# answer.cloud MCP: GitHub Push-to-Deploy Tools > Canonical source: [answer.cloud MCP: GitHub Push-to-Deploy Tools](https://www.answer.cloud/docs/mcp-github-tools-hosted/) 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. ## Organization selection Use browser OAuth for the normal interactive connection. Run `list_organizations` when the organization is not established; ask the user to choose if several are available. Include the selected `organization_id` on subsequent calls when required by the connection, including the tools listed below. 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:** `organization_id` when required by the connection - **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.