Qué es, en una frase
MCP — Model Context Protocol — sirve para que la IA no tenga que llevar una integración distinta para cada herramienta. Es un protocolo estándar: el servidor describe qué herramientas tiene y el cliente (el agent) pregunta en el mismo idioma, sea cual sea el servidor.
De ahí se ve la utilidad práctica: si tienes un servidor MCP para tu propio sistema, cualquier agent que hable el protocolo puede conectarse a él, y no hace falta desarrollar por separado para cada uno.
Lo que ha cambiado desde 2025: ya no es el protocolo de una empresa
Esta es la actualización más importante, porque muchas fuentes lo siguen describiendo como «el protocolo de una empresa desarrolladora de modelos».
Según el documento oficial de gobernanza, MCP es hoy un proyecto que funciona bajo el paraguas de la Linux Foundation. El código y la especificación están bajo licencia Apache 2.0, y la documentación bajo Creative Commons.
Y hay un principio que conviene conocer al pie de la letra: en la gobernanza técnica la pertenencia va ligada a personas, no a empresas; no hay asientos reservados para compañías concretas.
Esto no es un formalismo. Significa que el estándar sobre el que construyes tus integraciones no depende de la decisión comercial de una sola empresa.
La especificación de 2026 no es un ajuste fino
La numeración de versiones ya es informativa de por sí: MCP usa versiones con fecha, y el número marca el día en que se hizo el último cambio incompatible hacia atrás. La actual es 2026-07-28. La serie hasta ahora: 2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28.
El último paso reescribió la arquitectura:
- Desaparecen las sesiones a nivel de protocolo. La cabecera con el identificador de sesión queda eliminada. Si un servidor necesita mantener estado entre llamadas, lo hace con un identificador explícito emitido por el servidor, que viaja como un argumento de herramienta normal.
- MCP pasó a ser sin estado. También se eliminó el saludo inicial: cada petición lleva consigo la versión del protocolo y las capacidades del cliente.
- Una nueva llamada obligatoria con la que el servidor indica qué versiones y capacidades admite.
- Tres funciones anteriores quedaron obsoletas, y el viejo transporte basado en HTTP se declaró formalmente obsoleto.
El mensaje práctico: si una descripción habla de saludo inicial o de identificador de sesión, está desfasada. Es así desde el verano de 2026.
En ese mismo momento llegó también una buena noticia: se introdujo una política de obsolescencia. El estado de una función puede ser activa / obsoleta / retirada, la ventana de obsolescencia es de al menos doce meses (y en el caso acelerado, mínimo noventa días), y hay un registro público de las funciones retiradas. En un protocolo, eso es señal de madurez.
¿Cómo de grande es el ecosistema?
Hay un registro oficial y se puede consultar. Lo hice: recorrí el registro entero el 12 de septiembre de 2026:
| Indicador | Valor |
|---|---|
| Servidores únicos | 31.449 |
| Entradas de versión en total | 101.682 |
| De ellas, marcadas como obsoletas | 1.182 |
| Entradas con endpoint remoto | 41.066 |
| Fecha de la entrada más antigua | 8 de septiembre de 2025 |
(Medición propia sobre la API del registro oficial, recorriendo 1.017 páginas.)
Es decir, más de treinta mil servidores únicos en un año, con tres versiones publicadas de media por servidor. El día de la consulta seguían llegando entradas nuevas.
Dos límites importantes. El registro está en estado preliminar: sus propios responsables escriben que puede haber cambios que rompan compatibilidad o restauraciones de datos. Y no contiene servidores privados ni internos, así que la cifra real es mayor.
El tercer límite es el más importante, y es de seguridad: el registro dice expresamente de sí mismo que delega la revisión de seguridad en los registros de paquetes y en los mercados que lo reprocesan. Él se ocupa de la verificación de espacio de nombres y de los metadatos.
Entrar en el registro oficial no es, por tanto, un certificado de seguridad.
El lado de la seguridad
Esta parte explica por qué MCP no se puede «simplemente conectar».
Medición propia, el mismo día, en la base de datos nacional de vulnerabilidades:
| Vulnerabilidades ligadas a MCP en total | 78 |
| Publicadas en 2025 | 23 |
| Publicadas en 2026 (hasta septiembre) | 55 |
| Críticas | 17 |
| Altas | 38 |
En un año se ha más que duplicado, y alrededor del 70 % de los hallazgos están clasificados como altos o críticos.
De ellas destacan cuatro patrones, y los cuatro son instructivos.
El primero: las implementaciones de referencia tampoco son excepción. En uno de los servidores propios de los creadores del protocolo era posible una fuga de datos sin un solo clic (crítica, puntuación 9,3, julio de 2025): el agent generaba un mensaje en el que una referencia insertada por el atacante se llevaba los datos a escondidas, y el robot que prepara la vista previa del enlace la solicitaba por su cuenta. El mismo día se supo que en otros dos servidores oficiales también se podía salir de los directorios permitidos.
El segundo: las herramientas oficiales de desarrollo también. El depurador propio del protocolo recibió un fallo crítico de ejecución remota de código con puntuación 9,4, porque no había autenticación entre el cliente y el proxy.
El tercero, y este es el más elocuente: los cinco SDK oficiales cayeron en la misma trampa. Las versiones de Python, TypeScript, Go, Java y Rust trajeron todas el mismo fallo: por defecto no había protección frente a un ataque de red concreto y conocido desde hace tiempo, de modo que una web maliciosa podía alcanzar el servidor MCP que corre en tu propia máquina. Esto no habla de un desarrollador descuidado, sino de que el fallo nació alrededor del protocolo, no por debajo.
El cuarto: la comprobación de permisos en la capa equivocada. En un servidor se documentaron tres variables de entorno como control de acceso, pero solo actuaban al listar las herramientas, no en la llamada real. Quien supiera el nombre de una herramienta podía invocarla directamente. Filtrar la lista no es gestión de permisos, y no hay ejemplo de manual más limpio que este.
Y hay un ataque que no tiene número de vulnerabilidad, porque no es un fallo de implementación: el envenenamiento de herramientas. Un servidor malicioso entrega una descripción de herramienta que convence al propio agent de hacer algo. En la demostración publicada, el agent filtró su propio archivo de configuración y las claves SSH. En la variante más astuta, la descripción sobrescribe el comportamiento de otra herramienta de confianza: en el ejemplo publicado, escondida en la descripción de una inocente herramienta de suma iba la instrucción de que la herramienta de correo enviara desde entonces cada mensaje a la dirección del atacante y no se lo mencionara al usuario.
Lo que dice la propia especificación
Merece la pena leerla, porque es insólitamente sincera.
La frase de apertura del capítulo de seguridad: el protocolo permite acceso arbitrario a datos y rutas de ejecución de código, y ese poder viene con consideraciones de confianza importantes.
Los requisitos, en forma obligatoria:
- el usuario tiene que consentir expresamente cada acceso a datos y cada operación, y tiene que entenderlos;
- el host tiene que obtener consentimiento expreso antes de entregar datos del usuario a un servidor;
- antes de invocar una herramienta hace falta consentimiento expreso;
- y la frase más importante: el texto que describe el comportamiento de las herramientas debe considerarse no fiable, salvo que venga de un servidor de confianza.
Este último punto va exactamente sobre el envenenamiento de herramientas: la propia especificación avisa de ello.
Pero la frase más sincera es esta: el protocolo no puede imponer estos principios a nivel de protocolo. La responsabilidad es del cliente.
Además, la guía oficial de seguridad describe diez ataques con nombre y con esquemas, desde el delegado confundido hasta el compromiso de un servidor local, pasando por el reenvío de tokens y el acceso a la red interna. No es una lista teórica de riesgos: la documentación del propio protocolo enumera diez formas concretas de que esto se tuerza.
A2A: no es competencia
Una pregunta frecuente es si MCP tiene rival. La respuesta corta: no es competencia, es complemento, y así lo describen ambas partes.
| Para qué sirve | |
|---|---|
| MCP | comunicación agent ↔ herramienta: cómo se conecta el agent a sus herramientas, API y recursos |
| A2A | comunicación agent ↔ agent: cómo se encuentran, se pasan una tarea y comparten un resultado |
Y una observación interesante: A2A lo desarrolló una gran empresa tecnológica que después lo donó igualmente a la Linux Foundation, con un órgano de dirección formado por representantes de ocho organizaciones y también bajo Apache 2.0.
Es decir, para 2026 los dos estándares principales de interoperabilidad entre agents han salido de las manos de su empresa fundadora hacia una fundación neutral. Eso ya es noticia de por sí.
Malentendidos habituales
- «MCP es el protocolo de una empresa.» Ya no. Está bajo la Linux Foundation, con licencia Apache 2.0, y en la gobernanza no hay asientos asignados a empresas.
- «Si está en el registro oficial, es seguro.» El propio registro escribe que deja la revisión de seguridad en otras manos. Da verificación de espacio de nombres, no un certificado.
- «Los servidores oficiales son seguros.» Entre las implementaciones de referencia hubo una fuga de datos crítica y sin clics, y los cinco SDK oficiales trajeron el mismo fallo.
- «La descripción de la herramienta es solo documentación.» Según la especificación es entrada no fiable, con la que se puede construir un ataque que funciona.
- «El protocolo impone la aprobación.» No puede. La hace obligatoria, pero el cumplimiento depende del cliente.
- «Lo he quitado de la lista, así que no se puede alcanzar.» No. En al menos un caso documentado el filtro afectaba solo al listado, no a la llamada.
Lo que conviene llevarse
MCP es algo bueno: un estándar que elimina el crecimiento cuadrático de las integraciones, hoy al cuidado de una fundación neutral, con política de obsolescencia y observabilidad estandarizada. Un protocolo adulto.
Pero conviene tener dos cosas en la cabeza. La primera: conectar algo no es instalarlo, es una decisión de confianza; la descripción de la herramienta es entrada, no documentación, y el protocolo no puede decidir eso por ti. La segunda: el permiso hay que comprobarlo en la llamada, no en el listado, y ese error no lo cometió un aficionado, sino varios servidores en producción.
Cómo funciona exactamente la llamada a herramienta desde el lado del modelo lo detalla el post tool use y function calling , campo a campo; y para recortar los permisos te da una receta práctica el post el agent con los permisos mínimos , paso a paso.