answer.cloud MCP: Site & 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.

Published July 20, 2026

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 PUTs 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.