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.

Before any app gets access, Sahabti asks you — every time. Apps register themselves under any name they like, so the screen marks each one Unverified app and shows the address it will send you back to: approve only if you started this from that app and recognize the address. An app may only send you back to an HTTPS address, or to a listener on your own machine; one that registers anything else is refused, and can use a static token instead. Account → Sessions → Apps with access lists every app you've approved and revokes any of them.

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

Ninety-one tools, grouped roughly as:


Orientation	`whoami` — which workspace this credential acts in, and what it may do. An agent should call this first.
Instances	managed services, virtual machines and game servers: 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, MySQL or MariaDB instance (needs `instance:query`, for a `SELECT` too)
Backups	list, create, restore into a fresh instance, delete
Network access	an instance's inbound rules — list, forward a port, change who may reach it, remove — and making an instance public or private
SSH keys	list, add, remove
Certificates	list, import, rename, delete
Load balancers	list, get, create, rename, delete; their listeners, target groups and targets; protection, blocked and denied sources; metrics and metered usage
Kubernetes	clusters — list, get, create, scale, delete — with their node pools, volumes, API access, managed gateway and its hostnames, who has access, their settings (turning deletion protection and Pod Security on) and what needs attention
Web apps	list apps, their deployments and running processes; change how an app runs; redeploy or roll back
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, an app's environment variables or a kubeconfig. 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.
Lift a cluster's deletion protection. An agent can turn it on, never off: that takes a cluster admin, or a workspace owner or admin, signed in to the console.
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.
Get around a workspace's two-step requirement. In a workspace that requires two-step verification, an app acting for someone who hasn't set it up — signed in as them, or with a token they created — gets 403 TWO_FACTOR_REQUIRED from every tool there. whoami marks such a workspace with blockedBy: "TWO_FACTOR_REQUIRED".

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

NextKubernetes