answer.cloud MCP: GitHub Push-to-Deploy Tools

Connect a GitHub repository and deploy on push: github_get_connection, github_link_repo, github_get_workflow, github_trigger_deploy, and github_unlink_repo, plus the actions vs none build modes.

Published July 20, 2026

These answer.cloud MCP tools connect a GitHub repository to a site so that pushing to GitHub deploys automatically. They are an alternative to the manual start_deploy upload loop — once a repo is linked, you stop uploading zips by hand. For the manual deploy tools, see the site & deploy tools page; for connection and auth, see the MCP overview.

Linking a repository is configuration, not a deploy. It still requires your explicit intent, and the first push that actually deploys is one you make.

Two build modes

When you link a repo you choose how it deploys:

• actions (default, right for Astro and other build steps): your repo builds in GitHub Actions, then deploys to answer.cloud using OIDC — no secrets are stored anywhere. answer.cloud gives you a workflow file to commit; from then on, every push runs the build and deploys the result.
• none: your repository already contains the built, static output. There is no CI step — a push deploys the repo contents directly through a webhook.

The mode determines which tools apply, so pick deliberately.

github_get_connection

Check whether the organization has connected its GitHub App, and to which repositories.

• Arguments: none
• Returns: the connection state, the list of accessible repositories, and which sites are already linked. If the organization has not installed the App yet, it returns an install_url.
• How to use it: if you get an install_url, hand it to the user to open in a browser — installing a GitHub App and choosing repositories is a consent step only a human can complete. After they confirm, call github_get_connection again to see the now-available repositories. Agents should not loop on this expecting the connection to appear on its own.

github_link_repo

Link a repository to a site and choose its build mode.

• Arguments: site_slug, repo (owner/name); optional branch, dir, output_dir, build (actions or none), workflow
• Returns: the link record. For build: actions, the response includes the generated workflow file (.github/workflows/answercloud.yml).
• Notes: one repository powers one site. The call is idempotent — linking again updates the configuration. For actions builds, write the returned workflow file into the repo, commit, and push; that first push wires up OIDC deploys.

github_get_workflow

Fetch the current workflow file for a linked site.

• Arguments: site_slug
• Returns: the contents of .github/workflows/answercloud.yml
• Notes: use this to re-retrieve or diff the workflow if you need to re-commit it.

github_trigger_deploy

Deploy the head of the linked branch immediately, without waiting for a push.

• Arguments: site_slug; optional ref
• Returns: the queued deploy
• Notes: this works only for build: none sites, where answer.cloud controls the deploy directly. For build: actions sites it returns github_actions_build, because the build runs inside GitHub Actions — trigger those by re-running the workflow on GitHub instead. This tool consumes a daily deploy.

github_unlink_repo

Turn push-to-deploy off for a site.

• Arguments: site_slug
• Returns: confirmation
• Notes: unlinking stops automatic deploys but leaves the site and its current deploy live. Manual start_deploy deploys continue to work.

Checking status after a push

After a push deploys, use the standard list_deploys and get_deploy tools. Deploys created from GitHub carry the commit's git metadata, so you can confirm exactly which commit went live. For build: none sites, answer.cloud also posts a commit check run named answer.cloud; for build: actions sites, the Actions job itself is the commit status.

Frequently asked questions

Why don't my pushes deploy?

Check the build mode. For build: none, pushes to the linked branch deploy automatically. For build: actions, the workflow file must be committed to the repo and GitHub Actions must run — a push that doesn't trigger the workflow won't deploy.

The workflow won't commit — I get a 403.

Committing the workflow file needs the GitHub App's "Workflows: Read and write" permission in addition to contents access. Re-grant the App that permission, then commit the workflow again.

Can one repo deploy multiple sites?

No. The relationship is one repository to one site. Link a second repo for a second site.