MCP (Model Context Protocol) es un estándar abierto que define cómo un sistema de IA pide datos y ejecuta acciones sobre las herramientas de una empresa. En lugar de una integración a medida por cada modelo y cada sistema, expone un contrato único que cualquier cliente compatible puede consumir.
Durante año y medio lo tratamos como un asunto del equipo que construye. Nos equivocamos.
Lo aprendimos por la vía lenta. Un servidor MCP conectado a un sistema interno funcionaba en local, funcionaba en la demo y empezó a comportarse raro en cuanto hubo más de una instancia detrás de un balanceador. No era el modelo. Tampoco el código. Era que el protocolo mantenía sesión, y esa sesión vivía en un sitio que el resto de la infraestructura no conocía, así que dos instancias acababan sirviendo la misma conversación sin compartir el estado que la sostenía y la respuesta dependía de a cuál le tocara atender.
Semanas después, alguien preguntó quién autorizaba qué a través de ese servidor. Nadie supo contestar. Ahí es donde MCP deja de ser una librería.
TL;DR. MCP es el contrato que usan los sistemas de IA para leer datos y ejecutar acciones sobre las herramientas de una empresa. La especificación del 28 de julio de 2026 elimina la sesión, mueve el enrutado a cabeceras y formaliza la autorización gestionada por la organización, y esos tres cambios lo sacan del terreno del equipo de IA y lo meten en el de plataforma, identidad y observabilidad. La decisión relevante ya no es qué modelo usas, es quién gobierna los accesos que abres al conectarlo.
Qué resuelve MCP y qué no
El problema que ataca es viejo y aburrido: un modelo no sirve de nada si no llega a los datos y a los sistemas donde vive el trabajo. Antes de que existiera un estándar, cada equipo resolvía esa distancia con integraciones propias, de manera que un conector para el CRM, otro para el data warehouse y otro para el gestor documental convivían escritos contra el proveedor de modelo concreto que se estuviera usando ese trimestre. Cambiar de proveedor significaba reescribir la fontanería entera. Cada vez.
MCP invierte la relación. El sistema que tiene los datos expone un servidor que describe qué herramientas ofrece, qué parámetros aceptan y qué devuelven, y cualquier cliente compatible los consume sin saber nada del modelo que hay detrás. Se escribe una vez. Sobrevive al cambio de proveedor.
Conviene decir también qué no resuelve, porque el hype de los últimos meses lo ha estirado bastante más de la cuenta. MCP no ordena tus datos, no arregla permisos mal puestos y no evita que un agente haga una barbaridad si le das acceso a una herramienta destructiva. Es un protocolo de conexión, y un protocolo de conexión hereda la calidad de aquello que conecta. Si el estado de tus datos es malo, MCP se lo entrega al modelo igual de malo. Solo que más rápido.
Qué cambió el 28 de julio de 2026
La especificación 2026-07-28 es la que convierte el estándar en algo que un equipo de plataforma puede operar. Cuatro cambios importan por encima del resto.
El núcleo pasa a ser stateless. Desaparece el saludo inicial y desaparece la sesión. Cada petición viaja con su versión de protocolo, su identidad de cliente y sus capacidades, lo que significa que cualquier petición puede aterrizar en cualquier instancia detrás de un balanceador sin almacenamiento compartido, que es exactamente lo que nos rompió a nosotros y lo que rompe cualquier despliegue el día que crece de una máquina a varias. Es el cambio que más código toca. También el que más problemas quita.
El enrutado se mueve a cabeceras. El método y el nombre de la herramienta viajan en Mcp-Method y Mcp-Name. Un gateway puede enrutar y autorizar leyendo cabeceras, sin abrir el cuerpo JSON de la petición. Es un detalle técnico con una consecuencia organizativa grande: permite aplicar política de acceso en la capa de red, donde ya sabes hacerlo, en vez de dentro de la aplicación de IA.
La autorización se endurece. Validación de emisor por RFC 9207, migración del registro dinámico de cliente a documentos de metadatos de cliente, credenciales vinculadas al emisor. Y la extensión de autorización gestionada por la organización pasa a estable, lo que permite centralizar en un punto quién puede llamar a qué.
Aparece un marco formal de extensiones. Tasks sale del núcleo experimental y se convierte en extensión, y con ella llegan las peticiones de varias vueltas, que dejan a una herramienta pedir una confirmación o un parámetro que falta a mitad de la llamada en lugar de fallar.
La lista de quién lo está adoptando dice más que la especificación: AWS, Cloudflare, Google Cloud, Microsoft, Figma, Netlify, Supabase, Linear y Sentry aparecen nombrados en el anuncio, y ninguno de ellos es una empresa que persiga tendencias, sino proveedores que soportan cargas ajenas y que solo implementan un protocolo cuando calculan que van a tener que sostenerlo durante años. Cuando la infraestructura adopta algo, ese algo se convierte en infraestructura. Con todo lo que eso arrastra.
Por qué esto ya no es una decisión del equipo de IA
Aquí está el cambio real, y es de gobierno más que de tecnología. Un servidor MCP es una puerta. Detrás de esa puerta hay un sistema interno y una identidad que decide qué se puede hacer con él, así que multiplicar la operación por diez sistemas produce una superficie de acceso nueva que nadie llegó a inventariar, porque se fue montando pieza a pieza mientras se probaban cosas y ninguna de esas piezas parecía importante por separado.
Las tres preguntas que hay que poder responder antes de conectar nada son las de siempre en cualquier integración seria. Quién llama, y si esa identidad es la de la persona concreta que está pidiendo algo o la de un servicio genérico que difumina a todo el mundo detrás del mismo token. Qué puede hacer una vez dentro. Y qué queda registrado, porque un agente que consulta y escribe sin dejar traza se convierte en un problema de auditoría el día que alguien pregunte.
Ninguna la contesta un modelo mejor. Las contesta la plataforma, y por eso la conversación se ha movido de sitio.
Los proveedores lo dicen con sus propias palabras. Tina Schuchman, de Microsoft Foundry, describe el endpoint unificado de MCP de su producto como una pieza que reúne herramientas "centralizando a la vez el gobierno, la identidad y la observabilidad", según la traducción de su cita en el anuncio de la especificación. Gobierno, identidad, observabilidad. Ninguna de las tres es competencia del equipo que escribe prompts, y aparecen juntas porque en producción no se dejan separar.
Qué mirar antes de conectar un servidor MCP
Esta es la lista corta que usamos internamente. No está ordenada por importancia teórica sino por el número de veces que cada punto nos ha costado una tarde de la que se podía haber prescindido, que es un criterio bastante más útil cuando lo que tienes delante es una decisión y no un examen.
- Identidad propagada, no compartida. Si el servidor llama al sistema de destino con una cuenta de servicio única, has perdido la trazabilidad de quién hizo qué antes de empezar.
- Permisos de solo lectura por defecto. La escritura se habilita herramienta por herramienta y con una razón escrita, no como estado inicial.
- Revocación en un único punto. Si cortar el acceso exige tocar cinco sistemas, en la práctica no se corta.
- Traza de llamadas con contexto. Qué herramienta, con qué parámetros, en nombre de quién y con qué resultado.
- Comportamiento con varias instancias. Probarlo detrás de un balanceador antes de asumir que escala, que es donde el modelo stateless de la nueva especificación cambia las cosas.
- Dueño asignado. Cada servidor con una persona responsable de su ciclo de vida. Un servidor sin dueño es deuda que nadie ve hasta que rompe.
Quién sostiene esto dentro de un equipo
El perfil que hace falta aquí no es el que ajusta prompts. Es alguien que sabe de identidad, de red y de despliegue, y que además entiende cómo se comporta un sistema de IA cuando le das herramientas de verdad y deja de ser una demo con respuestas bonitas para pasar a escribir en sistemas que le importan a alguien. Existe. No abunda.
El mercado español ya lo está pidiendo, aunque las ofertas no usen esas palabras. Según el análisis de mercado de Shakers sobre 918 ofertas de AI Engineer en España (n=918, agosto 2026), 310 piden CI/CD y 191 piden Kubernetes, por delante de las 121 que piden PyTorch. La demanda se ha desplazado hacia el lado de operar el sistema, y lo desarrollamos con el detalle completo en qué pide de verdad una oferta de AI Engineer en España.
Esto encaja con lo que midió BCG en enero de 2025: solo una cuarta parte de las empresas declaraba obtener valor relevante de la IA, pese a la inversión y a los pilotos. Ese hueco tiene nombre, y es el implementation gap. No se cierra con un modelo mejor. Se cierra con la capacidad de llevar el sistema a producción y sostenerlo, que es la última milla de la IA y es exactamente el terreno donde la especificación de julio acaba de mover la línea.
La lección operativa, con su límite: MCP resuelve el problema de conexión, lo resuelve bien, y desde julio lo resuelve de una forma que un equipo de plataforma puede gobernar con las herramientas que ya tiene. Lo que todavía no sabemos es cómo se comporta el conjunto cuando una empresa tenga cuarenta servidores en producción en vez de cuatro. Nadie ha recorrido esa curva.
Si estás montando el equipo que tiene que sostener esta capa, habla con un experto de Shakers sobre las skills concretas que necesitas cubrir.
Preguntas frecuentes sobre MCP
- ¿MCP y API son lo mismo?
No. Una API expone funciones a un programa que ya sabe cuáles quiere llamar, mientras que un servidor MCP se describe a sí mismo para que un sistema de IA pueda descubrir en tiempo de ejecución qué herramientas existen, qué parámetros aceptan y qué devuelven, sin que nadie se lo haya codificado por adelantado. Por debajo suele haber una API. MCP es la capa que la hace legible para un modelo.
- ¿Hace falta MCP para usar IA con datos propios?
No es obligatorio. Se puede resolver con integraciones a medida, y para un único caso de uso con un solo proveedor puede salir más rápido. MCP compensa cuando hay varios sistemas, varios clientes de IA o intención de cambiar de proveedor sin reescribir la fontanería.
- ¿Qué cambia la especificación 2026-07-28 para quien ya tiene servidores en producción?
El cambio con más impacto es el núcleo stateless, porque elimina la sesión y permite escalar horizontalmente sin almacenamiento compartido. También cambia el enrutado, que pasa a cabeceras, y la autorización, que se endurece con validación de emisor. Migrar exige revisar despliegue y capa de autenticación, no solo actualizar una librería.
- ¿Es seguro conectar un servidor MCP a sistemas internos?
Depende por completo de cómo se configure la identidad y los permisos, no del protocolo. Los riesgos reales son dar acceso con una cuenta de servicio compartida, habilitar escritura por defecto y no registrar las llamadas. La extensión de autorización gestionada por la organización existe justamente para centralizar esas decisiones.