Staticbot MCP server

list_cloudflare_hosting_targets

Read-only

List available Cloudflare hosting targets so users can choose where to deploy their Worker: Staticbot-managed or their own connected account.

Instructions

List the Cloudflare accounts this app can be hosted in: Staticbot's managed account (the default) plus any Cloudflare account the user has connected. Call this before create_stack or create_deployment for a Cloudflare Workers / SSR app whenever the user has a connected Cloudflare account and might want the Worker deployed into it rather than hosted by Staticbot.

Read the response, do not compute from it:

managed is the Staticbot-hosted option. It is always present and always valid.
customerOptions lists the user's own accounts — each with a ready-to-render label and the value you pass back verbatim. Pass value through unchanged; never construct or edit one.
notices explains accounts that could not be offered (a revoked credential, a missing Workers permission). Show these to the user — they are the reason an account is missing from the list.
selectedValue / selectedHostname are the defaults when stackId was supplied.

Do not decide for the user. If customerOptionsAvailable is false, do not ask — Staticbot hosting is the only choice. If it is true, present the options (including the managed one) and let the user pick. Deploying into the user's own account means the Worker, its domain and its certificate live in their account, so it is their decision, not an inference from their setup.

Before creating anything with a customer choice, call preflight_cloudflare_hosting — it reports collisions that would otherwise fail the deployment.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`stackId`	No	Optional stack ID. When supplied, `selectedValue` and `selectedHostname` come back as that stack's current hosting choice and hostname, suitable as the default selection.

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

Behavior5/5

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds substantial behavioral context: managed is always present and valid, customerOptions values must be passed back verbatim, notices explain missing accounts, and the agent must not decide for the user. This goes well beyond the annotations.

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

Conciseness4/5

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

The description is longer than average but well-structured: purpose and usage come first, response semantics are bulleted, and the decision rule and preflight dependency are clearly separated. It earns its length, though the repeated emphasis on not deciding for the user could be slightly tightened.

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 single optional parameter, existing output schema, and complex decision context, this description is complete. It covers when to call, what the response fields mean, how to handle them, what not to do, and which follow-up tool to call before creating resources.

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?

Schema description coverage is 100%, and the single optional stackId is already well-documented in the schema. The description adds the behavioral consequence of supplying stackId—selectedValue and selectedHostname come back as defaults—but does not add new syntax or format details, so the baseline of 3 is appropriate.

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: 'List the Cloudflare accounts this app can be hosted in', and immediately distinguishes the managed Staticbot option from user-connected Cloudflare accounts. It clearly differentiates from sibling list_aws_hosting_targets by naming the Cloudflare 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 explicitly says when to call it: 'Call this before create_stack or create_deployment for a Cloudflare Workers / SSR app whenever the user has a connected Cloudflare account'. It also names the follow-up dependency, preflight_cloudflare_hosting, and gives a decision rule based on customerOptionsAvailable.

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

Deploy Server