Skip to main content
Auto MCP is the platform’s own MCP server — the surface through which an agent operates auto itself: discovering and starting connections, running consent flows, dry-running .auto/ changes, inspecting sessions, binding threads and pull requests, and coordinating sibling agents. Every session that declares the local auto tool gets it wired automatically under the auto alias. This page explains where the server lives, how it authenticates, what it exposes, and how the same tools appear under different client naming schemes.

​
One server, scoped to a session

Auto MCP is served per session over streamable HTTP:
There is no global endpoint to configure. When the platform launches a session whose agent declares local tools, it issues a session-scoped run access token (24-hour TTL) carrying exactly the scopes that session’s tools need, and hands the harness a server map entry { type: "http", url, headers } for the endpoint. A token minted for one session can only call that session’s endpoint. The server itself is assembled fresh per request and registers only the tool implementations present in the session’s tool snapshots — an agent without a chat tool sees no chat.* tools at all, and the billing offer tool exists only for sessions whose auto tool declares capabilities: { billing: write }. checks.* is the one snapshot-independent family: it registers whenever the spawning trigger declared checks:. Scopes are least-privilege per capability. The local auto tool adds agents:read, environments:read, provider_grants:read/write/use, secrets:read/write, and webhook_endpoints:write on top of the session scopes; GitHub access adds github:mcp; proxied connection tools add mcp:connection. Each tool call is additionally checked against per-tool scopes server-side.

​
What it exposes

Four tool families ride the one endpoint, documented in detail on their own pages:

auto.* — platform coordination

Spawn/message/stop sessions, bindings, connection discovery and consent flows, GitHub Sync, resource dry-runs, managed templates, webhooks, secrets, and eight read-only session-introspection tools.

chat.* — unified messaging

Send, search, history, reactions, attachment downloads, and issue tools across Slack, Discord, Telegram, and Linear.

checks.* — GitHub check runs

List, begin, and conclude the managed checks a trigger declared.

ping

ping({ message? }) → pong: <message> — a connectivity smoke test for the endpoint.
In capability terms, the surface covers: connection discovery and consent (auto.connections.providers.list, auto.connections.list, auto.connections.start, auto.agent_tools.connect — consent flows return an authorization URL and report their terminal outcome back to the session automatically), dry-runs (auto.resources.dry_run validates and plans .auto/ changes without applying), session inspection (auto.sessions.summary, .search, .conversation, .tools, .triggers, .bindings, .commands), thread subscription and PR ownership (auto.bind / auto.unbind with slack.thread and github.pull_request targets), and fleet coordination (auto.sessions.spawn / .message / .stop).

​
Tool names across clients

The canonical tool names are dotted (auto.sessions.spawn, chat.send, checks.begin). MCP clients render them differently: This is why production system prompts read mcp__auto__chat_send — it is the claude-code flattening of chat.send on the auto alias, not a different tool. When writing prompts, use the names your agent’s harness will see. The auto alias itself is reserved deterministically: if an agent’s own remote tool already claimed the alias auto, the platform’s server is wired as auto2 instead (the same rule protects the github alias for GitHub tools).

​
How the sandbox adapts it

Inside a sandbox, the agent-bridge runtime interposes a thin local shim in front of the session MCP URL for exactly one purpose: it rewrites auto.resources.dry_run into a path-first facade. The agent calls it with no arguments (validate the whole working-tree .auto directory) or with repository-relative paths:; the shim reads the YAML from the working tree — following local imports: automatically, enforcing 100-file / 3,000,000-byte bounds and working-tree containment — and forwards the platform’s established inline-files request upstream. Every other request and response passes through unchanged. This means a sandboxed agent never has to inline file contents to validate configuration, while remote callers of the same tool keep the explicit files/resources dialects.

​
Server behaviors worth knowing

  • Schema hygiene for picky models. tools/list responses are sanitized for model providers that reject boolean JSON-Schema subschemas, and structured parameters accept JSON-encoded strings which the server coerces back to objects — an accommodation for hosts whose constrained decoding cannot emit freeform object maps. Binding context fields document this arm explicitly.
  • Deprecated aliases are still registered for sessions spawned with older prompts: auto.artifacts.record/auto.artifacts.release (now auto.bind/auto.unbind) and auto.chat.subscribe/auto.chat.unsubscribe (now bind/unbind with a slack.thread target). New prompts should use the canonical names.
  • Required tools are enforced at boot. When a trigger declares checks:, the harness bootstrap requires the auto server to expose checks.list, checks.begin, checks.success, and checks.failure before the session’s first turn — a session cannot silently start without its check tools.
Auto MCP is provisioned automatically for hosted sessions; there is no separate standalone MCP server to install into a personal IDE or desktop client today. Hosted agents that “operate auto through MCP” — including the onboarding agent — are themselves sessions calling this endpoint.