Skip to content
autonym.dev
ContentsHide contents

MCP reference

The MCP binding (B3) targets MCP revision 2026-07-28, using stateless Streamable HTTP and server/discover, with server name autonym. There is no initialisation handshake and no Mcp-Session-Id; each request carries its protocol version and capabilities in _meta. Every request needs an Mcp-Method header, and tools/call, resources/read and prompts/get also need Mcp-Name; a header that disagrees with the body fails. Roots, Sampling and Logging are not used. This is a specified interface; the reference service does not expose it yet.

Tools

Each tool is an operation of the agent surface (A7.1), under the same name. The complete input and output definitions are in the generated tool definitions.

Tool Authority Accounting
get_grant The authenticated current grant only No read
list_domains Read grant No read; eligible granted keys only, no counts
get_context Read grant One atomic counted read
propose_entry Separate contribution grant One accepted unique event
confirm_entry Contribution grant with confirmation permission Returns a first-party review URL
withdraw_proposal The contributor's own proposal No read

get_context returns the signed disclosure in structured content and the same JSON as text, and there is no unsigned alternative. The provider rechecks the stored grant on every call. confirm_entry always returns review_required with a first-party review URL; the person confirms the exact statement in their own app, and sensitive acceptance is always first-party (A7.2).

Resource and prompt

autonym://context/{domain} is a single-domain context request under the same grant and compiler. It counts as one read and returns the signed JSON object. No grant means no read. The tool list is fixed and public; grant-dependent resource lists are private. Resource reads use ttlMs: 0 and cacheScope: "private", and no transport hint extends the signed validity.

autonym_briefing reads agent and communication at L1 in one counted read, and both domains must be granted. It returns a text message containing the signed disclosure JSON. Any summary is labelled as derived from it and cannot add entries or extend validity.

Errors

A token that fails verification is refused before any JSON-RPC processing, with status 401 and the challenge pointing at /.well-known/oauth-protected-resource/mcp. Every registered error code then reaches an agent in exactly one form (B3.4):

  • dpop_required, dpop_invalid, payload_too_large, rate_limited and not_ready as an HTTP response with the registered status and the Problem Details body, before JSON-RPC processing;
  • internal_error as JSON-RPC error -32603 with the Problem Details object as data;
  • the grant, request and proposal codes as a tool result with isError: true whose only content is the Problem Details JSON, or, from a method other than tools/call, as JSON-RPC error -32602;
  • and the entry limit and the first-party session and sign-in codes never reach an agent.

An unknown tool, resource or prompt gets the JSON-RPC protocol error MCP defines. No error message carries a submitted value. See Errors.

Read the full MCP binding or inspect synthetic examples. The example proofs are placeholders, not valid signatures.

Written against edition 1.0-draft-1: B3 MCP binding