· via Vercel blog
Vercel MCP replaces manual client allowlisting with Client ID Metadata Documents
Vercel's MCP server no longer hand-reviews each client before it can connect. Any MCP client can now authenticate by publishing a Client ID Metadata Document and using its HTTPS URL as an OAuth client_id.

Vercel has removed the manual allowlist that previously determined which clients could connect to its MCP server. According to the Vercel changelog, any MCP client can now request a connection to Vercel MCP. Users still log in and approve each connection, but the client itself no longer needs to be reviewed by Vercel first.
The shift replaces hand curation with a protocol-level mechanism: Client ID Metadata Documents, an approach the MCP authorization specification now recommends over OAuth Dynamic Client Registration.
What the allowlist replaced
Previously, Vercel reviewed each client and its redirect URIs by hand, and anything that was not on the list was rejected. That gave Vercel direct control over what could talk to its MCP server, at the cost of a review step for every client that wanted access.
How Client ID Metadata Documents work
Under the new model, a client publishes a Client ID Metadata Document — a JSON file hosted on its own domain that describes the client — and then uses the HTTPS URL of that file as its OAuth client_id.
Because the client_id is the document's URL, the client's identity is anchored to the domain that serves it. There is no allowlist entry to wait for; the document itself takes the place of a registration. According to Vercel, this follows the MCP authorization spec, which now recommends CIMD over Dynamic Client Registration, the OAuth mechanism in which clients register themselves programmatically with an authorization server at runtime.
What users see when approving a connection
Because Vercel has not reviewed CIMD-based clients, the consent screen is designed to make their origin visible. It shows the client's name, its logo and the hostname that serves its metadata document; the changelog cites "Claude Code by claude.ai" as an example of how that reads.
These clients do not get the Vercel verified badge that reviewed clients carry. Instead, the hostname is what a user is effectively trusting when they approve a connection. Apps already registered with Vercel are unchanged.
Why it matters
For client developers, the barrier to integrating with Vercel MCP drops sharply: no review cycle and no allowlist entry, just a JSON document on a domain the client controls and an OAuth flow pointing at it.
For the broader MCP ecosystem, the move is a signal about direction. With the MCP authorization spec now recommending CIMD over Dynamic Client Registration, other server operators face the same choice, and Vercel's implementation is a concrete example of one large operator landing on the CIMD side.
The trade-off is that trust moves from platform curation to domain identity. The verified badge meant a human at Vercel had examined a client; with CIMD, the practical check is whether the hostname on the consent screen is one the user recognizes. That puts more weight on users noticing the hostname before approving, and on client developers keeping firm control of the domains that serve their metadata documents.
- #mcp
- #vercel
- #oauth
- #cloud
- #model-context-protocol