11 September 2026

An assistant can say who it is without registering

Connecting an assistant used to mean it registered itself here first, and Claude made a new client every time somebody connected. It can now identify itself with a metadata document instead — an address it publishes, which this server reads — which is what the MCP specification prefers. Registration still works for clients that do not.

The approval page changed with it. It now says where a client’s description was published, and warns when the only place it can be sent back to is a program on your own computer, because anything running there can ask to be sent there too.

There are three ways a client can tell an authorization server who it is: register itself, be configured by hand, or publish a document at an address and use that address as its name. This server now reads the third.

What a metadata document is

Its client_id is an https URL. The document at that URL says what the client is called, where it may be sent back to, and optionally what it is asking for. The server fetches it while you are authorizing rather than keeping a registration of its own. It is draft-ietf-oauth-client-id-metadata-document-00, as the MCP authorization spec of 2025-11-25 profiles it, and Claude prefers it as soon as a server says it is supported.

What it replaces

Dynamic client registration (RFC 7591) mints a client here on every connection. Reconnecting the same assistant made another one, so the table held five rows all called "Claude" — none of which could be told from the others, or from a stranger who had registered under the same name. A published document has one address, and the address is the identity: what it says can change, what it is cannot. Registration still works, because clients that only do that exist.

What the server will and will not fetch

A client_id here is a URL handed over by a stranger and then fetched by our server, which is a request forgery waiting to be written badly. So: https only; a path, because a bare origin identifies a host rather than a client and anyone who can serve a file at a domain root would otherwise speak for the whole domain; no fragment and no credentials; the URL in canonical form, and repeated inside the document it names. Redirects are not followed, the address is resolved and refused if it is private, there is a timeout inside the one the client gives the whole endpoint, a 64 KB cap, and the body has to be JSON before it is parsed. Answers are held for an hour at most and failures for a minute, so a client_id that 404s does not turn every press of the button into another fetch.

What the approval page says about it

Where the client's description was published, and that it was read just now. And a warning when every address it may be sent back to is a program on your own machine: the document is published by the real client, but binding a port is all it takes to catch the code that comes back, and no page can tell two programs on your computer apart. That one is yours to judge.