Staticbot MCP server

create_deployment

Create a deployment for a stack in APPLY, PLAN, or DRY_RUN mode. For AWS-hosted stacks, pass a chosen hosting target to set infrastructure ownership; the deployment is prepared but not started.

Instructions

Create a new deployment for a stack. This prepares the deployment but does NOT start it — call start_deployment next. Default type is APPLY (creates real resources). Use PLAN for a dry-run preview.

For an AWS-hosted stack, call list_aws_hosting_targets with the stackId first and pass the selected option's exact value as targetAccountId. That value DECIDES infrastructure ownership: the managed value means Staticbot-managed hosting and a customer account value means customer-managed hosting. Never invent an account id or send infrastructureOwnership.

Do not set cloudflareChoice or cloudflareHostname unless the user has chosen to host a Cloudflare Workers app in their OWN Cloudflare account: call list_cloudflare_hosting_targets, let the user pick, then preflight_cloudflare_hosting, and pass that choice plus the hostname. Omit both to use the stack's existing hosting, which is the normal case — Staticbot hosts it.

Input Schema

TableJSON Schema

Name	Required	Description
`stackId`	Yes	Stack ID to deploy
`deploymentType`	No	APPLY creates real infrastructure (default). PLAN shows what would change without creating anything. DRY_RUN validates the template.
`targetAccountId`	No	AWS-hosted stacks only. The exact `value` selected from list_aws_hosting_targets. This value is the ownership choice: the managed value means Staticbot-managed infrastructure; a customer account value means customer-managed infrastructure. Never invent an account id or pass infrastructureOwnership.
`cloudflareChoice`	No	Optional, Cloudflare Workers apps deployed into the user's own account only. The `value` of a choice from list_cloudflare_hosting_targets. Omit to use the stack's existing hosting (Staticbot's account by default) — that is the normal case.
`cloudflareHostname`	No	Optional. The hostname the app will serve, e.g. 'example.com' or 'app.example.com'. Required together with a customer cloudflareChoice, and one of the hostnames that account's zones cover. Apex is supported.

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.9/5.0

Behavior5/5

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

Beyond the annotations (which only say readOnly=false and destructiveHint=false), the description discloses critical behavior: the deployment is prepared but not started, APPLY creates real infrastructure, and targetAccountId determines infrastructure ownership. It also adds strong guardrails such as 'Never invent an account id or send infrastructureOwnership' and the consequence of omitting Cloudflare fields.

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?

The description is information-dense but well organized: first the core behavior and default, then the AWS workflow, then the Cloudflare workflow. Every sentence adds decision-relevant guidance, and the key 'does NOT start it' distinction is front-loaded.

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?

For a fairly complex tool with 5 parameters, the description covers the main flow, the AWS-specific prerequisite, the Cloudflare-specific conditional flow, and the normal default. The output schema exists, so return-value details are already covered. An agent has enough context to invoke this tool correctly in all the described scenarios.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful workflow context beyond the schema: it explains that targetAccountId must be the exact `value` from list_aws_hosting_targets, that it decides infrastructure ownership, and that cloudflareChoice/cloudflareHostname should be omitted for the normal existing-hosting path. This raises it above baseline.

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 states a specific verb and resource ('Create a new deployment for a stack') and immediately distinguishes itself from the sibling start_deployment by clarifying that this tool only prepares the deployment. It also clarifies the deployment type semantics (APPLY vs PLAN), making the tool's purpose unmistakable.

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?

The description gives explicit when-to-use guidance: call start_deployment next, use PLAN for dry-run preview, call list_aws_hosting_targets first for AWS-hosted stacks, and call list_cloudflare_hosting_targets + preflight_cloudflare_hosting for customer-owned Cloudflare apps. It also explicitly says when NOT to set Cloudflare fields, which is the normal case.

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

Deploy Server