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_limitedandnot_readyas an HTTP response with the registered status and the Problem Details body, before JSON-RPC processing;internal_erroras JSON-RPC error-32603with the Problem Details object asdata;- the grant, request and proposal codes as a tool result with
isError: truewhose only content is the Problem Details JSON, or, from a method other thantools/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