~/ / Artículos de IA / Especificación MCP 2026-07-28: qué ha cambiado y qué revisar en tus propios archivos
Especificación MCP 2026-07-28: qué ha cambiado y qué revisar en tus propios archivos
La revisión 2026-07-28 de la especificación del Model Context Protocol (MCP) elimina las sesiones a nivel de protocolo, declara obsoletos el transporte HTTP+SSE anterior y varias funciones, y flexibiliza las reglas de los esquemas de herramientas. Este artículo resume el registro de cambios oficial y muestra cómo revisar dos archivos que escribes tú mismo: tu configuración de MCP y tus esquemas de herramientas.
Publicado: · Contrastado con la especificación oficial el 2026-10-24. Este artículo la resume y no la sustituye.
Los cambios más importantes
- Las sesiones a nivel de protocolo y la cabecera Mcp-Session-Id se eliminan del transporte Streamable HTTP. Un servidor que necesita conservar estado entre llamadas usa identificadores explícitos que él mismo crea y pasa como argumentos normales de las herramientas.
- MCP deja de tener estado: se elimina el protocolo de inicio initialize. Cada solicitud lleva en _meta su versión del protocolo y las capacidades del cliente, y si las versiones no coinciden se devuelve UnsupportedProtocolVersionError.
- Los servidores deben implementar una nueva llamada server/discover que anuncia las versiones del protocolo que admiten, sus capacidades y su identidad.
- El endpoint HTTP GET y resources/subscribe se sustituyen por subscriptions/listen, un único flujo de respuesta de larga duración para las notificaciones de cambios a las que se suscribe un cliente.
- Las solicitudes iniciadas por el servidor, como roots/list, sampling/createMessage y elicitation/create, se sustituyen por un patrón de Multi Round-Trip Requests: el servidor devuelve un resultado que pide información y el cliente repite la solicitud original con sus respuestas.
- Las tareas experimentales salen del protocolo básico y pasan a una extensión oficial.
- Se eliminan los flujos SSE reanudables (Last-Event-ID). Si un flujo de respuesta se corta, se pierde la solicitud en curso y el cliente debe enviarla de nuevo como una solicitud nueva.
Qué está ahora obsoleto
| Función | Obsoleto desde | Retirada más temprana | Migración sugerida |
|---|---|---|---|
| Roots | 2026-07-28 | Primera revisión publicada a partir del 2027-07-28 | Pasar directorios o archivos mediante parámetros de herramientas, URI de recursos o la configuración del servidor |
| Sampling | 2026-07-28 | Primera revisión publicada a partir del 2027-07-28 | Integrarse directamente con las API de los proveedores de LLM |
| Logging | 2026-07-28 | Primera revisión publicada a partir del 2027-07-28 | Registrar en stderr con stdio, o usar OpenTelemetry |
| Dynamic Client Registration | 2026-07-28 | Primera revisión publicada a partir del 2027-07-28 | Client ID Metadata Documents |
| Transporte HTTP+SSE | 2025-03-26 | Tres meses después de que SEP-2596 alcance el estado Final | Streamable HTTP |
| Los valores thisServer y allServers de includeContext | 2025-11-25 | Sigue a Sampling | Omitir el campo o usar none |
Una función obsoleta sigue formando parte de la especificación. La retirada más temprana indica cuándo pasa a ser elegible para su eliminación, y la retirada efectiva es una decisión que se toma durante la preparación de la versión. La nueva política de ciclo de vida de las funciones fija una ventana mínima de obsolescencia de doce meses.
Revisa tu configuración de MCP
Si tu configuración todavía usa el transporte HTTP+SSE, está en la lista de obsoletos. La documentación de Claude Code también califica su tipo sse de obsoleto y dice que se usen servidores HTTP cuando estén disponibles. La especificación describe el reemplazo, Streamable HTTP: el servidor expone un único endpoint que acepta POST, y el cliente envía cada mensaje JSON-RPC como su propio HTTP POST.
- Cada POST debe incluir una cabecera Accept que indique tanto application/json como text/event-stream.
- Cada POST debe incluir una cabecera MCP-Protocol-Version cuyo valor coincida con la versión del protocolo indicada en el cuerpo de la solicitud.
- Las solicitudes llevan una cabecera Mcp-Method, y una cabecera Mcp-Name en tools/call, resources/read y prompts/get.
- El servidor responde a cada solicitud con un único objeto JSON o con un flujo SSE limitado a esa solicitud.
Qué revisión del protocolo admite tu cliente es algo que debes consultar en la documentación de tu cliente. El verificador de abajo lee un .mcp.json o un claude_desktop_config.json e informa de entradas como un servidor remoto sin type, o uno que todavía usa sse.
Pruébalo: MCP Config Checker
Reglas comprobadas con la documentación el 2026-10-23.
Documentación: Claude Code / Model Context Protocol / VS Code
No se comprueba: si un comando existe, si un paquete se instala, si un servidor remoto responde ni los ajustes que otras aplicaciones leen de forma distinta.
Todo se ejecuta en tu navegador. La configuración no se sube.
Los esquemas de herramientas pueden usar todo JSON Schema 2020-12
- inputSchema y outputSchema ahora admiten cualquier palabra clave de JSON Schema 2020-12, y structuredContent puede ser cualquier valor JSON. La especificación añade requisitos para resolver $ref y límites a los recursos que pueden usar las palabras clave de composición.
- Un servidor puede marcar un parámetro de una herramienta con x-mcp-header para que su valor se copie en una cabecera HTTP Mcp-Param-{name}. El parámetro marcado debe ser una cadena, un entero o un booleano, no un número.
- La propiedad marcada debe ser alcanzable desde la raíz del esquema solo mediante claves properties. La cadena no debe pasar por items, oneOf, anyOf, allOf, not, if/then/else ni $ref.
- Un cliente que usa Streamable HTTP debe rechazar una definición de herramienta cuya anotación x-mcp-header incumpla estas reglas, lo que significa que la herramienta queda fuera del resultado de tools/list.
Para probar un esquema de herramienta, pégalo junto con un conjunto de argumentos de ejemplo en el validador de abajo. Comprueba las palabras clave habituales de Draft 2020-12 y te dice cuáles no comprueba.
Pruébalo: JSON Schema Validator
Sigue JSON Schema Draft 2020-12 en las palabras clave que admite. Lee $ref solo dentro del mismo esquema.
Todo se ejecuta en tu navegador. El esquema y los datos no se suben.
Puntos de seguridad para los servidores
- Un servidor debe validar la cabecera Origin en todas las conexiones entrantes para evitar ataques de DNS rebinding. Si la cabecera está presente y no es válida, debe responder con HTTP 403 Forbidden.
- Un servidor que se ejecuta en local debería enlazarse solo a localhost (127.0.0.1), no a todas las interfaces de red (0.0.0.0).
- Los servidores deberían implementar una autenticación adecuada para todas las conexiones.
- Un servidor que procesa el cuerpo de la solicitud debe rechazar una solicitud cuyas cabeceras no coincidan con el cuerpo, con HTTP 400 y el error JSON-RPC HeaderMismatch (código -32020).
- Los servidores de autorización deberían incluir el parámetro iss en las respuestas de autorización (RFC 9207), y cuando hay un iss, los clientes deben validarlo antes de canjear el código de autorización.
- Los clientes deben guardar las credenciales de cliente asociadas al emisor que las concedió, y no deben reutilizarlas con un servidor de autorización distinto.