Runtype hosts an MCP server that lets an AI client — Claude Code, Cursor, Claude Desktop, or any MCP-compatible app — build and operate your Runtype account through tools. From the client you can create products, design and run flows, configure surfaces, embed Persona chat widgets, and manage agents, records, logs, and runtime tools. This is the opposite direction from connecting Runtype to external MCP servers: here, an AI client connects to Runtype.
Runtype touches MCP in three distinct ways. Don’t confuse them — each is a different server in a different direction.
Runtype offers two MCP servers over the same account. Pick the one that matches how your client discovers and runs tools.
create_flow, list_records, execute_tool, and so on). Best for clients that browse a flat tool list and call tools by name.search / execute pair that runs JavaScript against the Runtype API. Best for clients that prefer to write code against a discovered API surface rather than call many individual tools.Both servers transmit a set of instructions to the client on connection that describe the recommended call sequence below.
Both servers expose helper tools that return platform rules and reference material. Follow this order so the client builds against accurate schemas instead of guessing.
get_build_instructions before any create_* mutation. It accepts a tasks value of build-product, generate-flow, or explain-capabilities and returns the platform rules, schemas, step types, and variable-system guidance for that task.get_platform_documentation for deterministic lookups and search_documentation for prose questions. get_platform_documentation serves exact schema, type-definition, tool-catalog, embed, SDK, and dashboard-link references on demand. search_documentation runs a semantic search over the published docs corpus and returns a synthesized answer with citations — reach for it for “how do I…” and “what is…” questions, and for get_platform_documentation when you need an exact contract.list_tools, then run them with execute_tool.On the Code Mode server, the equivalent of step 3 is to call search to list API methods grouped by category, drill into a method for its signature, then call execute. Still call get_build_instructions before building or designing anything.
list_toolslist_tools returns your user-defined tools by default, plus a builtinToolsAvailable summary that groups the 100+ built-in platform tools by category. This summary lets a client see what’s available without pulling every built-in at once.
id, name, and description: data_management, file_operations, image_generation, knowledge_retrieval, web_scraping, and web_search. Record CRUD, asset storage, image generation, and web search are immediately visible.commerce and third_party_api. For third_party_api, the top vendors are surfaced in the summary.Every tool returned — user or built-in — carries a source field of "user" or "builtin". Pass the id value to execute_tool verbatim.
The builtinToolsAvailable summary also carries a seeAlso array of resource URIs. Fetch any of these with resources/read for fuller documentation than the inline summary provides.
execute_toolexecute_tool runs both your user tools and the built-in platform tools. For platform tools, pass the id exactly as it appears in list_tools — the server dispatches it through the built-in tool executor and returns the same response shape as a user tool execution.
Platform tool IDs come in two forms:
builtin:<name> — for example builtin:firecrawl, builtin:dalle, builtin:exaplatform:orthogonal:<vendor>:<tool> — for example platform:orthogonal:apollo:people_matchCall list_tools with include_schema: true to inline each tool’s parametersSchema. The client then knows the expected arguments for execute_tool without a second round trip.
Two tools manage the lifecycle of Runtype Sandbox containers, so a client can deploy generated code and get a live preview URL:
Deploy returns a previewUrl you can open immediately to see the running result. Always call destroy_sandbox when you’re done to release the container.
dispatchWhen you run a flow through the MCP server with dispatch, debug mode is on by default, so the response includes each step’s result instead of only a final flow_complete summary. This lets the client verify exactly what the flow ran. To stream events as they happen, set streamResponse (camelCase) on the request.