El roadmap de MCP apunta a tareas largas y autenticación

El Model Context Protocol no ha cumplido aún dos años desde su presentación en noviembre de 2024 y ya tiene hoja de ruta propia. GIGAZINE informa de que el equipo que mantiene la especificación ha publicado un roadmap con cinco áreas de trabajo y destaca dos: el procesamiento de larga duración y la autenticación de los agentes de IA. Ambas apuntan al mismo sitio, que es lo que se rompe cuando MCP sale del portátil de un desarrollador y entra en una empresa.

Conviene recordar de qué hablamos. MCP es el estándar que permite a un modelo llamar a herramientas externas con un contrato común, en lugar de una integración a medida por cada servicio. Se configura en claude_desktop_config.json o desde Claude Code, y en poco tiempo ha pasado de propuesta de Anthropic a pieza que implementan proveedores muy distintos. Un roadmap con estos dos ejes marca el momento en que un protocolo deja de crecer a lo ancho y empieza a arreglar lo que duele.

Tareas largas contra el modelo de petición y respuesta

Una llamada a herramienta en MCP se parece a una petición HTTP: pides algo y esperas la respuesta. Eso encaja con consultar una base de datos y encaja mal con renderizar un vídeo, lanzar una migración, rastrear un sitio entero o aguardar a que termine un build de veinte minutos. El apaño habitual consiste en devolver un identificador de trabajo y hacer que el agente pregunte cada pocos segundos si ya está listo, lo que gasta contexto y tokens en no hacer nada.

La especificación contempla notificaciones de progreso y cancelación, pero eso no equivale a un trabajo capaz de sobrevivir a la desconexión del cliente y de entregar el resultado más tarde. Que el asunto entre en el roadmap sugiere que la solución acabará viviendo en el protocolo, en vez de repetirse a mano dentro de cada servidor.

Identidad: quién es el agente que llama

El segundo eje es el más delicado. Cuando hoy un servidor MCP remoto exige autenticación, el patrón habitual pasa por OAuth: la persona autoriza y el servidor recibe un token que la representa. El agente actúa entonces suplantando al humano y hereda todos sus permisos. Funciona en un escritorio y se cae en cuanto tienes varios agentes, dos entornos y alguien pidiendo una auditoría.

Lo que falta es poder distinguir al agente del usuario que lo ha lanzado: credenciales propias, permisos acotados a lo que ese agente necesita y una traza de qué agente hizo qué llamada con qué autorización. Sin eso, revocar el acceso de un agente comprometido obliga a revocar también el de la persona, y cualquier registro de auditoría acaba diciendo siempre el mismo nombre.

Qué hacer mientras tanto

Un roadmap no es una especificación y no obliga a reescribir nada hoy. Sí conviene ir preparando el terreno:

1. Diseñar herramientas idempotentes, porque los reintentos van a llegar igualmente.
2. En trabajos largos, devolver ya un identificador estable y un método de consulta, de modo que migrar a lo que salga sea cambiar el transporte y no la lógica.
3. Separar credenciales por agente y por entorno con cuentas de servicio, en lugar de reutilizar el token personal de quien montó la integración.
4. Revisar los scopes que pide cada servidor MCP instalado y retirar los que sobran.

Nuestra lectura

Lo interesante del roadmap no son las cinco áreas, sino lo que dejan ver. Un protocolo que se pone a resolver identidad y trabajos de horas es un protocolo que ya se usa en sitios donde hay algo que perder. Lo leemos como señal de madurez, con la cautela de siempre: la fecha que contará será la de la especificación publicada, no la del anuncio.