Staticbot MCP server

preflight_cloudflare_hosting

Read-only

Verify a Cloudflare hosting choice and hostname are deployable before creating anything. Preflight checks DNS, zones, and permissions read-only, blocking invalid deployments with clear fix instructions.

Instructions

Check that a hosting choice and hostname can actually be deployed, before create_stack or create_deployment. Read-only: it never creates, deletes or takes over anything. It answers for the managed choice too, so call it the same way whichever option the user picked.

How to use the result:

ok: true — deployable. Report connectionLabel, and hostname / workerName when present. note may add useful context (for example that an apex hostname is supported).
ok: false — do not create anything. Show the user blockingMessage verbatim; it names the exact collision and what to fix in Cloudflare. Resolve it with the user, then call this again. warnings are non-blocking (a check that could not be run) — surface them, but they do not stop the deployment.

For a customer choice, hostname must be a domain that already lives in one of that account's zones. An autogenerated Staticbot subdomain cannot be used, and an apex such as example.com is supported. The answer can go stale — permissions and DNS can change — so call it again after any change the user makes, and never treat a previous result as permission.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`choice`	Yes	The `value` of the chosen option from list_cloudflare_hosting_targets — either its `managed.value` or a `customerOptions[].value`. Pass it through unchanged.
`hostname`	Yes	The hostname the app will serve, e.g. 'example.com' or 'app.example.com'. Required for a customer account (apex is supported); ignored for the managed choice.

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

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'it never creates, deletes or takes over anything.' It goes beyond annotations by explaining the staleness risk ('permissions and DNS can change'), the meaning of ok:true/false, and how to handle warnings. This is rich behavioral context that helps the agent act correctly on the result.

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 structured with a clear purpose line, a 'How to use the result' section with bullet points, and a final constraints paragraph. Every sentence earns its place—no fluff. The most important info (purpose and read-only) is front-loaded, and the result-handling rules are logically organized.

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 (two params, conditional behavior, staleness), the description covers everything an agent needs: when to call, how to interpret results, constraints on hostname, and the need to re-call after changes. An output schema exists, so return-value details are not needed. The description is complete for safe and correct usage.

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

Parameters5/5

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

Schema coverage is 100% (both parameters have descriptions), but the description adds critical semantics: for a customer choice, hostname must be a domain in an account zone, autogenerated subdomains are forbidden, and apex domains are supported. It also instructs to pass the choice value through unchanged. These constraints are not in the schema and are essential for correct invocation.

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 opens with a precise verb+resource: 'Check that a hosting choice and hostname can actually be deployed, before create_stack or create_deployment.' It clearly names the two sibling tools it precedes, distinguishing its role as a preflight gate. The read-only nature is stated explicitly, and it even clarifies it applies to the managed choice as well, leaving no ambiguity about scope.

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 ('before create_stack or create_deployment') and instructs to call it again after any user change because the answer can go stale. It also states to call it the same way for either hosting option. While it doesn't list exclusions, the context is unambiguous and the alternative tools are named, so an agent knows exactly when to invoke this.

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

Deploy Server