Dynamic client registration is the part of MCP's authorization story marked SHOULD rather than MUST, and that distinction is the whole decision. The specification requires authorization servers to implement OAuth 2.1, requires MCP servers to implement protected resource metadata under RFC 9728, requires clients to use that metadata to discover the authorization server, and requires authorization servers to publish authorization server metadata under RFC 8414. Registration under RFC 7591 sits one level down as a SHOULD for clients and authorization servers, and the spec names exactly two things to do instead when a server skips it.
| Requirement | Level | Applies to |
|---|---|---|
| OAuth 2.1, with appropriate measures for confidential and public clients | MUST | Authorization servers |
| OAuth 2.0 Protected Resource Metadata, RFC 9728 | MUST | MCP servers |
| Using protected resource metadata for authorization server discovery | MUST | MCP clients |
| OAuth 2.0 Authorization Server Metadata, RFC 8414 | MUST | Authorization servers |
| OAuth 2.0 Dynamic Client Registration, RFC 7591 | SHOULD | MCP clients and authorization servers |
The four MUST items are what makes a client able to find your authorization server at all, and getting the discovery document's address wrong is a more common failure than anything registration causes. RFC 9728 discovery is path-specific rather than origin-wide, so a resource served at one path is described at a well-known address that includes that path.
The specification's case for dynamic client registration is about clients meeting servers they have never seen. A client cannot know every MCP server and every authorization server in advance, manual registration puts work on the user before anything can happen, and registration gives an authorization server a place to apply its own policy rather than forcing every integration through a support request. The point is obtaining a client id without user interaction, which is what makes adding a new server a single step rather than a project.
Any authorization servers that do not support Dynamic Client Registration need to provide alternative ways to obtain a client ID (and, if applicable, client credentials).
Connecting a remote MCP server to Claude, ChatGPT or Cursor is the same URL in all three. What differs is where the URL goes, whether the client can complete a browser sign-in, and what counts as proof that it worked.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The specification then names the two options a client is left with. It can hardcode a client id, and credentials where they apply, specifically for use with that one authorization server. Or it can present a screen where the user enters those details themselves, after registering an OAuth client through a configuration interface the server provides. Both are legitimate, and both move work from the protocol onto either the client's release cycle or the user's afternoon.
Durable storage, for the registrations and nothing else. Authorization codes and access tokens are short-lived and can live in a store with expiry; a client registration has to survive restarts and deploys, because a client that gets an unknown-client error after your next release has no path back except registering again, and what the user sees is a login that loops. A stored registration holds the issued client id, a secret for confidential clients or nothing for public clients using PKCE, the redirect URIs, the grant types, and the client metadata as it was registered.
One storage detail is worth deciding up front: keep the fields you query on out of the metadata blob. Redirect URIs and grant types are read on every authorization request, and a query that has to reach into a free-form document to find them is a query that gets slower and harder to index as the metadata grows. Store the blob for fidelity and store the queried fields beside it.
Dynamic client registration is not authentication and not authorisation. It hands out an identifier for a piece of software; it does not decide who may read anything. A registered client still has to send a user through the authorization flow, that user still has to be somebody with access, and the token that comes back is still scoped to them. Treating registration as a security boundary is the mistake to avoid here — the boundary is the authorization step and the consent screen in front of it.
No. The 2025-06-18 authorization specification says MCP clients and authorization servers SHOULD support the OAuth 2.0 Dynamic Client Registration Protocol, RFC 7591. The MUST-level requirements are OAuth 2.1 on the authorization server, protected resource metadata under RFC 9728 on the MCP server, authorization server metadata under RFC 8414, and clients using that metadata for discovery.
The specification names two alternatives. The client can hardcode a client id, and client credentials if the server issues them, for use with that particular authorization server. Or it can show the user a screen for entering those details after the user has registered an OAuth client themselves, typically through a configuration interface the server hosts. Both put the work somewhere other than the protocol.
They have to survive restarts and deploys, which in practice means durable storage. Authorization codes and tokens are different: they are short-lived and expiring, so an in-memory or cache-backed store with a time to live is appropriate for them. Mixing the two up is the failure to avoid: registrations that quietly disappear, and clients that loop through a login they have already completed.
No. It lets anyone obtain a client identifier, which is not access to anything. Every request still needs an access token, that token is issued only after a real user completes the authorization flow, and the server still checks the token's audience and the user's permissions. If registration feels like an open door, the thing to examine is what your authorization step checks, not the registration endpoint.
The server is the same in both. What differs is which layers the client implements: how it connects, how it discovers the authorisation server, which of the three capabilities it lists, and whether it reads the hints on each tool.
The Streamable HTTP transport changed in revision 2026-07-28: the GET stream endpoint and protocol-level sessions are gone. Here is what a request looks like now and what stops working.
