A remote MCP server on Cloudflare Workers that accepts OAuth clients identified by a Client ID Metadata Document. No developer portal, no client_secret, no POST /register.
The hosted demo has an open consent screen with no password on purpose, so anyone can try the full CIMD flow. Tokens only reach the demo tools (whoami, current_time, add_note, list_notes) and demo notes. On a copy you deploy, CONSENT_PASSWORD is an optional Worker secret that gates the consent screen. A real server should use real user login.
What this is
MCP clients talk to servers they have never seen. Classic OAuth assumes the server already knows the app. That is why MCP used Dynamic Client Registration (DCR, RFC 7591): the client posted to /register and the server minted a client_id.
MCP 2026-07-28 deprecates DCR and recommends CIMD instead. The client_id is an HTTPS URL. That URL hosts a small JSON file the authorization server fetches at login. Nothing about the client is stored ahead of time.
(Example for a local client. The hosted demo's inspector-web.json uses http://localhost:6274/oauth/callback for MCP Inspector, so copy that one to try the live server.)
This is a working server-side example of that path: discovery, CIMD fetch with SSRF guards, consent, PKCE tokens, and a Streamable HTTP MCP endpoint.
Why CIMD replaces DCR
DCR lets any caller create a client on your authorization server. That is convenient for first contact and expensive as a trust model: the server learns nothing durable about who the client is, and /register becomes an open write endpoint.
With CIMD the client already has an identity (the HTTPS URL of its metadata). The server checks that the document's client_id equals that URL and that the request redirect_uri is on the document's list. The client hosts the file. The server does not keep a developer-portal registry.
As of 9 October 2026, most MCP servers that use OAuth still don't advertise CIMD: 23 of 151 vendor servers (15%) on McpMetrics' official list, and 29% of OAuth servers in a 3,000-host sample of the MCP registry. This project exists so the server side of that spec is copyable.
The flow
sequenceDiagram
participant C as MCP client
participant W as This Worker
participant D as client.json
C->>W: POST /mcp (no token)
W-->>C: 401 + resource_metadata
C->>W: GET protected resource metadata
C->>W: GET authorization server metadata
C->>W: GET /authorize?client_id=https://.../client.json
W->>D: GET client.json
W-->>C: consent, then redirect with code
C->>W: POST /token (code + PKCE + resource)
W-->>C: access_token
C->>W: POST /mcp with Bearer token
Un servidor MCP remoto en Cloudflare Workers que acepta clientes OAuth identificados por un Client ID Metadata Document. Sin portal de desarrolladores, sin client_secret, sin POST /register.
La demo alojada tiene la pantalla de consentimiento abierta, sin contraseña, a propósito, para que cualquiera pueda probar el flujo CIMD completo. Los tokens solo llegan a las herramientas de demostración (whoami, current_time, add_note, list_notes) y a las notas de demostración. En una copia que despliegues, CONSENT_PASSWORD es un secreto opcional del Worker que bloquea la pantalla de consentimiento. Un servidor real debería usar un login de usuario real.
Qué es esto
Los clientes MCP hablan con servidores que nunca han visto. OAuth clásico asume que el servidor ya conoce la aplicación. Por eso MCP usaba Dynamic Client Registration (DCR, RFC 7591): el cliente hacía POST a /register y el servidor emitía un client_id.
MCP 2026-07-28 depreca DCR y recomienda CIMD. El client_id es una URL HTTPS. Esa URL aloja un JSON pequeño que el servidor de autorización descarga en el login. No se guarda nada del cliente por adelantado.
(Ejemplo para un cliente local. El inspector-web.json de la demo alojada usa http://localhost:6274/oauth/callback para MCP Inspector, así que copia ese para probar el servidor en vivo.)
Este es un ejemplo funcional del lado servidor: descubrimiento, descarga CIMD con protecciones SSRF, consentimiento, tokens PKCE y un endpoint MCP Streamable HTTP.
Por qué CIMD sustituye a DCR
DCR permite que cualquiera cree un cliente en tu servidor de autorización. Es cómodo para el primer contacto y caro como modelo de confianza: el servidor no aprende nada durable sobre quién es el cliente, y /register queda como un endpoint de escritura abierto.
Con CIMD el cliente ya tiene identidad (la URL HTTPS de sus metadatos). El servidor comprueba que el client_id del documento es esa URL y que el redirect_uri de la petición está en la lista del documento. El cliente aloja el archivo. El servidor no mantiene un registro tipo portal de desarrolladores.
Al 9 de octubre de 2026, la mayoría de los servidores MCP que usan OAuth todavía no anuncian CIMD: 23 de 151 servidores de proveedores (15%) en la lista oficial de McpMetrics, y el 29% de los servidores con OAuth en una muestra de 3,000 hosts del registro MCP. Este proyecto existe para que el lado servidor de esa especificación se pueda copiar.
El flujo
sequenceDiagram
participant C as Cliente MCP
participant W as Este Worker
participant D as client.json
C->>W: POST /mcp (sin token)
W-->>C: 401 + resource_metadata
C->>W: GET metadatos del recurso
C->>W: GET metadatos del servidor
C->>W: GET /authorize?client_id=https://.../client.json
W->>D: GET client.json
W-->>C: consentimiento, luego redirección con code
C->>W: POST /token (code + PKCE + resource)
W-->>C: access_token
C->>W: POST /mcp con token Bearer