Build applications with Kaitoi.

Use Kaitoi as your application's workflow backend, with MCP helping discover and author the contract. Building an application is different from displaying an MCP Apps result panel, publishing a Station, or deploying a website.

#Inspect the application contract first

Use MCP discovery and get_api_contract to inspect the current workflow routes, scopes and request body. Retain every requestBody chunk with its revision and continuation. Your application backend holds its scoped credential, authorizes its users, submits the REST run and observes its result. Contract generation does not upload, execute, save, mint keys or deploy an application. Run Inspector is an optional result viewer, not application hosting.

The request artifact shows only selected fields, including targetNodeIds and an example typed number; retain the complete generated request body. The REST result feeds the application’s interface. Separately, Run Inspector presents compatible MCP tool results; a REST run ID is not interchangeable with its MCP execution selector.

#Start with the application's authority boundary

Call get_app_building_guide for the current integration guidance. Decide which trusted process holds the Kaitoi credential and which application users may submit work or access results. A server key belongs in your backend; browser-key origins are a constraint, not your application's user authorization. See Authentication and scopes.

#Discover an endpoint or graph source

list_templates can find relevant templates and active endpoints. list_template_endpoints and get_template_endpoint_contract expose the current input/output fields, defaults, file shapes and callable routes. Follow cursors and bounded default-value readers where needed.

Shared discovery metadata is not authority to run another owner's endpoint. Supported team selectors validate membership and can still refuse a personal-only REST operation. Check the actual returned contract and ownership.

#Generate the exact REST run contract

get_api_contract supports the listed current_graph, project, or template source. Current inline graph contracts need explicit target IDs; a saved project needs its project ID; a template needs its template and endpoint IDs. Use the actual schema for optional overrides and guards.

The result describes validated request body, routes, scopes, provenance and examples. For a large body, retrieve part:"requestBody" chunks with the same returned revision and continuation offset. Save the exact returned body as request.json rather than reconstructing a shortened summary.

The current attached current_graph source can be refused instead of exporting headless state silently. Respect that refusal; choose an available source explicitly. A saved-project REST run still has no submission expectedVersion guard. Read the returned provenance and source limitations.

#Separate contract generation from execution

Authority: your application decides who can use its scoped credential. Contract: discovery and get_api_contract produce current fields, routes, scopes and the exact body; retain all chunks. Execute: uploads, runs, persistence and deployment are separate actions. Shared metadata is not execution authority, and Run Inspector is a result viewer rather than hosting.

#Build and test the application deliberately

Contract generation does not run a graph, upload media, save a project, mint keys, publish content or deploy software. Those are separate authorized steps. Upload inputs through the REST file contract, reuse completed fileIds, submit a logical run once, observe its ID, and retain useful outputs.

Run Inspector is a conditional inline MCP Apps viewer for tool results; it does not host or deploy your own application. For a visitor-paid controlled tool, consider Stations. For a backend workflow, use Workflow API endpoints.