Remote MCP servers make authorization awkward in a way local MCP servers usually do not. With stdio, the server often runs on the user’s machine and can read local credentials. With HTTP, the server has to answer three questions before it hands anything over: which client is asking, which user approved the request, and which resource the token is for.

Client ID metadata answers the first question. An MCP client can identify itself with an HTTPS URL that points to a small JSON document. No dashboard. No per-server app setup. The authorization server fetches the document, checks it, and uses it during OAuth.

The core idea

OAuth needs a client_id. In a typical SaaS API, you get one by registering an app in a developer console, adding redirect URIs, copying the generated ID, and shipping that configuration with your client.

That is a poor fit for MCP. The protocol assumes many clients may connect to many servers, often with no prior relationship. A desktop agent, IDE, CLI, or hosted agent runner should not need a custom registration step for every MCP server it might touch.

Client ID metadata turns the model around. The client hosts its own metadata file. The URL of that file becomes the client_id.

A minimal document looks like this:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "redirect_uris": ["http://127.0.0.1:3000/callback"]
}

The exact-match rule matters. If the client sends https://app.example.com/oauth/client-metadata.json as its ID, the fetched document must contain that same value in client_id. The authorization server should also reject the request if the redirect URI is not listed in the document.

How the flow works

A protected HTTP MCP server behaves like an OAuth resource server. When a client calls it without a token, the server returns 401 Unauthorized and points the client to protected resource metadata. That metadata tells the client which authorization server protects the resource.

The client then discovers the authorization server metadata. If the authorization server says it supports client ID metadata documents, the client can start the OAuth request with its metadata URL as the client_id.

The flow is straightforward:

  1. A user connects an MCP client to a protected remote MCP server.
  2. The MCP server returns a 401 response with resource metadata information.
  3. The client discovers the authorization server and checks its supported features.
  4. The client sends an OAuth authorization request with client_id=https://client.example.com/metadata.json.
  5. The authorization server fetches that URL.
  6. The server validates the JSON, checks the redirect URI, and shows a consent screen using the declared client name.
  7. If the user approves, the authorization server issues an authorization code, then an access token.
  8. The MCP client calls the MCP server with Authorization: Bearer <token>.

The practical win is portability. The same client identity document can work across compatible authorization servers. The client does not need a different client ID from each server unless that server requires pre-registration.

Why AI agents need this

AI agents are not one app connecting to one API. They are runtimes that may connect to search, databases, files, browsers, SaaS tools, and internal systems through MCP. If every connection requires a human to create an app registration, remote MCP becomes painful fast.

Client ID metadata gives servers something inspectable. A consent screen can show a real client name, homepage, logo, and redirect URI set instead of an opaque random string. Servers can cache the metadata and apply their own policies. Clients can support more MCP servers without keeping a drawer full of one-off registrations.

It also cleans up the story around OAuth Dynamic Client Registration. Earlier MCP authorization designs leaned harder on dynamic registration, where a client posts metadata to a registration endpoint and receives credentials. That can still work, but the current MCP spec treats it as a fallback for older authorization servers. New implementations should prefer client ID metadata when it is available.

Client ID metadata vs. dynamic registration

Dynamic registration creates server-specific client credentials. The client has to store registration state for each authorization server and avoid reusing credentials across servers. If the MCP server changes which authorization server protects it, the client may need to register again.

Client ID metadata is different. The client identity is the HTTPS URL itself. Any authorization server that supports the mechanism can fetch and validate the same document.

There is still policy involved. A server may reject unknown clients, require certain domains, or run extra checks before approval. But the base identity does not have to be minted separately for every server.

Pre-registration still makes sense when there is already a relationship. Enterprise MCP deployments may want approved clients only, fixed redirect URIs, private client credentials, or central identity provider rules. For public interoperability, client ID metadata is the better default.

MCP client ID metadata in practice

If you are building an MCP client, host a stable metadata document over HTTPS. Include a human-readable client_name, accurate redirect_uris, and any optional fields that help users and servers understand the client. Serve valid JSON from a URL you control.

If you are building an authorization server for MCP, advertise support with client_id_metadata_document_supported: true in your authorization server metadata. When a request arrives with a URL-shaped client ID, fetch the document, require an exact client_id match, validate the redirect URI, and return clear OAuth errors when validation fails.

If you are building a protected MCP server, publish protected resource metadata so clients can discover the right authorization server. The flow only works cleanly when resource discovery, authorization server discovery, and client registration agree with each other.

FAQ

Is client ID metadata required for every MCP server? No. Authorization is optional in MCP, and stdio servers should normally use local environment credentials instead of the HTTP OAuth flow. Client ID metadata matters for protected remote MCP servers that use HTTP-based transports.

Does client ID metadata replace OAuth? No. It is one registration mechanism inside the OAuth flow. The client still uses authorization codes, PKCE, resource indicators, access tokens, and bearer token requests.

Can a server reject a valid metadata document? Yes. A document can be syntactically valid but still fail local policy. An authorization server may block unknown domains, require pre-approved clients, or reject redirect URIs it considers unsafe.

Should new MCP clients support dynamic registration? Support it as a fallback if you need compatibility with older authorization servers. For new MCP implementations, client ID metadata is the preferred path when the authorization server supports it.