Docs / planning: Atomic as an MCP server

[joepio]

Related Issues

Planning only. Related: #1310 (OIDC/OAuth retarget — relevant, not the MCP auth path), #1275 (issued agents / Atomic as AS — the remote-auth path).

Checklist

• Add changelog entry linking to issue, describe API changes
• Add or update tests if needed
• Update docs if needed

What this is

A proposal for exposing Atomic as an MCP server (Cursor, Claude Desktop, etc.), not another in-app MCP client. No protocol or server code.

Decision

• Local stdio MCP signs writes as the user's Agent. This is v1, and it is the "writes happen client-side" path.
• Remote Streamable HTTP starts read-only. Writes, if they come, are an issued agent the node holds — the same shape as unattended plugins — never the user's root, never an OAuth Bearer on /commit.
• Do not grow a fifth tool list: extract the headless verbs from useAtomicTools.ts. Compact JSON-AD stays the wire dialect; format=compact on the server is the Rust path.
• Retarget OIDC / OAuth after DID and local-first #1310 (Atomic as OIDC relying party) is for human login. MCP HTTP clients speak OAuth 2.1; they need Atomic as an authorization server (Issued agents as app keys #1275's shape), with the MCP server as a resource server (RFC 9728). D1 still holds.

See planning/mcp-endpoint.md.