MCP for coding agents

The Tori MCP interface is a preview. It is a second thin client of the same public API as the CLI, intended for coding agents that need to deploy and operate an app without learning a separate control-plane interface. Managed Postgres is also a preview. Its tools work with service apps; static sites cannot have a managed database.

Connect a host

Tori is a local stdio server. The host starts it and speaks MCP over the process’s standard input and output. For Claude Code:

claude mcp add tori -- npx -y tori.host mcp

For another MCP host, configure command npx with arguments -y, tori.host, and mcp. Keep stdout attached to the host: it carries the protocol, while diagnostics go to stderr.

The process working directory matters only for tori_deploy with a relative directory or source. Prefer an absolute path when the host’s working directory is unclear.

tori_deploy takes exactly one of three inputs, and they are not interchangeable:

directory publishes already-built static files as they are. Tori runs no build command for the agent, so build the site first. The directory must contain index.html.
source uploads a project for Tori to build: a Dockerfile at the root is built, otherwise the language is detected. .git, node_modules and everything .gitignore matches stay out of the upload — the same rules as tori deploy --service, including a monorepo root’s .env rule. The result reports built as dockerfile or detected, read from what was uploaded rather than from the working tree (a .gitignore that matches Dockerfile leaves it on disk and out of the build).

Migrations do not run by themselves. A source deploy runs a release command before the new revision takes traffic only if the release input is given, or the project’s tori.json sets "release"; "release": false there means none. Without either, the new revision serves against the old schema. The result echoes release — an array, or null when none ran — so an agent can say which happened rather than inferring it from status: live.

A container that does not listen on 8080 needs its port: the port input for a source or image deploy, or "port" in the project’s tori.json for a source deploy. Without it the revision never becomes ready. Ports 8012, 8013, 8022, 9090 and 9091 are reserved and refused before anything is uploaded.
image deploys a digest-pinned image that is already in a registry.

directory creates a static app; source and image create a service. An app is one kind for its whole life, so a slug first deployed from a directory cannot later take a source deploy — start a new app instead.

Authenticate

The server uses the same API tokens as the CLI. Choose one of these paths:

Run npx tori.host login once as the same operating-system user that runs the MCP host. The server reads ~/.config/tori/config.json.
Set TORI_TOKEN in the MCP server’s environment. This takes precedence over the config file and is the usual choice for an isolated host or CI.

TORI_API_URL overrides the default API base URL. Do not paste a token into a prompt or tool argument; the tools have no token field. Revoke a token under Settings → API tokens in the console when the host should lose access.

Work with asynchronous operations

Tool results report observed state, not a promise that background work has finished.

tori_deploy waits for an authoritative live or superseded deploy result.
tori_db_create usually returns provisioning. Call tori_db_status until it returns ready. That state proves the database resource is available, but not that Tori attached its URL: an existing customer-supplied DATABASE_URL is preserved and attachment can fail independently. Before deploying a revision that should use it, run tori env list and check that the key exists. Because the value is masked, its presence does not distinguish a preserved customer URL from the managed one. The URL and password are never returned through MCP.
tori_db_restore restores a succeeded nightly dump into a separate database. It never overwrites the live database and never changes DATABASE_URL. Follow it with tori_db_restore_status.
tori_db_delete permanently removes the live managed database. tori_db_restore_delete requests removal of only the named restore copy; its response does not prove that asynchronous zone cleanup has completed. MCP hosts should ask for confirmation before either destructive call.

Shared-tier recovery is based on nightly dumps, not point-in-time recovery. A dump with pending or failed status is not restorable.

Tools

Read the generated MCP tool catalogue for every advertised tool, its inputs, and its read-only, destructive, and idempotency hints. That page is generated by connecting to the same registry the server exposes, so adding a tool without adding it to the reference is not possible.

The command that starts the server is documented separately under tori mcp.

Download this page as Markdown.