Un asistente puede decir quién es sin registrarse
Conectar un asistente exigía que antes se registrara aquí, y Claude creaba un cliente nuevo cada vez que alguien se conectaba. Ahora puede identificarse con un documento de metadatos — una dirección que él mismo publica y que este servidor lee —, que es lo que prefiere la especificación de MCP. El registro sigue disponible para los clientes que no saben hacer otra cosa.
La página de aprobación cambió con ello. Ahora dice dónde está publicada la descripción de un cliente y avisa cuando el único sitio al que puede devolverte es un programa de tu propio ordenador, porque cualquier cosa que se ejecute allí puede pedir lo mismo.
Un cliente tiene tres maneras de decirle a un servidor de autorización quién es: registrarse, quedar anotado a mano, o publicar un documento en una dirección y usar esa dirección como nombre. Este servidor lee ya la tercera.
Qué es un documento de metadatos
Su client_id es una URL https. El documento que hay en esa dirección dice cómo se llama el cliente, adónde se le puede devolver y, si quiere, qué está pidiendo. El servidor lo recoge mientras autorizas, en vez de llevar un registro propio. Es draft-ietf-oauth-client-id-metadata-document-00 tal como lo perfila la especificación de autorización de MCP del 25 de noviembre de 2025, y Claude lo prefiere en cuanto un servidor dice admitirlo.
Qué sustituye
El registro dinámico de clientes (RFC 7591) crea aquí un cliente en cada conexión. Volver a conectar el mismo asistente producía otro más, de modo que la tabla acumulaba cinco filas llamadas «Claude», imposibles de distinguir entre sí o de un desconocido registrado con ese mismo nombre. Un documento publicado tiene una dirección, y la dirección es la identidad: lo que dice puede cambiar, lo que es no. El registro sigue funcionando, porque existen clientes que solo saben hacer eso.
Qué recoge el servidor y qué no
Aquí un client_id es una URL que entrega un desconocido y que después pide nuestro servidor: una falsificación de peticiones del lado del servidor esperando a estar mal escrita. Así que: solo https; con ruta, porque un origen desnudo identifica a un anfitrión y no a un cliente, y quien pueda dejar un archivo en la raíz de un dominio hablaría si no por el dominio entero; sin fragmento y sin credenciales; la URL en forma canónica y repetida dentro del documento que nombra. No se siguen redirecciones, la dirección se resuelve y se rechaza si es privada, hay un plazo propio dentro del que el cliente concede a todo el extremo, un tope de 64 KB, y el cuerpo debe ser JSON antes de leerse. Las respuestas se guardan una hora como mucho y los fallos un minuto: un client_id que responde 404 no convierte cada pulsación del botón en otra petición.
Qué dice de ello la página de aprobación
Dónde está publicada la descripción del cliente, y que acaba de leerse. Y un aviso cuando todas las direcciones a las que puede devolverte son programas de tu propia máquina: el documento lo publica el cliente auténtico, pero basta con ocupar un puerto para atrapar el código que vuelve, y ninguna página puede distinguir dos programas de tu ordenador. Ese juicio queda de tu parte.
Relacionado: convertir documentos desde un asistente y convertir documentos con una API.