Qué significan el núcleo sin estado y la autenticación gestionada de MCP para los equipos de integración
La gobernanza de Linux Foundation, el transporte HTTP sin estado y la autorización gestionada por proveedores de identidad hacen que MCP sea viable para la integración empresarial. Aquí está lo que ha cambiado.
El protocolo Model Context Protocol estandariza la forma en que los agentes de IA se conectan con los sistemas a su alrededor, de manera similar a cómo las APIs estandarizaron en el pasado la forma en que las aplicaciones se comunicaban entre sí. Para quienes trabajan en integración y operaciones de TI, ha sido algo a observar desde la distancia durante dos años: prometedor, ganando impulso y aún más parecido a herramientas para desarrolladores que a algo que un comité de revisión arquitectónica aprobaría. Esa distancia se ha reducido. En ocho meses, MCP ha superado tres hitos que, en conjunto, recuerdan a los primeros años de la gestión de APIs alrededor del 2010, repitiéndose ahora en el caso de los agentes de IA.
Tres cambios en ocho meses
Gobernanza neutral. Anthropic entregó MCP a la Agentic AI Foundation en diciembre de 2025. Se trata de un fondo dirigido dentro de la Linux Foundation, creado por Anthropic, Block y OpenAI, y respaldado por Google, Microsoft, AWS, Cloudflare y Bloomberg. Gracias a esto, MCP ya no seguía los planes de un único proveedor y pasó a estar bajo una gestión imparcial similar a la con la que crecieron Kubernetes y Node.js.
Autorización centralizada. El 18 de junio de 2026, la extensión Enterprise-Managed Authorization (EMA) alcanzó estabilidad. Reemplaza las pantallas de consentimiento por servidor con un modelo impulsado por el proveedor de identidades, y Anthropic, Microsoft y Okta se encontraron entre los primeros en adoptarla.
Un núcleo sin estado. La versión del 28 de julio de 2026 supuso la mayor revisión de especificaciones desde la aparición del protocolo, y reemplaza un diseño con estado y vinculado a sesiones por uno sin estado basado en HTTP puro.
Estos cambios no son meramente estéticos. Cada uno elimina una razón concreta por la cual MCP no se utilizó en entornos de producción reales, y son especialmente importantes para quienes se dedican a conectar sistemas como trabajo y no crean demostraciones de IA.
Una definición rápida
MCP es un estándar abierto que define cómo una aplicación de IA, como por ejemplo un agente basado en LLM, encuentra e invoca herramientas externas, lee recursos externos e intercambia contexto con sistemas distintos al modelo. Una interfaz uniforme sustituye a la integración personalizada necesaria para cada fuente de datos.
Una comparación aproximada: MCP hace por las conexiones de IA a sistemas lo que REST y OpenAPI hicieron entre aplicaciones. Los sistemas integrados permanecen tal como están. Lo que se estandariza es el contrato entre el cliente de IA y lo que sea que maneje el servidor MCP, ya sea una herramienta de gestión de tickets, un CMDB, una plataforma de monitoreo o una base de datos interna.
Cambio 1: ya no hay sesiones
Durante sus primeros dos años, MCP sobre HTTP funcionó como muchos protocolos en tiempo real. Un cliente se conectaba, completaba un proceso de inicialización y recibía un ID de sesión que cada solicitud posterior debía incluir. La sesión vinculaba al cliente a la única instancia del servidor que la había creado. Quienes hayan implementado un servicio WebSocket detrás de un balanceador de carga conocen las dificultades que esto conlleva. Para escalar, era necesario utilizar enrutamiento sticky, un almacén de sesiones compartido o una pasarela que analizara el tráfico para encontrar la instancia específica que mantenía la conexión.
La especificación del 2026-07-28 elimina todo eso. No existe un proceso de inicialización ni de intercambio de información al inicializarse, y tampoco hay un encabezado Mcp-Session-Id. En su lugar, cada solicitud trae consigo su propia versión de protocolo, identidad del cliente y capacidades. Como resultado, cualquier instancia de servidor puede responder a cualquier solicitud, por lo que las sesiones persistentes y los almacenes de sesiones compartidos ya no son algo que exija el protocolo. Los clústeres sin servidor, multiinstanciales y de enrutamiento periférico funcionan entonces como lo hacen con las API HTTP habituales, porque estructuralmente eso es lo que se ha convertido MCP.
Sin sesiones de protocolo, las aplicaciones no se vuelven sin estado. Cuando un servidor realmente necesita recordar algo entre llamadas, como una exportación en curso o una tarea de corrección larga, sigue la antigua práctica REST: crea un identificador explícito y el cliente lo pasa de vuelta como un argumento normal la próxima vez. Los ingenieros familiarizados con los puntos de extremo de paginación y estado de tareas lo reconocerán; se trata de una elección deliberada que es adecuada para los balanceadores de carga y no de un parche.
Esa misma versión reforzó la seguridad en torno a la nueva forma. Los clientes deben validar al emisor en las respuestas de autorización, lo que evita el secuestro de sesiones mediante redirecciones en configuraciones con varios servidores. También deben indicar para qué servidor está destinado un token, cerrando una brecha de delegación que los equipos de seguridad habían señalado como un riesgo real en implementaciones multiinquilino. Además, MCP cuenta ahora por primera vez con una política formal de obsolescencia, de modo que los cambios disruptivos siguen un ciclo de vida real y no se eliminan de forma arbitraria.
Cambio 2: acceso gestionado por el proveedor de identidad
El segundo cambio se refiere menos al transporte y más a las dificultades diarias que surgen al desplegar agentes en toda la empresa. Con el enfoque de autorización de primera generación, cada empleado tenía que completar por su cuenta el paso de consentimiento de OAuth para cada servidor MCP que utilizaba su cliente de IA. Con cien empleados y seis o siete herramientas internas, el proceso de incorporación deja de escalar. Los equipos de seguridad también pierden una visión centralizada de quién está conectado a qué, y no existe una forma ordenada de restringir el acceso cuando alguien se traslada o renuncia.
EMA deja la decisión sobre la autorización en manos del proveedor de identidades de la empresa. Un administrador decide una sola vez, en el IdP, qué servidores MCP puede utilizar un grupo de empleados. Posteriormente, el acceso se activa automáticamente la primera vez que una persona inicia sesión a través de un cliente compatible, sin necesidad de solicitudes de consentimiento ni configuraciones adicionales.
Okta fue el primero entre los proveedores de identidad en brindar soporte para ello, utilizando su producto Cross App Access como base. La extensión se basa en Identity Assertion JWT Authorization Grant, que es una especificación abierta de IETF y no algo exclusivo de Anthropic. Anthropic la integró en Claude, Claude Code y Cowork a través de una capa MCP compartida, mientras que Microsoft incorporó el soporte directamente en Visual Studio Code. Los servidores que ya lo soportan incluyen Asana, Atlassian, Canva, Figma, Granola, Linear y Supabase, y la lista sigue creciendo.
El proveedor de identidad finaliza su función una vez que ha emitido el permiso de autorización. No participa en la llamada a la herramienta en sí, un hecho importante en las revisiones de seguridad: el IdP no actúa como proxy en todos los flujos de datos de la IA al sistema, sino que solo decide quién obtiene las credenciales. Dado que el acceso está centralizado, lo mismo ocurre con la revocación. Al desactivar la cuenta de una persona que se retira, se desconectan de inmediato todos sus servidores conectados a EMA, por lo que no es necesario recordar ni revocar manualmente siete integraciones por separado.
El inicio de sesión único para la pila SaaS de una empresa funciona de la misma manera, lo que le da un aspecto familiar, y eso es intencional. Los equipos de seguridad no necesitan crear un nuevo modelo de gobernanza para los agentes; simplemente extienden el que ya existe.
Qué significa esto para los equipos con soluciones personalizadas
Muchos equipos de integración y plataforma no esperaron a que MCP madurara. Al pedírseles que permitieran a un asistente de IA interno leer información de Jira, publicar en Slack o consultar herramientas de monitoreo, escribieron su propio código de conexión: un wrapper personalizado para cada API, un flujo de autenticación hecho a medida y un manejo manual de sesiones, ya que no existía nada estándar. Funcionó. Pero cada nueva herramienta se convirtió en un proyecto único, la autenticación se reinventaba para cada sistema, y el enfoque fallaba cada vez que otro equipo quería la misma funcionalidad.
La madurez recién adquirida aborda ese problema de tres maneras:
- Un transporte estable y sin estado basado en HTTP puro permite a los equipos dejar de escribir su propio sistema de gestión de conexiones y tratar un servidor MCP como cualquier API REST detrás de una pasarela de APIs.
El trabajo de integración en sí no desaparece. La traducción de datos entre un esquema de tickets y uno de monitoreo, junto con la transformación a nivel de campos, la deduplicación y la lógica empresarial que abarca varios sistemas, sigue requiriendo un verdadero trabajo de ingeniería independientemente del protocolo que transmita la solicitud. Lo que disminuye es la infraestructura auxiliar: el transporte, la gestión de sesiones y el flujo de autenticación. Esto reduce en gran medida el esfuerzo no diferenciado, aunque no todo el trabajo.
Una historia antigua con una nueva etiqueta
Dejando de lado el enfoque basado en la IA, esto resulta familiar. Durante aproximadamente dos décadas, las empresas han creado e adquirido plataformas de integración para resolver los problemas relacionados con las conexiones API a API: autenticación estandarizada, mapeo y transformación de datos gestionados de forma centralizada, un volumen de transacciones que crece sin necesidad de código personalizado para cada nuevo par de sistemas, y un lugar donde los equipos de seguridad pueden ver y controlar qué está conectado.
MCP parece seguir el mismo enfoque disciplinado para las conexiones entre agentes de IA, solo que más rápido. Un núcleo sin estado basado en HTTP simple permite que un servidor MCP se comporte y escale como cualquier servicio backend. La autorización gestionada por el IdP convierte la concesión y auditoría del acceso a las herramientas de IA en una tarea cotidiana dentro del control de accesos empresarial. Además, la gobernanza neutral bajo Linux Foundation hace que la adopción del protocolo sea similar a elegir Kubernetes, en lugar de seguir el plan de desarrollo de una sola empresa.
Para los equipos de integración, la lección no es que los agentes requieran un nuevo conjunto de procedimientos. Los métodos ya utilizados para conectar sistemas de manera fiable, segura y a gran escala ahora también se aplican directamente a los agentes. La capa de protocolo se integra en la infraestructura que las personas ya conocen, y lo que realmente diferencia a los equipos se sitúa en niveles superiores: el mapeo de datos, la aplicación de políticas de gobernanza y la gestión de cambios en todos los sistemas involucrados, que siempre ha sido la parte más difícil.