# answer.cloud MCP: Site & Deploy Tools > Canonical source: [answer.cloud MCP: Site & Deploy Tools](https://www.answer.cloud/docs/mcp-site-and-deploy-tools-hosted/) The MCP tools for creating sites and shipping static artifacts: list_sites, create_site, start_deploy, finalize_deploy, deploy_files, get_deploy, list_deploys, and rollback, plus the deploy status flow and warnings. ## 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 are the answer.cloud MCP tools for creating sites and shipping static artifacts. They cover the full deploy loop: inspect what exists, create a site, upload a build, finalize it, and poll until it is live. For authentication and connection details, see the MCP overview page; for GitHub push-to-deploy and CMS authoring, see their dedicated pages. ## The deploy loop at a glance ``` list_sites → create_site only if the target is missing → build locally → start_deploy → run upload command → finalize_deploy → poll get_deploy until "live" → read warnings → fix and redeploy until clean ``` Deploys move through a fixed sequence of statuses: ``` uploading → queued → extracting → embedding → syncing_cms → generating_aeo → publishing_cms → live ``` Terminal failure states are `failed` and `rolled_back`. Each site numbers its deploys with a monotonic `sequence`. ## list_sites List every non-deleted site in the organization. - **Arguments:** `organization_id` when required by the connection - **Returns:** `sites[]`, each with `slug`, `name`, `url`, `custom_domain`, `status`, `pages_used`, `pages_limit`, and `current_deploy` (its `sequence` and `live_at`). Use this first to discover slugs and confirm whether the site you want already exists. ## create_site Create a new site served at `https://{slug}.answer.cloud`. - **Arguments:** `slug` (required), `name` (optional) - **Returns:** the site record and its live URL - **Notes:** the slug must be a DNS-safe label — lowercase letters, digits, and hyphens. The call is idempotent: asking for a slug the organization already owns returns the existing site. If the organization has no card on file, it fails with `card_required`. ## start_deploy Begin a full-artifact deploy by requesting a direct-to-storage upload. - **Arguments:** `site_slug`; optional `environment` assertion - **Returns:** `deploy_id`, `sequence`, a presigned `upload_url`, `expires_at`, `max_bytes`, and a ready-to-run `upload_command` - **Notes:** the presigned URL is valid for 15 minutes. The `upload_command` zips your build directory and `PUT`s it to storage — edit its build-directory path before running it. This tool consumes a daily deploy and reports `deploys_remaining_today`. ## finalize_deploy Tell the platform the upload is complete and start processing. - **Arguments:** `deploy_id`; optional `artifact_sha256` - **Returns:** the queued deploy status - **Notes:** call this only after the upload finishes. The server checks the uploaded object's size against your plan ceiling; an oversized artifact is deleted and the deploy fails with `too_large`. Pass `artifact_sha256` to have the platform verify integrity. ## deploy_files Deploy a small changeset inline, without the presigned-upload round trip. - **Arguments:** `site_slug`, `files[]` (each `{ path, content_base64 }`, 1–200 files), optional `message` - **Returns:** `deploy_id`, `status` - **Notes:** intended for changesets of **500 KB or less, total**. Remember that base64 inflates size by roughly a third. For full sites, always use `start_deploy` so the artifact goes straight to storage instead of through the model's context. This tool also consumes a daily deploy. ## get_deploy Poll a deploy's progress — this is your status endpoint. - **Arguments:** `deploy_id` - **Returns:** `sequence`, `status`, `warnings[]`, `pages_ingested`, `pages_skipped`, `error` (on failure), and `live_url` once live. While the deploy is in progress it returns `retry_after_seconds` (honor it between polls). **Warnings you should act on:** - `spa_shell` — the deployed HTML is an empty client-rendered shell. Answer engines read raw markup, so switch to static generation (Astro's default output). - skipped pages — the site exceeded the AEO page-indexing limit for your plan; some pages were not indexed. - `cms_path_collision` — a static file in the artifact shadowed a CMS-owned path. The static file wins; remove it or move the CMS path. A deploy can reach `live` and still carry warnings. Always read `warnings[]` before declaring success — a green status does not guarantee a healthy site. ## list_deploys Show recent deploy history for a site. - **Arguments:** `site_slug` - **Returns:** up to the last 7 deploys with `sequence`, `status`, and timestamps ## rollback Re-point a site's live traffic to an earlier deploy. - **Arguments:** `site_slug`, `to_sequence`; optional `environment` target - **Returns:** the new current deploy and live URL - **Notes:** you can only roll back to a deploy that previously went live. Rollback also re-renders published CMS content onto the target deploy. ## A note on two identifiers Deploys are addressed two ways. `get_deploy` and `finalize_deploy` take the numeric `deploy_id`; `list_deploys` and `rollback` work with the human-friendly `sequence`. Both are returned by `start_deploy`, so keep them together and don't cross them. ## Frequently asked questions ### Should I use start_deploy or deploy_files? Use `deploy_files` only for tiny edits (≤ 500 KB after base64). Everything else — and every first deploy of a real site — goes through `start_deploy`. ### Why did my upload succeed but finalize_deploy fail with too_large? A presigned upload cannot enforce a size limit at upload time, so an oversized artifact still reaches storage and is rejected at `finalize_deploy`. Keep artifacts within your plan's ceiling before uploading. ### How long should I wait between get_deploy polls? Use the `retry_after_seconds` value from the previous response. Ingestion embeds each page, so a large site can take several polling cycles — and every poll counts toward your per-minute request limit. ## Staging and production `configure_release_workflow` takes `site_slug` and `enabled`. When independent releases are enabled, all uploads target the platform staging URL and require explicit promotion to the custom-domain production site. The optional `environment` on `start_deploy` or `deploy_files` is an assertion; the configured workflow decides the destination. `promote_deploy` takes `site_slug`, with optional `deploy_id` or `to_sequence`, and promotes a processed staging deploy without rebuilding. `rollback` can target an environment. Inspect the site and request the intended release explicitly. ## Custom domains On an eligible paid plan, `set_custom_domain` takes `site_slug`, `domain`, and optional `include_apex`. The latter defaults to false; enable it only when the apex should redirect to the selected host. Use the returned DNS records rather than a hard-coded infrastructure hostname. `check_domain` takes `site_slug`, optional `domain`, and optional `refresh`; refresh queues a new DNS/HTTPS check. Verify routing and certificates before relying on the domain. A full hosted site and an existing-site companion require different artifacts. Follow the [hosted guide](https://www.answer.cloud/docs/mcp-hosted-sites-hosted/) or [existing-site guide](https://www.answer.cloud/docs/mcp-existing-sites-hosted/).