Connect an assistant
Not released. This page describes planned behaviour as designed for edition 1.0-draft-1 of Open Personal Context. The specification is the normative reference, and what is described here may change before any release.
An MCP client that supports the MCP authorisation specification and DPoP-bound tokens is intended
to connect to an Autonym server, hosted or local. Every access token Autonym issues is DPoP-bound,
so a client that can only send a Bearer token, as the MCP specification describes, cannot obtain or
use one. A server is intended to publish its metadata at /.well-known/autonym and its MCP endpoint at
/mcp.
Which clients work in practice depends on the client and its connection options; tested
combinations will be published as they are confirmed, and none is confirmed yet.
A remote connector and a locally configured server are different connection paths with different setup. A local address is not a universal instruction: a client that connects from its vendor's own infrastructure cannot reach a server on your machine.
The connection
The MCP binding (B3) targets MCP revision 2026-07-28 over stateless Streamable HTTP, with server
name autonym. There is no initialisation handshake and no session header, and the server
implements server/discover. The binding specifies Streamable HTTP for a hosted server and a local
one alike.
Authorisation
The MCP endpoint is its own protected resource. A request without a token is answered with a
challenge pointing at its metadata, /.well-known/oauth-protected-resource/mcp (A6.1), which names
the authorisation server and requires DPoP-bound tokens signed with ES256.
A client registers through a Client ID Metadata Document, or through RFC 7591 dynamic registration,
which stays available to every client. It then uses the authorisation code flow with PKCE S256 and
the resource indicator of the MCP endpoint. A token issued for /mcp is valid only there.
A client's class comes from its registration evidence, never from its own assertion (A2). A client
is assistant only when the operator's allowlist names it, and never when it registers a loopback
redirect URI. Any other public client is assistant_unverified: it may read and propose, but not
confirm, keep a copy or delegate, a grant to it lasts at most 30 days, and the person is told at
consent that it is unverified.
What the assistant sees
After the grant, the assistant has six tools, one resource template and one prompt. The
autonym_briefing prompt reads agent and communication at L1 in one counted read, and both
domains must be granted (A7.3). It returns the signed disclosure as JSON in a text message when the
client uses the prompt; any human-readable summary is labelled as derived from that object and adds nothing to it. What the assistant does with the
context is the assistant's decision, so responses can still vary. See the
MCP reference.
Proposing entries
Proposing needs a contribution grant, separate from any read grant. When the person tells the
assistant something worth keeping, the assistant calls propose_entry with the domain, key and
value, as one event. The proposal waits in the review queue until the person confirms it.
confirm_entry never confirms anything on the assistant's say-so: it returns a first-party review
URL (A7.2), and the person confirms the exact statement in their own app after signing in.
Written against edition 1.0-draft-1: B3 MCP binding