Staticbot MCP server

create_stack

Create a deployable stack from a template by selecting a domain, then let Staticbot route it to the correct hosting target.

Instructions

Create a new infrastructure stack from a template. A stack ties a template to a domain and becomes deployable. Call list_templates first to find the right templateId. Staticbot analyzes the template's repository and owns the hosting decision: static sites route to the supported AWS static target, SSR/full-stack apps route to the supported Cloudflare Workers target. Report the returned hostingWorkload, deploymentTarget, and infrastructureOwnership fields to the user.

Never invent a provider or an account. Cloudflare alone accepts an account-placement default during stack creation because a customer Worker stack pins its connected integration and resolved zone. If the user wants that, call list_cloudflare_hosting_targets, let them choose, then preflight_cloudflare_hosting and pass the preflighted value as cloudflareChoice. Otherwise omit it for Staticbot hosting. For an AWS static site, create the stack first, then call list_aws_hosting_targets with its stackId and pass the selected value to create_deployment as targetAccountId. There is no AWS account field on create_stack.

For templates that use Supabase, pass supabaseIntegrationInstanceId + supabaseProjectRef. Staticbot fills and refreshes the declared Supabase configuration from the connected account; never ask the user for Supabase API keys.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable name for the stack (e.g. 'My Portfolio Site')
`templateId`	Yes	Template ID — get this from list_templates
`domainOption`	Yes	How to assign a domain to this stack
`configOverrides`	No	Non-secret key/value overrides for template config variables. See get_template for available keys. Never put passwords, tokens, private keys, or provider credentials here — secret-looking keys are REJECTED, not ignored, because this connection cannot carry credential values.
`cloudflareChoice`	No	Optional, Cloudflare Workers / SSR apps only. Where to host the app: the `value` of a choice from list_cloudflare_hosting_targets (its `managed.value` for Staticbot hosting, or a `customerOptions[].value` for the user's own Cloudflare account). Omit for Staticbot hosting. Only pass a value that response returned, and only after preflight_cloudflare_hosting returned ok — the domain must already live in one of that account's zones.
`supabaseProjectRef`	No	Optional. Supabase project reference (the subdomain part of https://<ref>.supabase.co) — get it from list_supabase_projects. Must be set together with supabaseIntegrationInstanceId to enable auto-refresh.
`supabaseIntegrationInstanceId`	No	Optional. Supabase integration instance ID from list_integration_instances. Combined with supabaseProjectRef, enables auto-refresh of anon keys from Supabase Management API on each deploy — you never have to manually rotate.

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

Behavior5/5

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

Annotations are sparse (readOnlyHint=false, openWorldHint=false, destructiveHint=false), so the description carries the full burden. It richly discloses behavior: Staticbot owns the hosting decision, routing static to AWS and SSR/full-stack to Cloudflare Workers. It explains the output fields ('hostingWorkload', 'deploymentTarget', 'infrastructureOwnership') that the agent should report. It also warns about secret rejection: 'secret-looking keys are REJECTED, not ignored' and explains Supabase auto-refresh behavior. This goes well beyond annotations.

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

Conciseness1/5

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

The description is excessively long (over 300 words) for a tool with already-detailed schema. It repeats information already in the schema (e.g., the cloudflareChoice description essentially duplicates the property description) and includes procedural narrative that could be shortened. It is not front-loaded effectively; the core purpose is stated first, but the subsequent paragraphs are dense and could be condensed. This is over-specification, not concise guidance.

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 (7 params, nested objects, multiple hosting targets, security constraints), the description provides comprehensive context: prerequisites (list_templates), provider selection rules, credential handling, and expected outputs. With an output schema present (has_output_schema=true), the return value explanation is not required. The description covers all necessary aspects for an agent to call it correctly.

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% (as indicated by the signal), and the schema already provides descriptions for all 7 parameters, including nested objects and special constraints. The description adds value by specifying relationships between parameters (e.g., 'supabaseIntegrationInstanceId must be set with supabaseProjectRef') and clarifications for cloudflareChoice (pass only after preflight). However, since the schema already covers the basics, the description's incremental semantics are moderate, justifying a 3.

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 ('create'), a specific resource ('infrastructure stack'), and the purpose ('ties a template to a domain and becomes deployable'). It clearly differentiates from siblings like list_stacks, get_stack, and create_deployment. The mention of 'from a template' and 'deployable' adds precise context.

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 directs when to use this tool: 'Call list_templates first to find the right templateId'. It also names alternatives for related decisions: 'call list_cloudflare_hosting_targets' for Cloudflare, 'call list_aws_hosting_targets' for AWS, and notes that there is no AWS account field on create_stack. It clearly states what not to do ('Never invent a provider or an account') and when to omit optional parameters ('Omit it for Staticbot hosting').

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

Deploy Server