MCP v0.1.0 · 22 tools

Your agent can deploy what it just wrote

Point an MCP client at one hosted endpoint and it can read your services, follow a failing build to the line that broke it and ship the fix. Nothing to install, nothing to run — an API key you scope, and secrets that never leave the dashboard.

https://mcp.runsite.app/mcp

Authorization: Bearer ak_live_…

agent — runsite mcp
22 tools
get_service_health api
degraded · last deploy failed 4m ago
get_deployment api dp_5c1e
build log: missing STRIPE_SECRET_KEY
set_env api ["STRIPE_SECRET_KEY"]
approval ap_8f21 — you enter the value
deploy api wait=true
running · 2 instances · healthy

Every call is made as the owner of the API key you gave it — nothing wider

Point a client at it

Create a key in the dashboard, drop it into the client you already use, and the tools appear in its next session. The server speaks Streamable HTTP and keeps no state between calls.

terminal
claude mcp add --transport http runsite \
  https://mcp.runsite.app/mcp \
  --header "Authorization: Bearer $RUNSITE_API_TOKEN"

Reads the key from your shell, so it never lands in a config file. Run `/mcp` in Claude Code to confirm the connection.

What the agent can reach

Every tool takes a service name or its id, and acts as the owner of the key you handed over — never wider. The scope beside each name is what a key needs before the tool appears in its list at all.

Look around

What exists on the account, and how it is configured.

whoamiread
The account this key belongs to and what it may do
list_projectsread
Projects on the account
list_servicesread
Every web service with its status, plan and public URL
get_serviceread
Repository, branch, instances and status of one service
list_envread
Variable names on a service — values are always masked
list_databasesread
Managed Postgres and Valkey in the workspace
get_databaseread
One database and its usage; connection URLs are never returned

Find out what broke

Enough context to diagnose a service without opening the dashboard.

get_service_healthread
Status, resource usage, last deployment and error lines in one call
get_logsread
Recent container output, capped at 200 lines and 8 KB
get_metricsread
CPU, memory and instance count, with the trend over a period
list_deploymentsread
Recent deployments with status, commit and duration
get_deploymentread
One deployment, plus the build log tail when it failed

Ship the fix

The same lifecycle actions the dashboard performs.

deploywrite
Build and release the current commit; wait=true polls until it finishes
restartwrite
Roll the running containers without rebuilding
startwrite
Start a stopped service from its existing image
stopwrite
Stop a service and release its compute; env and disks are kept
create_servicewrite
Create a service from a repository on a connected git provider

Ask you first

Nothing here changes anything until you answer in the dashboard.

set_envwrite
Request environment variables by name; you type the values
set_secretadmin
The same request for project secrets
rollbackwrite
Request a return to an earlier deployment
delete_serviceadmin
Request a deletion, which cannot be undone once approved
check_approvalread
Whether you approved, rejected or let the request expire

Hand over as little as you like

A key carries one scope, and the server filters the tool list to match it before the agent ever sees it. Start with a read key while you get a feel for what an agent does with your account, and revoke it in the dashboard the moment you want it to stop.

ScopeToolsWhat it allows
read13 of 22Inspect services, logs, metrics, deployments and databases. Nothing changes.
write20 of 22Everything above, plus deploy, restart, stop, create a service and request a rollback.
admin22 of 22Everything above, plus requesting project secrets and the deletion of a service.

An agent that loops gets 60 tool calls per minute per key and a refusal after that, so a bad retry loop costs you a minute rather than a bill.

Secrets stop at the dashboard

An agent can tell you a service needs a Stripe key. It cannot be the one holding it. Anything that sets a value, rolls a service back or deletes it goes through the same three-step handshake.

  1. 1

    The agent asks

    It names the keys it needs set. The values are not part of the request, so there is nothing for the agent to guess or leak.

    set_env("api", ["STRIPE_SECRET_KEY"])
  2. 2

    You answer in the dashboard

    The tool returns a link and an approval id. You type the values in the dashboard and approve, or reject. Unanswered requests expire.

    dashboard.runsite.app/approvals
  3. 3

    The agent reads the outcome

    Polling returns pending, approved, rejected or expired — and only that. The value you entered is never sent back to the agent.

    check_approval("ap_8f21") → approved

The rest of the surface follows the same rule: list_env masks values, get_database never returns a connection URL, and logs come back capped at 200 lines so a transcript cannot quietly swallow your whole output.

Resources and prompts

Clients that prefer to attach context rather than call a tool can read the same data as a resource. The two prompts are the routines worth having written down: diagnosing a service, and shipping a change without declaring victory too early.

Resources

runsite://services
Every web service on the account as JSON, for clients that read resources instead of calling tools.
runsite://service/{id}
One service as JSON, the same shape the dashboard reads.

Prompts

diagnose_service
Walks the agent through health, deployment, resources and dependencies, and tells it to change nothing.
deploy_and_verify
Deploys, waits, checks health, and asks you before rolling anything back.
FAQ

Frequently Asked Questions

Common questions about this service.

Any MCP client that speaks Streamable HTTP and lets you set an Authorization header — Claude Code, Cursor and VS Code are covered by the snippets above. Clients that only launch stdio servers can reach the same endpoint through the mcp-remote bridge.

In the dashboard under Settings → API keys. Give the key the smallest scope that covers what you want the agent to do: read for inspection only, write to let it deploy and restart, admin only if it needs to request secrets or deletions. Keys can be revoked at any time, which cuts the agent off immediately.

No. list_env returns variable names with masked values, get_database never returns a connection URL, and set_env and set_secret only carry key names — you type the values in the dashboard. Nothing in the tool surface returns a credential.

The server allows 60 tool calls per minute per API key and refuses the rest with a message telling the agent to wait. Your plan quotas still apply on top of that, so a runaway agent cannot deploy its way past them.

No. The server is hosted at https://mcp.runsite.app/mcp and holds no state between calls — it validates your key against the Runsite API on each request and acts as the owner of that key. There is nothing to update when tools are added.

No. The tool list itself is filtered by the scope of your key, so a read key advertises 13 tools and no deploy tool at all. A call to something outside the scope is refused with an explanation of which scope it would need.

Your app deserves to be online

€5 of credit on signup. Deploy in under a minute. No credit card needed.