Vercel MCP ya acepta cualquier cliente de IA sin revisión

Vercel MCP ya no revisa clientes a mano: qué cambió

Cerca del 60% de la actividad en Vercel ya la generan agentes de código, según declaraciones de su CEO, Guillermo Rauch, recogidas por un análisis publicado en note.com. Y ahora cualquiera de esos agentes puede pedir conectarse a Vercel MCP sin que Vercel lo revise antes.

Hasta este cambio, Vercel revisaba y agregaba a mano cada cliente y sus redirect URIs a una lista de permitidos. Todo lo que no estuviera en esa lista se rechazaba. El nuevo modelo invierte la lógica: el cliente se presenta solo y el usuario decide si lo aprueba.

El mecanismo se llama Client ID Metadata Document (CIMD): un archivo JSON que el cliente publica en su propio dominio, describe quién es, y cuya URL HTTPS se usa como client_id de OAuth. Vercel sigue así el spec de autorización de MCP, que ahora recomienda CIMD por encima del Dynamic Client Registration (DCR).

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La consecuencia práctica se ve en la pantalla de consentimiento. Como Vercel no revisó a ese cliente, la pantalla muestra de dónde viene: su nombre, su logo y el hostname que sirve el documento de metadatos, por ejemplo "Claude Code by claude.ai". Los clientes que entran por CIMD no llevan el badge de verificado de Vercel, así que ese hostname es lo único en lo que te apoyas cuando apruebas. Las apps ya registradas con Vercel no cambian.

¿Por qué el spec de MCP abandonó el registro manual de clientes?

El cambio de Vercel no es una decisión aislada: es la implementación de una recomendación del propio protocolo. InfoWorld reportó que la versión 2025-11-25 del spec de MCP, la que llega con el SDK 1.0 de C# de Microsoft, presenta los CIMD como alternativa al DCR y los convierte en el método preferido para el registro de clientes.

El problema que resuelven es operativo. Según SD Times, para usar DCR el desarrollador de un servidor MCP necesita un Authorization Server que permita a los clientes registrarse solos a través de una API pública. Si ese servidor no lo soporta, hay que construir un proxy OAuth y registrarlo a mano. Los mantenedores del protocolo descartaron la alternativa de que cada usuario final registre su propio cliente porque, dijeron, sería "intercambiar una tarea compleja por otra".

La misma versión del spec sumó tareas con estado, extensiones, extensiones de autorización y metadatos de iconos para herramientas y recursos, según InfoWorld y SD Times. El contexto: MCP cumplió un año desde que Anthropic lo liberó como open source y, según sus mantenedores, se convirtió en el estándar de facto para conectar modelos con herramientas externas en menos de doce meses.

La letra chica: sin badge verificado, el hostname es tu única garantía

Aquí está el trade-off que conviene entender antes de aprobar cualquier conexión. Scalekit explica que CIMD mueve el registro del servidor al cliente: ya no hay una tabla de clientes que un equipo de identidad mantiene, sino un documento que el servidor descarga y valida en tiempo de ejecución. Eso elimina el cuello de botella, pero traslada la confianza al dominio que publica el archivo.

Scalekit detalla tres riesgos operativos concretos de CIMD: si la URL de metadatos no está disponible, fallan todos los intentos de login; el servidor debe implementar protecciones contra SSRF (bloquear redes privadas, exigir HTTPS, timeouts cortos) porque la URL la provee el cliente; y el cacheo de metadatos puede generar fallos intermitentes durante una rotación de claves JWKS.

A esto se suma el contexto de seguridad del protocolo. Ars Technica reportó que en los últimos cinco meses Google y otras cuatro organizaciones reconocieron vulnerabilidades que explotan la confianza entre agentes dentro de una red: un investigador independiente, Syed Anas Mohiuddin, probó ataques de prompt injection contra agentes de Google, JP Morgan Chase, Weaviate, Rapid7, la dirección digital interministerial del gobierno francés y el gobierno federal de Estados Unidos. Como los servidores MCP guardan credenciales por agente y los agentes confían entre sí, una instrucción bien construida puede pasar de un agente a otro.

Traducido a tu operación: la pantalla de consentimiento de Vercel dejó de ser un trámite y pasó a ser un punto de decisión de seguridad.

¿Qué significa esto para tu startup?

1. Enseña a tu equipo a leer el hostname antes de aprobar. Con el modelo anterior, Vercel filtraba por ti. Ahora el filtro eres tú: el nombre y el logo del cliente los controla quien publica el documento, y el hostname es el dato duro. Si alguien de tu equipo ve una pantalla que dice "Claude Code by claude.ai", está bien; si ve un hostname que no reconoce, no aprueba.

2. Si construyes un producto que consumen agentes, publica tu CIMD. Mantener una allowlist manual de clientes y redirect URIs no escala: cada instancia de IDE, cada CLI y cada agente efímero se comporta como un cliente OAuth distinto. Publicar un JSON en tu dominio y usarlo como client_id te quita ese trabajo. Scalekit recomienda tratarlo como configuración de producción: versionado, con monitoreo de uptime y TLS, porque si el documento se cae, tus usuarios no pueden autenticarse.

3. Si eres usuario de Vercel, conecta tu cliente y mide. Vercel expone documentación en Markdown, llms.txt, MCP y procedimientos de CLI para que un agente no solo lea los docs sino que consulte la lista de proyectos, revise el estado de un despliegue y sus logs, o investigue un dominio, según el análisis de note.com. Antes de dar acceso, define qué proyectos y qué entornos quieres que un agente pueda ver.

4. Si operas un servidor MCP, prepara las defensas del lado servidor. Bloquea rangos de red privados en las peticiones salientes, exige HTTPS, fija timeouts cortos y define políticas de cacheo e invalidación antes de una rotación de claves. Son las recomendaciones que Scalekit marca como obligatorias cuando el registro pasa a ser dinámico.

Conclusión

Vercel movió el cuello de botella del onboarding al juicio del usuario. Para un founder, la lectura es doble: por un lado, tus agentes se conectan más rápido a las herramientas que ya usas; por el otro, la decisión de confiar en un cliente de IA recae cada vez más en ti y en tu equipo, no en el proveedor. La comodidad de aprobar en un clic es exactamente el lugar donde conviene tener una regla escrita.