Gobernanza de MCP en 2026: qué cambió con la Linux Foundation
Anthropic donó MCP a la Linux Foundation en diciembre de 2025. Quién decide ahora la especificación, qué eliminó la versión 2026-07-28 y qué revisar.
La gobernanza de MCP es el conjunto de reglas que deciden quién puede cambiar el Model Context Protocol, cómo se aprueba un cambio y cuándo sale. Desde diciembre de 2025 esas reglas están en manos de la Agentic AI Foundation, un fondo dirigido dentro de la Linux Foundation, y ya no solo de Anthropic.
Esto afecta a cualquier equipo con un servidor MCP en producción o con uno en el presupuesto del año que viene. Un protocolo que pertenece a una empresa se mueve al ritmo de esa empresa. Un protocolo bajo una fundación se mueve con un proceso escrito de propuestas, con rastro público y un grupo de mantenedores que vienen de empresas que compiten entre sí. La primera especificación redactada entera bajo el nuevo esquema, con fecha 2026-07-28, es también la más invasiva que ha publicado MCP. Si empiezas de cero con el protocolo, lee antes qué es MCP y por qué un SaaS necesita un servidor.
Qué pasó en diciembre de 2025
El 9 de diciembre de 2025 Anthropic donó MCP a la recién creada Agentic AI Foundation (AAIF), constituida como fondo dirigido bajo la Linux Foundation. La AAIF arrancó con tres proyectos fundacionales: MCP de Anthropic, AGENTS.md de OpenAI y el framework de agentes goose de Block. El anuncio de la Linux Foundation cita a Google, Microsoft, AWS, Cloudflare y Bloomberg entre los apoyos.
La donación llegó después de la adopción, no la provocó. En el traspaso MCP declaraba más de 97 millones de descargas mensuales de sus SDK y unos 10.000 servidores activos, con soporte de cliente de primer nivel en ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. Un protocolo de ese tamaño viviendo dentro de una sola empresa es una objeción de compra que dura años. Llevarlo a una casa neutral responde a la objeción sin tocar una línea de la especificación.
Quién decide qué entra en la especificación
Dos órganos, dos oficios. La junta directiva de la AAIF lleva estrategia, presupuesto, captación de miembros y aprobación de proyectos nuevos. La dirección técnica se queda con los mantenedores de MCP. El proyecto lo dijo sin rodeos cuando se hizo el traspaso: quien decide sobre el protocolo sigue siendo el grupo de mantenedores que ya lo cuidaba.
Los cambios entran por los SEP, las Specification Enhancement Proposals. Un SEP es una propuesta escrita con responsable, ciclo de revisión y registro público. Los grupos de trabajo cubren áreas como transportes, agentes y la propia gobernanza. El grupo de mantenedores crece a la vista de todos: una actualización de abril de 2026 sumó a Clare Liguori como core maintainer y a Den Delimarsky como lead maintainer.
En la hoja de ruta de 2026 hay dos puntos que pesan más que el organigrama. El primero es la escalera de contribución: un camino documentado que va de participante de la comunidad a contribuidor de grupo de trabajo, facilitador, lead maintainer y core maintainer, con criterios explícitos en cada peldaño. El segundo es la delegación. Los grupos de trabajo de confianza pueden aceptar SEP de su área sin esperar la revisión central, de modo que los core maintainers conservan la dirección estratégica y los grupos ganan velocidad.
Hay además una puerta que antes no existía. Un SEP de Standards Track no llega al estado Final hasta que un escenario equivalente entra en la suite de conformidad. Dicho claro: una función no es definitiva hasta que existe una prueba que demuestre que una implementación la soporta. Las suites de conformidad y los niveles de SDK están financiados como trabajo continuo bajo el SEP-1730, no como una limpieza puntual.
Qué compra un asiento platino y qué no
La fundación ha crecido rápido. En su anuncio de miembros la AAIF declara 146 miembros tras incorporar 18 Gold y 79 Silver, y nombra a David Nalley, director de developer experience de AWS, presidente de la junta directiva. El nivel platino lo forman ocho empresas: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI.
Nada de eso se convierte en permiso de merge sobre la especificación. Un asiento en la junta decide dónde gasta el dinero la fundación y qué proyectos acepta. Los mantenedores deciden qué dice el protocolo. Separar esas dos palancas es justo la razón de ser de un fondo dirigido, y es lo que conviene comprobar la próxima vez que un proveedor te presente su extensión MCP como estándar. Pregunta de qué SEP viene y en qué estado está.
La especificación 2026-07-28, la primera con el nuevo proceso
La release candidate se cerró el 21 de mayo de 2026 y la especificación final se publicó el 28 de julio de 2026. Es la revisión más amplia desde el lanzamiento de MCP y se reparte en tres frentes.
El núcleo pasa a ser stateless
Desaparecen el handshake initialize e initialized, la sesión a nivel de protocolo y la cabecera Mcp-Session-Id. Eliminados, no marcados como obsoletos. La información del cliente, la versión del protocolo y las capacidades viajan ahora en el campo _meta de cada petición, así que cada llamada se describe sola. Un servidor remoto puede vivir detrás de un balanceador round-robin corriente, con cualquier instancia respondiendo a cualquier petición, sin afinidad de sesión ni almacén compartido.
Este es el cambio que cuesta horas. Los clientes antiguos siguen funcionando solo si mantienes el camino viejo junto al nuevo: dos ramas de código y una fecha para apagar la primera.
Las extensiones pasan a una vía gobernada
Las extensiones eran una convención informal. Ahora son un armazón: dentro del proceso SEP hay un Extensions Track que define cómo una extensión pasa de experimental a oficial. El primer grupo oficial incluye MCP Apps para interfaces HTML en sandbox, una versión stateless de Tasks, la Enterprise Managed Authorization y las OAuth Client Credentials.
La autorización se acerca al OAuth de siempre
La autorización del núcleo sigue más de cerca los despliegues reales de OAuth 2.0 y OpenID Connect: validación del issuer, credenciales de cliente atadas a su servidor de autorización y salida progresiva del Dynamic Client Registration hacia los Client ID Metadata Documents. La extensión Enterprise Managed Authorization permite gestionar el acceso a MCP desde el proveedor de identidad que la empresa ya tiene, por ejemplo Okta o Microsoft Entra ID. La parte operativa la contamos en cómo blindar un servidor MCP para empresas.
Qué revisar si ya tienes un servidor MCP
- Busca el estado de sesión en el código. Cada lectura de
Mcp-Session-Id, cada punto que da por hecho un handshake antes de la primera llamada a una herramienta, cada mapa en memoria indexado por sesión. Esa es la superficie a migrar. - Fija una ventana de doble camino y ponle fecha. Mantener viejo y nuevo en paralelo está previsto. Mantenerlo para siempre es la manera de que el segundo camino no llegue nunca.
- Lleva el estado por sesión a un almacén o bórralo. Con enrutado stateless, la instancia que responde puede no haber visto nunca a ese cliente.
- Relee tu autenticación con las reglas nuevas. Si dependes del Dynamic Client Registration, planifica el paso a Client ID Metadata Documents y añade validación del issuer.
- Sigue la suite de conformidad, no los blogs. Cuando una función de la que dependes tiene escenario de conformidad, en una revisión de seguridad tienes algo comprobable que enseñar.
El soporte del lado cliente llega en el calendario de cada proveedor. Anthropic publicó su plan de despliegue para Claude aparte de la fecha de la especificación, y el resto de plataformas hizo lo mismo.
Qué no arregla la gobernanza de una fundación
Tres límites que conviene decir en voz alta.
La gobernanza fija quién decide, no a qué velocidad. Un proceso con grupos de trabajo, ciclos de revisión y puerta de conformidad es más lento que una empresa publicando un cambio un martes. Ese tiempo se paga a cambio de estabilidad.
La especificación no son las implementaciones. Que una función llegue a Final te dice que el estándar se ha asentado. No te dice si los tres clientes que usan tus usuarios ya la han publicado.
Las extensiones todavía pueden fragmentar el terreno. Una vía gobernada hace la fragmentación visible y discutible. No la hace imposible. Si la extensión de un proveedor es la única razón por la que tu servidor habla con su cliente, tienes una dependencia que ninguna fundación te va a quitar.
Para un equipo que está decidiendo entre montar su propio servidor o comprarlo, el traspaso inclina un poco la balanza hacia montarlo. La especificación es ahora más difícil de mover para un proveedor en solitario, y el rastro de propuestas da meses de aviso antes de que llegue un cambio que rompe. El resto de la decisión, costes y carga de mantenimiento incluidos, está en servidor MCP gestionado o self-hosted.
En este texto
Preguntas frecuentes
¿La Linux Foundation controla ahora MCP?+
No. La Linux Foundation aloja a la Agentic AI Foundation, que tiene los activos y gestiona el presupuesto. Las decisiones técnicas siguen con los mantenedores de MCP a través del proceso SEP. La junta directiva aprueba proyectos y gasto, no los merges sobre la especificación. Es el reparto habitual de un fondo dirigido, y por eso una cuota platino no compra influencia sobre lo que dice el protocolo.
¿Tengo que migrar ya a la especificación 2026-07-28?+
No de inmediato, pero ponle fecha. El handshake initialize y la cabecera Mcp-Session-Id se eliminaron, no se marcaron como obsoletos, así que los clientes antiguos solo siguen funcionando mientras mantengas los dos caminos. Dos caminos significan dos conjuntos de errores y dos de pruebas. Para la mayoría de equipos el momento es el trimestre siguiente a que sus plataformas cliente principales publiquen soporte, y apagar el camino viejo cuando el tráfico baje del umbral que hayan fijado antes.
¿Cómo sé si la extensión MCP de un proveedor es estándar de verdad?+
Pide el número de SEP y su estado. Las extensiones pasan ahora por un Extensions Track dentro del proceso SEP, así que una extensión oficial tiene propuesta pública, rastro de revisión y un estado que puedes leer. Si el proveedor no sabe decirte el SEP, la extensión es suya, no del protocolo. Es legítimo y a veces útil, pero es una dependencia de un proveedor: va en el registro de riesgos, no en el diagrama de arquitectura como estándar.
¿Con gobernanza neutral se puede apostar por MCP para los próximos cinco años?+
Quita un riesgo y deja otros. La captura por parte de un proveedor es ahora mucho más difícil: hay proceso escrito, un grupo de mantenedores repartido entre empresas y una puerta de conformidad antes de que una función llegue a Final. Lo que la gobernanza no promete es que MCP gane la categoría. La interoperabilidad entre agentes sigue en disputa, y la propia AAIF aloja piezas que compiten, como AGENTS.md y goose. Una apuesta a cinco años tiene sentido para la capa de tool calling de un producto, y bastante menos para algo que no puedas reimplementar detrás de una interfaz interna.
Servicios relacionados
Studio
Empieza un proyecto.
Escribimos sobre lo que construimos. Cuéntanos qué quieres construir tú.