Adoption records

Model Context Protocol

Version pinned

MCP specification revision 2026-07-28, read on 4 October 2026. Its versioning page names it the current protocol version. A current revision can still receive backwards-compatible changes; a later revision is taken only through a change entry.

What is taken

• The stateless model of this revision: no initialise handshake and no Mcp-Session-Id; protocol version and capabilities in _meta; server/discover (B3.1).
• Streamable HTTP with the Mcp-Method and Mcp-Name headers validated against the body (B3.1).
• Tools with input and output schemas, resources and prompts, and the revision's list-cache fields (B3.2, B3.3).
• Tool execution errors and JSON-RPC error responses as the revision defines them, carrying the registered Problem Details object (B3.4).
• The MCP authorisation flow over OAuth: protected-resource metadata and Client ID Metadata Documents for unknown clients (A6.1; see the OAuth record).

Why

Assistants reach external context through MCP. Binding the A7 agent surface to it lets an assistant connect to a record without bespoke integration.

What is extended

A fixed, public tool set (get_grant, list_domains, get_context, propose_entry, confirm_entry, withdraw_proposal), the autonym://context/{domain} resource and the autonym_briefing prompt, all returning the A5 signed disclosure; exact-statement confirmation through the first-party app (A7.2). There is no generic record access.

What is replaced or not used

Roots, Sampling and Logging are not adopted. Legacy protocol revisions are not supported unless separately declared and tested (B3.1).

Deviations

• Revision 2026-07-28 deprecates Dynamic Client Registration in favour of Client ID Metadata Documents. A6.1 keeps Client ID Metadata Documents as the primary mechanism and RFC 7591 registration available to any client, MCP clients included, for compatibility.
• The revision's authorisation section cites OAuth 2.1 draft revision 13 and Client ID Metadata Document draft revision 00; the OAuth record pins revisions 16 and 02. Both pairs were compared. From revision 13 to 16, OAuth 2.1 removes PKCE plain, has the authorisation server send iss in every authorisation response, mentions pushed authorisation requests in its authorisation endpoint section, adds guidance on JWT client authentication and on consent phishing, gathers its value sizes into one section and clarifies its error responses and repeated parameters; A6.3 already requires S256 only and iss, so a client that follows revision 13 and meets A6 is unaffected. From revision 00 to 02, the Client ID Metadata Document draft lists the client identifier URL's rules (https, a path, no user information, fragment or dot segments), compares it as a simple string without port normalisation, forbids shared-secret authentication and private key material in the document, recommends client authentication more strongly, limits the loopback exception to its SSRF rules to development and testing, and adds privacy considerations. A6.1 takes revision 02; a revision 00 document that follows those rules is accepted.
• Revision 2026-07-28 has an MCP client send its access token as Authorization: Bearer and does not list RFC 9449. Open Personal Context binds every access token to a DPoP key and accepts none as Bearer (A6.3), so an MCP client that cannot send a DPoP proof cannot obtain or use a token. The protected-resource metadata of <origin>/mcp says so with dpop_bound_access_tokens_required (A6.1).

Conformance checks

TRANSPORT-01, CORE-01, SIGN-01 and LOG-01 in the conformance manifest, with runtime evidence pending.

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