MCP Dynamic Client Registration: Choose the Registration Model

MCP authorization supports more than one client-registration approach. A deployment can preregister clients or use RFC 7591 Dynamic Client Registration. Client ID Metadata Documents provide another approach where supported. Each choice changes who controls redirect URIs and metadata. It also changes who controls credentials and revocation.

This decision belongs to the MCP authorization plane. It does not authorize a later request to an LLM, and it does not secure local STDIO sessions.

TL;DR

• Use preregistration when the client set is small and tightly administered.
• Use RFC 7591 only with bounded registration access and metadata validation, backed by lifecycle controls.
• Evaluate Client ID Metadata Documents through URL ownership and transport security. Include cache behavior and redirect-URI matching.
• Apply a separate identity and data policy when the application later sends an authenticated HTTP request to an LLM.

MCP offers three registration approaches

The MCP authorization specification describes client-registration approaches for MCP deployments. RFC 7591 defines OAuth 2.0 Dynamic Client Registration, including registration requests and client metadata.

Write a decision record before enabling one approach. Name the MCP client type and authorization server. Add deployment scale and trust model. Include redirect patterns and credential method. Record the lifecycle owner and rejection criteria.

My position is that open registration is an operational liability unless the server can explain who may register and how stale clients disappear, including which metadata is accepted. A green "registered" message on a terminal is the start of the control, not the end.

Preregistration gives administrators the narrowest inventory

Preregistration works well when client identities and redirect URIs are known before deployment. The authorization team creates the client record through an administrative process and supplies the required identifier or credentials.

Preserve the request and approving owner. Record approved redirects and client type. Include the authentication method and creation time, along with the expiry or review date. Test that an unregistered client fails and that a near-match redirect URI is rejected.

The trade-off is administration. Desktop tools and distributed clients can create pressure for broad wildcard redirects or shared identifiers. Reject those shortcuts when they erase client attribution or redirect control.

RFC 7591 needs a registration policy

Dynamic registration accepts client metadata through an endpoint. Decide whether the endpoint is open or protected by an initial access token. Another trust mechanism can also limit access. Record rate limits and abuse handling.

Validate redirect URIs exactly under the applicable OAuth rules. Check the client type and token-endpoint authentication method. Restrict unsupported grant types. Reject unknown fields when they affect security, and preserve the accepted metadata version.

Protect registration access tokens as credentials. Define issuance and rotation. Document storage and use monitoring. Include revocation. A registration endpoint should also resist duplicate names and metadata flooding. It should reject malicious logo or policy URLs and oversized values.

RFC 7591 also describes client registration responses. Keep the issued client identifier and relevant metadata under the same lifecycle record without exposing secrets in logs.

Client ID Metadata Documents shift trust to a URL

With Client ID Metadata Documents, the client identifier can point to metadata published at a URL. The authorization server must retrieve and validate that document according to the MCP specification and applicable profile.

Test HTTPS requirements and hostname ownership. Check redirects during metadata retrieval and cache expiry. Verify document size and content type, plus exact redirect-URI matching. Decide what happens when the document changes after consent or becomes unavailable.

Pin the metadata used for an authorization decision through a checksum or retained version where permitted. A later investigator should be able to show which redirect list and client properties were evaluated at that time.

Fail closed on metadata and redirect errors

Build negative tests before rollout. Use an unapproved redirect. Serve malformed metadata. Change a hostname after registration. Expire an access token. Remove the client. Repeat a registration request under a different tenant.

The expected result should be explicit for every case. Preserve the request reference and validation step. Record the decision and reason code, along with the time. Avoid returning secrets or unnecessary policy detail in errors.

The MCP OAuth authorization security guide covers the wider authorization flow. Registration is one input to that flow, not proof that the user approved a tool call or that a resource server enforced it.

Keep MCP and LLM routes separate

MCP registration identifies a client to an authorization server. MCP tool access is enforced by the MCP authorization and resource components. Local STDIO has no HTTP registration exchange and requires host-level controls.

If the MCP-enabled application later sends context to an LLM, evaluate that model request under a separate route policy. Bind the authenticated user or workload and approved use case. Include the data classification and model destination. Do not treat an MCP client identifier as complete user identity.

The AI agent authorization guide explains the broader delegation record. Join the MCP authorization event and LLM route event through a stable workflow identifier while keeping their policies distinct.

DeepInspect

DeepInspect can enforce policy when an MCP-enabled application sends an authenticated HTTP request to an LLM through the managed route. The decision can use application-supplied identity and role. It can also use data classification, use case, model destination, and policy version.

MCP client registration and tool authorization stay outside that boundary. Protocol messages and local STDIO stay outside it too. Keep the evidence chains joined by a workflow identifier without claiming one control replaces the other.

Book a technical deep dive at deepinspect.ai.