answer.cloud MCP: Site & Deploy Tools

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.