MCP authorization rewrite — Client ID Metadata Documents — What does it mean?
The news. By November 8, 2026, the MCP project had merged a rewrite of its authorization guide for both the 2026-07-28 specification and the draft copy. The change replaces a vendor-specific walkthrough with provider-neutral guidance, updates the TypeScript, Python and C# samples to v2 SDKs, and incorporates a security review. The pull request changed 2 files, with 1,082 additions and 1,848 deletions. Read the pull request →
Picture the authorization server as a venue front desk and the MCP client as a visitor it has never met. Under the old default the visitor filled in a form and the desk handed back a badge number, then wrote it in a ledger. That is Dynamic Client Registration: the client posts its metadata to the authorization server's registration_endpoint and receives a client ID. A badge number from one desk means nothing at another desk, so the guide tells clients to keep such credentials by issuer and never use them with a different one.
Under the new default the visitor skips the form and hands over its own website address. With a Client ID Metadata Document, the client's client_id is an HTTPS URL, and the JSON document hosted at that URL is the registration. The desk reads the page when an authorization request arrives and checks it. The guide's rules are short: the URL must use https and contain a path, the document must contain at least client_id, client_name and redirect_uris, and its client_id must match the URL exactly. A server announces support with client_id_metadata_document_supported: true. This sits inside the flow described in MCP, Two Ways.
| Approach | When the guide says to use it |
|---|---|
| Pre-registration | The client already has credentials for this authorization server. |
| Client ID Metadata Documents | Client and server have no prior relationship. The guide calls this the most common case. |
| Dynamic Client Registration | Deprecated. Only for authorization servers that do not support Client ID Metadata Documents. |
A client that supports all three should try them in the table's order, and if none is available it should ask the user to enter the client information. Because the URL belongs to the client, the same client ID works with every authorization server that supports CIMD, and the client does not register again if the MCP server changes authorization servers. The old route had a cost on the server side too: the guide warns that anyone can register with an open registration_endpoint, so servers needed controls such as trusted hosts and rate limits. This explainer does not cover how a server should limit the fetches CIMD introduces; the guide points builders to its Security Best Practices page for the attack classes involved, which the attack-surface step previews.
Take a client that works with 3 authorization servers (illustrative numbers). With DCR it makes 3 registration calls and stores 3 client IDs, one per issuer, because each ID is valid only at the server that issued it. With CIMD it hosts 1 document and uses 1 client ID everywhere, and each server fetches the same page. 3 registrations and 3 stored credentials become 1 URL and 0 registration calls. The guide states the one-ID-everywhere behavior; the count of 3 is chosen only to show the arithmetic.
Goes deeper in: AI Agents → Tool Use & Function Calling → MCP, Two Ways
Related explainers
- MCP SEP-2468 — the iss parameter — after registration, the client must also check which server answered
- MCP authorization rewrite — JWT audience, issuer and scope checks — the server-side half: what the MCP server checks on each token