B3. MCP binding

spec 1.0-draft-1

Status: normative. Binds MCP revision 2026-07-28. Document version 1.0-draft-1.

This binding carries the A7 agent surface, and the A5 signed disclosure, over the Model Context Protocol. It binds MCP revision 2026-07-28; the MCP adoption record says what is taken from it, what is extended and what is not used.

B3.1 Transport

The normative target is MCP revision 2026-07-28, Streamable HTTP, server name autonym. This specifies an implementation requirement; the reference repository does not yet expose this surface.

The server is stateless, with no initialise/initialized handshake or Mcp-Session-Id, and MUST implement server/discover. Requests carry protocol version/capabilities in _meta. Require Mcp-Method on every request and Mcp-Name on tools/call, resources/read and prompts/get. Decode and validate headers against the body under the transport rules; mismatches fail. Roots, Sampling and Logging are not adopted. Legacy revisions are unsupported unless separately declared and tested; no legacy compatibility is claimed by this draft.

B3.2 Tools

The complete input and output definitions are generated in tools.json. Each A7.1 operation is an MCP tool of the same name.

Tool lists are fixed and public. Grant-dependent resource lists are private. Use the revision's list-cache fields. Resource reads use ttlMs:0 and cacheScope:"private"; these transport hints never extend signed context validity.

get_context returns the A5 signed disclosure in structured content and the same JSON as text content. Errors follow B3.4.

B3.3 Resources and prompts

autonym://context/{domain} maps to a single-domain context request under the same grant and compiler, counts as one read, and returns the signed JSON object. No grant means no read.

The autonym_briefing prompt carries the A7.3 briefing. It returns a text message containing the signed disclosure JSON.

B3.4 Errors

Every code in the registry has exactly one row below: a form in which it reaches an agent, carrying the same Problem Details object as B4.3, or the last row, of codes no agent operation raises. A request that is not a valid JSON-RPC message, fails the MCP request schema or names an unknown tool, resource or prompt gets the JSON-RPC protocol error MCP defines, not a registered code. Every JSON-RPC error message is the registered title or, for a protocol error, fixed text; neither carries a submitted value or validation detail. A token that fails verification at the MCP endpoint fails RFC 6750 invalid_token as A6.3 says, before any JSON-RPC processing: status 401 with the A6.1 challenge carrying that code. It is not a registered code, so it has no row below.

Form	Codes
HTTP response on the MCP endpoint, before any JSON-RPC processing, with the registered status and the Problem Details body. A `401` also carries the A6.1 challenge and a `429` carries `Retry-After`	`dpop_required`, `dpop_invalid`, `payload_too_large`, `rate_limited`, `not_ready`
JSON-RPC error `-32603` (Internal error) with the Problem Details object as `data`	`internal_error`
From `tools/call`, a tool result with `isError:true` whose only content is the Problem Details JSON as text, without structured content, because each tool's output schema describes its successful result. From any other method, such as `resources/read`, `prompts/get` or a grant-dependent `resources/list`, a JSON-RPC error `-32602` (Invalid params) with the Problem Details object as `data`	`invalid_scope`, `purpose_missing`, `invalid_request`, `not_found`, `idempotency_conflict`, `domain_not_granted`, `grant_revoked`, `grant_expired`, `grant_exhausted`, `safety_write_forbidden`, `inference_forbidden`, `proposal_not_found`, `proposal_decided`, `value_rejected`, `capability_not_granted`, `advertising_ineligible`, `client_suspended`
None: no agent operation adds an entry in this version (A4.1, A7.1, A14), and the session, CSRF, re-authentication, sign-in and sign-up refusals answer only the person's own first-party requests (A15.3), so these refusals reach only the person's own operations, never an agent	`entry_limit_reached`, `session_required`, `csrf_invalid`, `reauthentication_required`, `sign_in_failed`, `signup_unavailable`

These forms follow the MCP error handling for tools, resources and prompts: a tool reports an input or business failure in its result so that the model can recover, a resource or prompt reports it as a JSON-RPC error, and a tool's structured content always matches its output schema.

Checks: TRANSPORT-01, CORE-01, SIGN-01, LOG-01.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.