> ## Documentation Index
> Fetch the complete documentation index at: https://docs.auto.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Auto MCP

> The platform's own MCP server: the session-scoped endpoint behind the auto alias, what it exposes, how tool names appear in each client, and how the sandbox adapts it.

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:

```http theme={null}
POST https://<your auto host>/api/v1/sessions/{sessionId}/mcp
Authorization: Bearer <session-scoped run token>
```

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:

<CardGroup cols={2}>
  <Card title="auto.* — platform coordination" href="/runtime/auto-tools">
    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.
  </Card>

  <Card title="chat.* — unified messaging" href="/runtime/chat-tools">
    Send, search, history, reactions, attachment downloads, and issue tools across Slack, Discord, Telegram, and Linear.
  </Card>

  <Card title="checks.* — GitHub check runs" href="/runtime/auto-tools">
    List, begin, and conclude the managed checks a trigger declared.
  </Card>

  <Card title="ping" href="/runtime/auto-tools">
    `ping({ message? })` → `pong: <message>` — a connectivity smoke test for the endpoint.
  </Card>
</CardGroup>

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:

| Client      | Rendering                                    | Example                                                  |
| ----------- | -------------------------------------------- | -------------------------------------------------------- |
| claude-code | `mcp__<alias>__<tool>` with dots underscored | `mcp__auto__auto_sessions_spawn`, `mcp__auto__chat_send` |
| codex       | `<alias>.<dotted tool>`                      | `auto.auto.sessions.spawn`, `auto.chat.send`             |

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](/runtime/github-mcp)).

## 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.

<Note>
  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.
</Note>