Staticbot MCP server

get_deployment

Read-only

Check deployment progress and DNS state for each domain, then act on per-domain actions such as adding records, pushing to Cloudflare, or registering the domain.

Instructions

Get the status of a deployment and the per-domain DNS state. Poll this for progress. Statuses: CREATED → PENDING → IN_PROGRESS → WAITING → COMPLETED (or FAILED).

Response fields you should always read:

status — pipeline state.
dns — per-domain DNS state, populated once Terraform emits a state snapshot. Present regardless of status; check it on every poll, not just on WAITING.
requiredAction — legacy; only set when status=WAITING and there are records to add. Prefer dns.

For each entry in dns, read action and behave as follows:

NO_ACTION — registrar NS already delegate to a zone Staticbot owns; nothing to ask the user. Celebrate.
MANUAL_RECORDS_AT_REGISTRAR — present records (cert CNAME + ALIAS/CNAME for the website) to the user, asking them to add them at whatever DNS provider currently serves their domain. Do NOT suggest changing nameservers — Staticbot intentionally does not recommend NS takeover as a default path.
OFFER_CLOUDFLARE_PUSH — domain is on Cloudflare and an integration is linked. Offer push_dns_to_cloudflare using this item's exact domainId; obtain authorization before the external DNS write. Manual records at the current provider remain the fallback.
OFFER_CLOUDFLARE_CONNECT — domain is on Cloudflare without an integration. Suggest connecting Cloudflare (direct the user to the integrations page) for the smoothest no-NS-change path.
REGISTER_DOMAIN_FIRST — domain is not registered. Block and ask the user to register it first.

Other fields per domain:

staticbotManaged — true when live registrar NS overlap our recorded Route53 zone NS for this apex. Useful for explaining 'your domain is already pointing at us'.
nsPointedAt — AWS_ROUTE53 | CLOUDFLARE | OTHER (where the live NS resolve to).
mailRecordsDetected — true when MX/TXT/SRV/CAA records exist on the apex. Treat as a hard block on any advice that involves changing nameservers — doing so would risk breaking the customer's mail.
cloudflareLinked — true when the domain is wired to a Cloudflare integration in Staticbot.
domainId — Staticbot DNS-domain ID; pass this exact value to push_dns_to_cloudflare.
records — flat list of {type, host, value, description} to surface to the user.

The response also includes failureSummary when a worker job is failing or has been retried. Surface its summary; when terminal=true, include the statusUrl so the user can inspect the full failure.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Deployment ID

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Parsed JSON response from the Staticbot public API

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.8.1Sep 24, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds significant behavioral context: it explains that 'dns' is present regardless of status, that 'requiredAction' is legacy and only set when WAITING, and that 'mailRecordsDetected' is a hard block on NS-change advice. It also covers failureSummary and terminal status handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though lengthy, the description is well-structured with clear sections (statuses, response fields, per-domain actions, other fields, failureSummary). Every sentence serves a purpose, and critical guidance is front-loaded. It is comprehensive without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple DNS action states, legacy fields, external tool integration, hard blocks), the description is exceptionally complete. It covers all necessary interpretation rules, fallback behaviors, and edge cases, leaving nothing essential unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single 'id' parameter (uuid, 'Deployment ID') with 100% schema description coverage. The description does not add extra parameter semantics, but none are needed. This is a baseline 3 as the schema handles it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to get the status of a deployment and per-domain DNS state, and explicitly says to poll for progress. It also lists the status flow (CREATED → PENDING → ... → COMPLETED/FAILED), which distinguishes it from listing tools like list_deployments and other deployment-related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance ('Poll this for progress') and detailed instructions on how to interpret each DNS action (e.g., NO_ACTION, MANUAL_RECORDS_AT_REGISTRAR, OFFER_CLOUDFLARE_PUSH) and what to do or avoid (e.g., 'Do NOT suggest changing nameservers', 'obtain authorization before the external DNS write'). It also advises preferring 'dns' over legacy 'requiredAction'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server