Construye con CometAPI¿Necesitas una sola API para varios modelos?Prueba el flujo en el Playground y luego crea una clave de API cuando el modelo y el costo encajen con tu caso de uso.
MCP 2026-07-28 Guía de migración: servidores sin estado
Aprende a migrar a MCP 2026-07-28, incluyendo transporte sin estado, MRTR, encabezados de enrutamiento, almacenamiento en caché, cambios en OAuth y actualizaciones del SDK.
Mia MarenEquipo de investigación de modelos de IA y API
TL;DR: MCP 2026-07-28 elimina las sesiones a nivel de protocolo y el apretón de manos de inicialización obligatorio. Los equipos de producción deben detectar dependencias ocultas de sesión, adoptar metadatos de protocolo por solicitud, implementar Solicitudes de Múltiples Idas y Vueltas (MRTR), actualizar las políticas del gateway y realizar una implementación canaria del nuevo protocolo antes de retirar el comportamiento heredado.
La especificación de Model Context Protocol publicada el 28 de julio de 2026 introduce el mayor cambio arquitectónico en MCP desde que se añadió el soporte de transporte remoto.
El protocolo ahora usa un núcleo sin estado de petición y respuesta. El intercambio obligatorio y ha desaparecido, se ha eliminado y cada solicitud lleva la información de protocolo necesaria para procesarla.
Revisado para mayor claridad, atribución de fuentes y terminología API actual.
initialize
notifications/initialized
Mcp-Session-Id
La versión también introduce Solicitudes de Múltiples Idas y Vueltas (MRTR), encabezados de enrutamiento HTTP, respuestas de lista cacheables, un comportamiento de autorización más estricto, un marco de extensiones y un ciclo de vida de obsolescencia formal. Consulta el anuncio oficial del lanzamiento de MCP 2026-07-28 y el registro completo de cambios de la especificación para detalles a nivel de protocolo.
Estos cambios facilitan el escalado de servidores MCP remotos detrás de infraestructura HTTP estándar. No convierten automáticamente una aplicación existente en sin estado.
Un servidor en producción aún puede depender de espacios de trabajo en memoria, enrutamiento sticky, credenciales ligadas a la sesión, flujos de larga duración o interacciones iniciadas por el servidor. Esta guía se centra en detectar y sustituir esas dependencias.
¿El servidor rechaza llamadas hasta que finaliza la inicialización?
¿Un ID de sesión selecciona a un usuario, credencial, espacio de trabajo o conversación?
¿Otra instancia de servidor puede continuar un flujo iniciado por la primera?
¿El balanceador de carga requiere afinidad de sesión?
¿Una herramienta ejecuta un efecto secundario antes de solicitar confirmación?
¿El gateway analiza el body para identificar el método o la herramienta?
¿Se almacenan credenciales OAuth sin su servidor de autorización emisor?
¿El cliente depende de la reconexión SSE o la reentrega de mensajes?
¿Las listas de herramientas o recursos varían por conexión?
¿Qué funciones obsoletas aún reciben tráfico de producción?
No elimines Mcp-Session-Id hasta que entiendas qué almacena la aplicación detrás de él.
Un servidor que elimina el encabezado pero mantiene el estado en memoria local puede funcionar durante el desarrollo y fallar intermitentemente cuando las solicitudes se distribuyen entre varias instancias.
2. Sustituye el estado de sesión oculto
MCP 2026-07-28 elimina las sesiones a nivel de protocolo, no el estado de la aplicación.
El estado necesario entre llamadas debe usar uno de tres patrones.
Identificadores explícitos
Devuelve un identificador emitido por el servidor desde una herramienta y exígelo en llamadas posteriores.
{"resultType":"complete","content":[{"type":"text","text":"Espacio de trabajo creado."}],"structuredContent":{"workspaceHandle":"ws_7f93a2"}}
Una solicitud posterior pasa el identificador como un argumento ordinario:
Esto hace visible la dependencia en el contrato de la herramienta y permite que cualquier instancia de servidor compatible procese la solicitud.
Almacenamiento compartido
Usa una base de datos, caché distribuida, object store o sistema de tareas durables cuando:
varios workers necesitan el mismo estado;
el flujo debe sobrevivir a un reinicio;
el estado es demasiado grande para un identificador;
el flujo dura más que una sola solicitud;
se requiere comportamiento transaccional o de un solo uso.
requestState protegido
MRTR puede devolver un valor opaco requestState que el cliente devuelve al reintentar la solicitud original.
Como el valor pasa por el cliente, protégelo con un HMAC o cifrado autenticado. Átalo al principal autenticado, la operación original, parámetros importantes, tiempo de expiración y un nonce cuando se requiera protección contra replays.
Nunca confíes en un valor requestState sin firmar solo porque el cliente lo devolvió sin cambios.
3. Adopta solicitudes autocontenidas y discovery
Las solicitudes modernas de MCP incluyen el contexto de protocolo en _meta.
Una llamada de herramienta por HTTP transmisible puede verse así:
Los servidores dirigidos al nuevo protocolo deben implementar server/discover, que anuncia las versiones soportadas, capacidades e identidad del servidor. Los clientes pueden llamarlo antes de otra operación o usarlo para determinar si se requiere un fallback heredado.
Lee la documentación oficial de server/discover para el contrato de respuesta.
Negociación de versión en el SDK de TypeScript
Actualizar el SDK de TypeScript por sí solo no cambia automáticamente un cliente al nuevo protocolo.
Un cliente que use el SDK v2 debe optar explícitamente:
4. Sustituye solicitudes iniciadas por el servidor con MRTR
Implementaciones anteriores de MCP podían enviar solicitudes como elicitation/create, sampling/createMessage o roots/list del servidor al cliente.
El nuevo protocolo sustituye ese modelo con Solicitudes de Múltiples Idas y Vueltas.
El flujo es:
El cliente envía la solicitud original.
El servidor devuelve resultType: "input_required".
El cliente recopila la información o aprobación solicitada.
El cliente reintenta la operación original usando un nuevo ID JSON-RPC.
El reintento incluye inputResponses y el requestState original.
El servidor completa la solicitud o inicia otra ronda.
Ejemplo de respuesta:
{"jsonrpc":"2.0","id":"delete-1","result":{"resultType":"input_required","inputRequests":{"confirm_delete":{"method":"elicitation/create","params":{"mode":"form","message":"¿Eliminar el proyecto project_123?","requestedSchema":{"type":"object","properties":{"confirmed":{"type":"boolean"}},"required":["confirmed"]}}}},"requestState":"protected-expiring-state"}}
Una implementación MRTR de producción debe definir:
rondas máximas;
expiración del estado de solicitud;
comportamiento de cancelación y rechazo;
validación de esquemas de respuesta;
verificaciones de autorización en cada reintento;
protección contra replays;
idempotencia para efectos secundarios;
comportamiento cuando un cliente no soporta la capacidad solicitada.
Evita completar una compra, eliminación, deducción de crédito o escritura externa antes de devolver input_required.
Usa una operación por etapas o una clave de idempotencia para que los reintentos no dupliquen la acción. Consulta la especificación MRTR oficial para el modelo de interacción completo.
5. Actualiza gateways, caché y autorización
Los cambios de infraestructura están estrechamente relacionados y deben probarse juntos.
Valida los encabezados de enrutamiento MCP
Las solicitudes POST de HTTP transmisible ahora incluyen:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
Estos encabezados permiten que los gateways enruten, midan, autoricen y apliquen límites sin analizar cada body JSON.
Pueden soportar controles como:
límites de velocidad específicos por herramienta;
políticas separadas para métodos de listado y ejecución;
pools de workers dedicados para herramientas costosas;
acceso restringido a operaciones de alto riesgo;
métricas de latencia y errores por herramienta;
imputación de costos de infraestructura.
Los valores aún los proporciona el cliente. Compáralos con el body JSON-RPC antes de aplicar la política.
Una solicitud no debe poder afirmar una herramienta de bajo riesgo en Mcp-Name mientras invoca otra herramienta distinta en el body. Las discrepancias entre encabezados y body deben rechazarse y registrarse.
Usa claves de caché conscientes de la autorización
El nuevo protocolo añade ttlMs y cacheScope a resultados cacheables, incluidos:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
Una clave de caché normalmente debe incluir:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
No reutilices una entrada de caché privada entre usuarios o tenants solo porque el TTL no haya expirado.
La ordenación determinista de herramientas también importa. Un catálogo estable evita fallos de caché innecesarios y puede mejorar la reutilización de la caché de prompts del modelo cuando las definiciones de herramientas se insertan en prompts.
Refuerza el manejo del issuer de OAuth
Durante la migración de autorización:
valida un valor iss devuelto frente al issuer registrado para el flujo;
indexa las credenciales de cliente almacenadas por issuer;
nunca reutilices credenciales con otro servidor de autorización;
establece un application_type apropiado durante DCR;
prepara nuevas integraciones para Client ID Metadata Documents.
Dynamic Client Registration permanece disponible por compatibilidad, pero queda obsoleto como enfoque preferido de registro.
6. Migra notificaciones, tareas y funciones obsoletas
La ruta de notificación HTTP GET anterior y el flujo resources/subscribe o resources/unsubscribe han sido sustituidos por subscriptions/listen.
Los clientes abren un stream de respuesta POST de larga duración y se suscriben a las categorías de notificación que necesitan. Las notificaciones de progreso y logs específicas de una solicitud permanecen unidas al stream de respuesta de la solicitud que describen.
Para despliegues multiinstancia, usa un bus de eventos compartido cuando las notificaciones generadas en una instancia deban llegar a una suscripción conectada a otra.
Extensión Tasks
El trabajo de larga duración ha salido del protocolo core experimental y se ha movido a:
io.modelcontextprotocol/tasks
La extensión usa:
tasks/get para polling;
tasks/update para actualizaciones de cliente a servidor;
identificadores de tareas durables;
subscriptions/listen para actualizaciones a las que el cliente se ha suscrito.
Los patrones antiguos tasks/result y tasks/list no deben trasladarse a una nueva implementación.
Funciones obsoletas
Las siguientes funciones están obsoletas:
Función
Dirección recomendada
MCP 2026-07-28
Acción de migración
Roots
Pasa directorios vía argumentos de herramienta, URIs de recurso o configuración
Sin handshake obligatorio
Elimina compuertas de inicialización de solicitudes modernas
Sampling
Integra directamente con APIs del proveedor de modelos
Sin sesión a nivel de protocolo
Haz explícito el estado requerido
Logging
Usa stderr para stdio u OpenTelemetry en producción
Llamada opcional server/discover
Implementa discovery y negociación de versión
Dynamic Client Registration
Muévete hacia Client ID Metadata Documents
Incluido en _meta de la solicitud
Envía metadatos de protocolo por solicitud
HTTP+SSE heredado
Migra a HTTP transmisible (Streamable HTTP)
Encabezados Mcp-Method y Mcp-Name
Actualiza enrutamiento, política y observabilidad
Valores includeContext obsoletos
Omite el campo o usa "none"
Solicitudes de Múltiples Idas y Vueltas
Maneja input_required y reintentos
Caché de listas
Catálogos recuperados repetidamente
ttlMs, cacheScope, orden determinista
Añade caché consciente de autorización
Notificaciones
Stream GET y suscripciones a recursos
subscriptions/listen
Mueve las notificaciones de cambios al nuevo stream
La funcionalidad obsoleta permanece disponible durante la ventana de obsolescencia, pero las nuevas implementaciones no deben adoptarla. La política de ciclo de vida de MCP proporciona un período de obsolescencia mínimo de doce meses; no significa que cada función tenga la misma fecha confirmada de retirada.
No cambies clientes, servidores, gateways, caché y autorización en un único lanzamiento sin observabilidad.
Orden de migración recomendado
Inventaría versiones de protocolo, SDKs, sesiones, tráfico SSE, clientes DCR y métodos obsoletos.
Actualiza SDKs fuera de producción.
Añade server/discover y negociación de versiones.
Sustituye dependencias ocultas de sesión.
Implementa y asegura MRTR.
Añade encabezados de enrutamiento validados y cachés con alcance.
Prueba los límites del issuer de autorización.
Realiza una implementación canaria del protocolo moderno junto al camino heredado.
Retira el comportamiento antiguo solo después de revisar la telemetría.
Compatibilidad durante el canario
Cliente moderno + servidor moderno
→ Usa MCP 2026-07-28
Cliente moderno + servidor heredado
→ Sondea y retrocede cuando esté soportado
Cliente heredado + servidor con doble versión
→ Continúa por el camino heredado
Combinación no soportada
→ Devuelve un error claro de versión de protocolo
El lanzamiento de una nueva especificación MCP no es un cambio simultáneo en todo el ecosistema. Clientes, servidores, SDKs y plataformas hospedadas migrarán a diferentes velocidades.
Telemetría a registrar
Señal
Qué revela
Versión de protocolo por solicitud
Adopción y combinaciones incompatibles
Éxito de discovery y tasa de fallback
Comportamiento de negociación de versión
Encabezados MCP ausentes o inválidos
Clientes desactualizados o errores del gateway
Discrepancias encabezado/body
Errores de cliente o intentos de burlar la política
MRTR solicitadas y completadas
Fiabilidad de flujos interactivos
MRTR rechazadas o con timeout
Rutas de fallo de usuario y cliente
Fallos en verificación de request-state
Manipulación, replays o expiración
Prevención de operaciones duplicadas
Eficacia de controles de idempotencia
Tasa de aciertos de caché por scope
Reducción segura de tráfico
Fallos de validación de issuer
Problemas de configuración OAuth
Tráfico HTTP+SSE
Trabajo restante de migración de transporte
Tráfico de métodos obsoletos
Evidencia para planificar la retirada
Latencia de herramientas y tasa de tareas aceptadas
Fiabilidad visible para el usuario
Las solicitudes exitosas one-shot de tools/call no bastan para medir la migración. Un flujo que se agota reiteradamente, solicita entradas innecesarias o duplica una escritura externa sigue siendo un fallo en producción.
Cómo encaja CometAPI en una arquitectura MCP
MCP no sustituye una API de modelo. Las dos capas resuelven problemas de integración diferentes.
Capa
Responsabilidad principal
MCP
Conectar agentes con herramientas, recursos, prompts, aprobaciones y tareas
API unificada de modelos
Conectar aplicaciones con modelos, credenciales, uso y facturación
Orquestación de aplicaciones
Decidir cuándo y cómo llamar a modelos y herramientas
Una arquitectura de producción típica se ve así:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP estandariza cómo los agentes interactúan con herramientas y contexto. No estandariza la tarificación del modelo, credenciales del proveedor, endpoints de inferencia o failover de proveedor.
Esta separación es especialmente útil al migrar lejos de la capacidad obsoleta de Sampling. Si un servidor MCP o el agente que lo consume aún necesita inferencia de modelos, la aplicación puede llamar directamente a una API de modelos en lugar de depender del antiguo flujo de Sampling de MCP.
Cuándo ayuda un gateway unificado de modelos
Un gateway unificado de modelos puede reducir el trabajo operativo cuando:
varios servidores MCP necesitan acceso a distintos proveedores de modelos;
diferentes herramientas requieren modelos diferentes;
los equipos quieren cambiar de modelos sin reescribir integraciones específicas de proveedores;
las credenciales, el uso y la facturación deben gestionarse de forma centralizada;
el acceso a modelos debe permanecer independiente de cambios de transporte en MCP.
CometAPI proporciona un endpoint compatible con OpenAI que puede usarse como capa de acceso a modelos detrás de aplicaciones MCP. Esto mantiene la lógica de proveedor de modelos separada de las herramientas, recursos y orquestación de tareas de MCP.
Por ejemplo, una herramienta MCP puede llamar a un modelo a través del mismo cliente compatible con OpenAI utilizado en el resto de la aplicación:
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.COMETAPI_KEY,
baseURL: "https://api.cometapi.com/v1"
});
export async function summarizeResource(content: string) {
const response = await client.chat.completions.create({
model: "your-selected-model",
messages: [
{
role: "system",
content: "Resume el recurso proporcionado de forma clara y concisa."
},
{
role: "user",
content
}
]
});
return response.choices[0]?.message?.content ?? "";
}
El servidor MCP sigue siendo responsable del contrato de la herramienta, la autorización, el estado y el manejo del resultado. El gateway de modelos gestiona la selección de modelos, el acceso al proveedor y las respuestas de inferencia.
Mantener estas capas separadas aporta dos beneficios prácticos:
Los clientes y servidores MCP pueden migrar al nuevo protocolo sin cambiar la capa de integración de modelos.
Se pueden cambiar los proveedores de modelos sin rediseñar las herramientas MCP ni el comportamiento del transporte.
Lista de verificación de migración a MCP 2026-07-28
Cliente
Actualiza a un SDK compatible.
Habilita la negociación de versión moderna.
Soporta server/discover.
Incluye metadatos de protocolo en cada solicitud.
Maneja resultType.
Soporta o rechaza explícitamente MRTR.
Usa un nuevo ID JSON-RPC para reintentos.
Conserva y devuelve requestState.
Valida issuers de OAuth.
Almacena credenciales por issuer.
Respeta las sugerencias de caché.
Soporta subscriptions/listen cuando sea necesario.
Servidor
Elimina compuertas de inicialización para solicitudes modernas.
Elimina dependencias de Mcp-Session-Id.
Implementa server/discover.
Sustituye estado oculto por identificadores o storage compartido.
Devuelve resultType.
Sustituye solicitudes iniciadas por el servidor con MRTR.
Protege requestState.
Valida todas las inputResponses.
Añade idempotencia para efectos secundarios.
Devuelve listas deterministas.
Publica sugerencias de caché conservadoras.
Migra el trabajo de larga duración a la extensión Tasks.
Gateway e infraestructura
Valida los encabezados de solicitud MCP.
Compara los encabezados con el body de la solicitud.
Elimina el enrutamiento sticky innecesario.
Prueba solicitudes a través de varias instancias.
Separa cachés por límites de autorización.
Añade un bus de notificaciones compartido cuando se requiera.
Rastrea tráfico heredado y obsoleto.
Mantén una ruta de rollback durante el canario.
Preguntas frecuentes
¿Qué es MCP 2026-07-28?
MCP 2026-07-28 es la especificación del Model Context Protocol publicada el 28 de julio de 2026. Introduce un núcleo de protocolo sin estado, Solicitudes de Múltiples Idas y Vueltas, encabezados de enrutamiento HTTP, resultados cacheables, cambios de autorización, extensiones y un ciclo de vida de obsolescencia formal.
¿Se eliminó Mcp-Session-Id?
Sí. El nuevo protocolo de HTTP transmisible ya no usa Mcp-Session-Id.
Las aplicaciones aún pueden preservar estado mediante identificadores explícitos, almacenamiento compartido, tareas durables o valores de estado de solicitud protegidos.
¿Se eliminó el handshake de inicialización de MCP?
Sí. Las solicitudes modernas ya no requieren el intercambio initialize y notifications/initialized.
Los servidores deben implementar server/discover, aunque los clientes no necesitan llamarlo antes de cada operación.
¿MCP sin estado significa que las herramientas no pueden preservar estado?
No. Sin estado se refiere a la capa de protocolo.
Una herramienta puede seguir almacenando estado, pero el procesamiento de solicitudes no debe depender de afinidad de transporte oculta ni de un proceso de servidor específico.
¿Qué es MRTR?
Las Solicitudes de Múltiples Idas y Vueltas permiten que un servidor solicite entrada adicional del cliente o usuario sin enviar una solicitud iniciada por el servidor sobre una conexión bidireccional abierta de forma continua.
El servidor devuelve input_required y el cliente reintenta la operación original con las respuestas solicitadas.
¿Se elimina HTTP+SSE de inmediato?
No. Está obsoleto en lugar de eliminarse inmediatamente.
Los servidores nuevos deben usar HTTP transmisible, mientras que los sistemas existentes deben medir y migrar el tráfico HTTP+SSE restante.
¿Los clientes del SDK de TypeScript v2 usan MCP 2026-07-28 automáticamente?
No. El SDK v2 de TypeScript requiere una configuración explícita de negociación de versión para usar el protocolo moderno.
Usa negociación automática cuando el cliente deba funcionar con servidores modernos y heredados.
Recomendaciones finales
MCP 2026-07-28 facilita el escalado, enrutamiento, caché y observabilidad de la infraestructura MCP remota. El principal riesgo de migración no es simplemente la eliminación de un encabezado o handshake, sino el estado de aplicación oculto y la lógica de interacción que aún pueden depender de ellos.
Antes de desplegar el nuevo protocolo:
Encuentra toda dependencia de inicialización y Mcp-Session-Id.
Mueve el estado requerido a identificadores explícitos o almacenamiento compartido.
Implementa MRTR con expiración, protección contra replays e idempotencia.
Valida los encabezados MCP frente al body JSON-RPC.
Separa las cachés por tenant y scope de autorización.
Refuerza la validación del issuer de OAuth.
Mide métodos obsoletos y tráfico de transporte heredado.
Implementa caminos moderno y heredado en canario antes de retirar.
Trata la migración como un cambio de infraestructura y no como una simple actualización de SDK.
Una vez que la capa MCP sea sin estado y observable, mantén el acceso al modelo detrás de una interfaz separada. Esto permite que el protocolo de herramientas y la capa de proveedores de modelos evolucionen de forma independiente.
Registro centrado en DCR
Reglas más fuertes de issuer y dirección a CIMD
Audita clientes OAuth y almacenamiento de credenciales
Trabajo de larga duración
Tasks experimentales en el core
Extensión io.modelcontextprotocol/tasks
Muévete al contrato de extensión
Características antiguas
Roots, Sampling, Logging, HTTP+SSE
Obsoletas
Detén la adopción nueva y mide uso existente
Autorización
Registro centrado en DCR
Reglas más fuertes de issuer y dirección a CIMD
Audita clientes OAuth y almacenamiento de credenciales
Trabajo de larga duración
Tasks experimentales en el core
Extensión io.modelcontextprotocol/tasks
Muévete al contrato de extensión
Funciones antiguas
Roots, Sampling, Logging, HTTP+SSE
Obsoletas
Detén la adopción nueva y mide uso existente
MCP 2026-07-28 Guía de migración: servidores sin estado - CometAPI
