# answer.cloud MCP: Site & Deploy Tools > Canonical source: [answer.cloud MCP: Site & Deploy Tools](https://ai.answer.cloud/docs/mcp-site-and-deploy-tools/) 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. 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 → 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:** none - **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` - **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` - **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.