MCP for AI agents

Sahabti speaks the Model Context Protocol, so an AI assistant can work with your workspace directly: list what's running, read the provisioning log of the instance that failed, run a query, take a backup before a migration, resize a box that's out of memory.

The endpoint is:

text

https://api.sahabti.com/mcp

It's the same control plane the dashboard uses. There is no second implementation of any rule behind it — each tool call runs the exact route the dashboard calls, so your role, your token's scopes and your quota are enforced the same way whether a person or a model made the request.

Connect a client

The panel is on your workspace's API tokens page, under MCP, with a copy-ready snippet for each client. Two ways to authenticate:

OAuth — add the endpoint with no token. Your client registers itself, opens a browser for you to sign in, and then acts as you: your role in each workspace, re-checked on every request. This is the one to use on your own machine.

Static token — mint a workspace token and send it as an x-api-key header. The token names one workspace and carries the scopes you gave it, which makes it the right fit for a CI job or an agent running unattended.

Claude Code, with a token:

bash

claude mcp add --transport http sahabti https://api.sahabti.com/mcp --header "x-api-key: <token>"

Cursor, VS Code, and anything else that takes a config file:

json

{
  "mcpServers": {
    "sahabti": {
      "url": "https://api.sahabti.com/mcp",
      "headers": { "x-api-key": "<token>" }
    }
  }
}

For OAuth, drop the headers block and let the client handle sign-in.

A browser session cookie is deliberately not accepted. If it were, any page you happened to have open could reach every mutating tool.

What an agent can do

Twenty-six tools, grouped roughly as:


Orientation	`whoami` — which workspace this credential acts in, and what it may do. An agent should call this first.
Instances	list, get, create, start, stop, restart, retry a failed provision, rename, resize, delete
Observability	provisioning log, metrics, quota usage
Data	run a SQL query against a PostgreSQL or MySQL instance
Backups	list, create, restore into a fresh instance, delete
Projects	list apps and their deployments (read-only)
Workspace	list networks, list notifications, read and raise a quota increase request

Everything writes through the same intent-and-reconcile path as the dashboard: a create or a resize is recorded and answered immediately, and the instance converges to it. An agent that wants to know what happened should read the instance back, or watch the provisioning log — not assume.

What it deliberately can't do

Connection secrets. No tool returns an instance's password or an app's environment variables. A tool result becomes model context: it gets logged, and it travels to whichever provider the client uses. Connection details stay on the instance page in the dashboard.
Anything operator-level. Platform-wide and staff routes aren't in the catalog, and a workspace credential could never reach them anyway.
More than the credential holds. A read-only token gets read-only tools; a viewer's OAuth session can't start an instance. The permission check is the route's, not the tool's.

Next steps

API tokens — scoping the token an unattended agent uses
Database tools — the same query channel, from the dashboard
Instances — what the lifecycle tools actually do

PreviousAPI tokens