If your AI agent cannot connect to a business system and the log says Incompatible auth server: does not support dynamic client registration, the fix in 2026 is usually not to find a server that supports it. The 2026-07-28 MCP specification deprecated Dynamic Client Registration in favour of Client ID Metadata Documents. The error names a route that is being retired, not a defect you should chase.
What changed in MCP client registration on 28 July 2026?
MCP had a hard problem from the start: an agent and a business system that have never met still need to complete an OAuth flow. The original answer was Dynamic Client Registration, RFC 7591. The client POSTs its name and redirect URIs to a registration endpoint at runtime, the authorization server creates a record, and hands back a fresh client_id.
That worked in demos and scaled badly. Every install of the same desktop client becomes a separate row. The /register endpoint is open to anyone, which makes it a flood target, and the name on the form is whatever the client typed. The 2026-07-28 spec resolved this by demoting DCR and promoting a mechanism that inverts the direction of trust.
The client registration chapter now lists three mechanisms and a strict priority order. Clients should use pre-registered credentials first, then Client ID Metadata Documents if the authorization server advertises support, then DCR as a fallback, then prompt the user. The requirement levels moved too. CIMD is a SHOULD, DCR is a MAY, and the spec page carries an explicit warning that DCR is deprecated and new implementations should not adopt it.
Why does "does not support dynamic client registration" keep appearing?
Because a lot of client tooling still treats DCR as the only automatic path, and a lot of authorization servers never supported it. The combination produces a confident error message pointing at the wrong party.
The pattern is easy to find in the open. Claude Code logged an issue about MCP servers that do not implement DCR back in July 2025, and reports since then name Slack, the GitHub Copilot MCP endpoint, Box, Azure DevOps and AWS Cognito as authorization servers that hit it. We saw both halves of it in our own tooling this week: one server returning "does not support dynamic client registration", another rejecting the registration POST outright with an HTTP 403.
Read those two failures correctly and they say different things. The first means the authorization server never exposed a registration_endpoint in its metadata. The second means it exposed one and refuses to serve you, usually because registration is restricted to administrators. Neither is fixed by retrying. Both are fixed by choosing a different registration mechanism.
What is a Client ID Metadata Document, exactly?
A CIMD is a static JSON file the client hosts on its own domain, and the file's HTTPS URL is the client_id. Instead of the client pushing a registration into the server's database, the server pulls the client's identity from a URL it can verify. The mechanism comes from SEP-991 and tracks the IETF draft OAuth Client ID Metadata Document.
The spec's minimum is small. The document must be served over https, the URL must contain a path component, and the file must include client_id, client_name and redirect_uris, with the client_id inside the file matching the URL it was fetched from exactly. A public client adds token_endpoint_auth_method: none and relies on PKCE. A confidential client sets private_key_jwt and publishes a jwks_uri, which removes the shared secret from the relationship entirely.
Three consequences are worth holding on to. First, impersonation is blocked by the redirect_uris list: a phishing site can quote someone else's client_id URL, but the authorization server fetches the real document, sees that the attacker's callback is not listed, and aborts. Second, the authorization server advertises support with client_id_metadata_document_supported: true in its OAuth metadata, so a client can detect the capability rather than guess. Third, and least discussed, CIMD client_ids are portable across authorization servers. DCR credentials are not. The same release bound client credentials to the issuer that minted them, so if a vendor moves its authorization server, every DCR-registered client has to re-register while every CIMD client keeps working.
Which authorization servers support CIMD today?
Adoption is real but uneven, and it splits along a line that matters more than the technology. Developer-platform identity providers have shipped it. Enterprise identity providers have not.
- Shipped or shipping. Clerk's OAuth provider added CIMD in beta on 6 August 2026, with a dashboard tab for allowing clients by their client_id URL and a switch for whether unknown clients may connect at all. Better Auth ships it as a CIMD plugin. Stytch and WorkOS have published implementations. Auth0 has written the model up in detail but has not shipped it.
- Not available. Microsoft Entra ID supports neither CIMD nor DCR. Okta supports DCR and has not shipped CIMD.
That asymmetry is the practical story. If the system your agent needs to reach sits behind a developer-platform IdP, CIMD is available now and the migration is one static file. If it sits behind the identity provider a Dutch or Belgian company actually runs, neither automatic option exists.
Why does Microsoft Entra ID refuse both?
Not by oversight. A design note on MCP authentication with Entra sets out the reasoning, and it is coherent even if it is inconvenient. Entra's model is that an administrator can see every app registration in the tenant, who created it, what it may do and when it last signed in. Both automatic mechanisms break that in different ways: DCR creates app objects nobody approved, and CIMD creates no server-side object at all, so there is nothing for Conditional Access to evaluate and nothing in the audit trail beyond a fetch of an external URL that can change afterwards.
The note also lists CIMD's own costs, and they are the ones an architect should weigh. Fetching a stranger's URL turns the authorization server into an HTTP client, which is a server-side request forgery surface and a potential DDoS amplifier; the MCP security considerations tell implementers to harden that fetcher with internal-IP blocking, tight timeouts and a response size limit. Localhost redirect URIs cannot distinguish between two processes on the same port. And the underlying IETF document is still an Internet-Draft, not a ratified RFC, which is a normal reason for a large identity provider to wait.
Entra's bridge is pre-registration, plus pre-registering the most common clients itself. That is option one on the spec's own priority list, so a company following it is not out of compliance. It is simply doing the work by hand.
Which registration route should you pick?
Four states, and the answer follows from which side of the connection you own.
- You are buying an agent that connects to a SaaS system. Check whether the vendor's authorization server advertises client_id_metadata_document_supported. If it does not and there is no registration_endpoint either, the answer is a pre-registered client ID, and you should ask the vendor for one before signing rather than after the first failed connection.
- You are building an MCP client. Publish a CIMD at a stable URL on your own domain and keep DCR as a fallback for now. This is a small, additive change: a static JSON file and a code path that prefers a URL client_id when the server advertises support.
- You are exposing your own system as an MCP server behind Entra or Okta. Pre-registration is your route today. Document the client IDs you allow, and treat that list as an access-control artefact rather than a configuration detail.
- You are running your own authorization server. Enable CIMD, advertise it, and harden the fetcher first. Give yourself an admission policy so you can decide whether unknown clients may connect, which is exactly the control Clerk shipped alongside the feature.
Whatever you pick, stop persisting DCR credentials across authorization servers. That is now explicitly forbidden, and it is the kind of thing that works quietly for a year and then breaks on a vendor migration.
What this means for a Dutch or Belgian company
For a company of roughly 20 to 250 people running Microsoft 365, the practical answer is short: your identity provider is Entra, so the automatic routes are not open to you, and every MCP connection you add is an administrator task. That is not a workaround. It is the governance model you already apply to every other app registration, extended to agents.
Plan for it rather than discovering it. When you scope an agent that has to reach an ERP or bookkeeping package, put "which client IDs does this need, and who approves them" in the same conversation as the permissions the server may exercise. The two questions have the same owner and the same review cycle, and both belong in the integration design rather than in a support ticket after go-live.
On timing: the 2026-07-28 release introduced a formal deprecation policy with a twelve-month minimum window, which puts the earliest possible removal of DCR in the second half of 2027 at the soonest, and only in a future spec revision. There is no emergency. There is a direction, and building new integrations on a mechanism the specification has already marked for removal is a choice you will pay for later rather than now.
If you are still catching up on what else moved in that release, the stateless core and the extensions framework changed more of the protocol than authorization did, and the two migrations are usually worth doing together. If you would rather have someone map your own connections against this, that is the sort of thing an agent integration engagement starts with.
