MCP 2026-07-28 Guía de migración: servidores sin estado

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 initialize y notifications/initialized ha desaparecido, Mcp-Session-Id se ha eliminado y cada solicitud lleva la información de protocolo necesaria para procesarla.

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.

Para una introducción más básica al recorrido de implementación, lee Cómo crear un servidor MCP para Claude Code antes de comenzar la migración.

¿Quién necesita migrar?

El esfuerzo requerido depende de cómo se use MCP en tu sistema.

Un servidor local que no conserva estado entre solicitudes puede requerir solo una actualización del SDK y pruebas de compatibilidad.

Un despliegue remoto que use sesiones, OAuth, streaming o solicitudes iniciadas por el servidor requiere una migración escalonada.

¿Qué cambió en MCP 2026-07-28?

1. Audita la implementación existente

Antes de actualizar, busca en el cliente, servidor, gateway y configuración de despliegue suposiciones de protocolo antiguas.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Luego responde a las siguientes preguntas:

1. ¿El servidor rechaza llamadas hasta que finaliza la inicialización?
2. ¿Un ID de sesión selecciona a un usuario, credencial, espacio de trabajo o conversación?
3. ¿Otra instancia de servidor puede continuar un flujo iniciado por la primera?
4. ¿El balanceador de carga requiere afinidad de sesión?
5. ¿Una herramienta ejecuta un efecto secundario antes de solicitar confirmación?
6. ¿El gateway analiza el body para identificar el método o la herramienta?
7. ¿Se almacenan credenciales OAuth sin su servidor de autorización emisor?
8. ¿El cliente depende de la reconexión SSE o la reentrega de mensajes?
9. ¿Las listas de herramientas o recursos varían por conexión?
10. ¿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:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

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í:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "migración sin estado de MCP"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

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:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

En modo automático, el SDK sondea con server/discover y puede retroceder al flujo de inicialización anterior cuando llega a un servidor heredado.

Los equipos que aún usan @modelcontextprotocol/sdk v1 deben seguir primero la guía oficial de migración del SDK de TypeScript de v1 a v2. Los equipos que ya usan v2 deben usar la guía de soporte del protocolo 2026-07-28.

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:

1. El cliente envía la solicitud original.
2. El servidor devuelve resultType: "input_required".
3. El cliente recopila la información o aprobación solicitada.
4. El cliente reintenta la operación original usando un nuevo ID JSON-RPC.
5. El reintento incluye inputResponses y el requestState original.
6. 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"
  }
}

El cliente reintenta la operación original:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "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:

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.

Revisa el registro de funciones obsoletas antes de fijar una fecha de retirada.

7. Despliega la migración de forma segura

No cambies clientes, servidores, gateways, caché y autorización en un único lanzamiento sin observabilidad.

Orden de migración recomendado

1. Inventaría versiones de protocolo, SDKs, sesiones, tráfico SSE, clientes DCR y métodos obsoletos.
2. Actualiza SDKs fuera de producción.
3. Añade server/discover y negociación de versiones.
4. Sustituye dependencias ocultas de sesión.
5. Implementa y asegura MRTR.
6. Añade encabezados de enrutamiento validados y cachés con alcance.
7. Prueba los límites del issuer de autorización.
8. Realiza una implementación canaria del protocolo moderno junto al camino heredado.
9. 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

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.

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:

1. Los clientes y servidores MCP pueden migrar al nuevo protocolo sin cambiar la capa de integración de modelos.
2. Se pueden cambiar los proveedores de modelos sin rediseñar las herramientas MCP ni el comportamiento del transporte.

Para más detalles de implementación, consulta el Quickstart de CometAPI, la documentación de la API y la guía de aplicaciones de IA multi-modelo.

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.

1. Mueve el estado requerido a identificadores explícitos o almacenamiento compartido.
2. Implementa MRTR con expiración, protección contra replays e idempotencia.
3. Valida los encabezados MCP frente al body JSON-RPC.
4. Separa las cachés por tenant y scope de autorización.
5. Refuerza la validación del issuer de OAuth.
6. Mide métodos obsoletos y tráfico de transporte heredado.
7. 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.