Cumplimiento de MCP 2.0

MCP Fusion usa la revisión del protocolo 2026-07-28 como predeterminada y mantiene un registro escrito de obsolescencias, porque un protocolo que cambia bajo tu servidor es un riesgo operativo. Esta página es el mapa de cumplimiento: qué está implementado, qué se eliminó y qué el framework se niega a hacer.

Contenido estructurado

ToolResponse lleva el campo structuredContent de MCP 2.0 junto al contenido de texto. successStructured(data) establece ambos: el objeto legible por máquinas y un bloque de texto JSON para clientes antiguos. Combínalo con .withOutputSchema(schema) para publicar el contrato de salida en la definición de la herramienta. Ten en cuenta que los Presenters producen la forma de texto documentada en Wire format; structuredContent es el canal analizado en paralelo, no una salida de Presenter.

Solicitudes con múltiples idas y vueltas

El modelo de solicitudes iniciadas por el servidor de 2025 no sobrevive en serverless. La respuesta de 2026 se basa en retornos: un handler devuelve que necesita entrada, el cliente la completa y vuelve a entrar. MCP Fusion lo expone como requireInput(), readInput(), los descriptores de campos ask.* y .interactive() en una herramienta, todo documentado en Streaming and cancellation. El driver admite ambas eras: en una conexión de 2026, el framework emite sin cambios la respuesta de entrada requerida y el SDK gestiona el reintento; en una conexión persistente de 2025, cumple la solicitud por el canal activo; sin canal, la llamada se degrada a ELICITATION_UNSUPPORTED y el bucle tiene un límite.

Caché de listas (SEP-2549)

Los resultados de listas pueden llevar metadatos de caché para cualquier proxy situado delante de tu conector. Configúralo una vez:

attachToServer(server, {
  listCacheTtlMs: 300_000,   // default: 5 minutes
  listCacheScope: 'private', // or 'public' for shared data
});

Los metadatos se colocan en la raíz del resultado, según la disposición de esta revisión, en tools/list, prompts/list, resources/list y resources/templates/list. Establecer listCacheTtlMs en cero los elimina sin coste adicional. Es caché de nivel de protocolo para la lista, no la señalización de obsolescencia de nivel de herramienta de State sync.

Sellado del estado de solicitudes (SEP-2322)

Cuando un servidor hace una ida y vuelta del estado de continuación mediante un cliente, ese estado no debe poder falsificarse. Proporciona una clave al iniciar:

startServer(registry, {
  transport: 'http',
  requestStateKey: process.env.REQUEST_STATE_KEY,  // 32 bytes or more
});

sealRequestState(payload) crea después un token sellado HMAC-SHA256 con expiración, y el servidor verifica cada estado sellado entrante antes de volver a entrar en un handler. Sin una clave, el framework vuelve a la serialización JSON simple y lo marca como no confiable en la documentación: seguro para una continuación no sensible, no para la identidad.

Enrutamiento por encabezados y x-mcp-header

El transporte sin estado enruta las solicitudes mediante los encabezados Mcp-Method y Mcp-Name en lugar de una sesión, lo que permite que cualquier instancia detrás de un balanceador round-robin atienda cualquier llamada. Un parámetro también puede reflejarse en un encabezado HTTP: .withHeaderParam('tenant', 'X-Tenant') anota el esquema con x-mcp-header y el cliente lo envía como Mcp-Param-X-Tenant, para que la infraestructura pueda enrutar sin analizar cuerpos. Los parámetros publicados así no deben ser secretos; el framework lanza un error con un nombre de encabezado vacío y documenta la restricción de token de RFC 9110.

Notificaciones de cambios

Hay cuatro eventos de listas y recursos conectados: notifications/tools/list_changed (transiciones de FSM, handoff, recarga en caliente), notifications/prompts/list_changed, notifications/resources/updated y notifications/resources/list_changed. En MCP 2.0, el stream subscriptions/listen registra un filtro y lo confirma, así que un cliente se suscribe una vez y recibe solo las clases de eventos que solicitó.

El registro de obsolescencias

La política de obsolescencia es honesta sobre el estilo: las funciones sin significado en el servidor simplemente están ausentes, las desaconsejadas avisan durante la validación y las eliminadas desaparecen en lugar de degradarse silenciosamente. La ventana de eliminación publicada para el conjunto obsoleto termina el 2027-07-28.

Artefactos de descubrimiento

En http y stateless, el servidor responde en /.well-known/mcp/server-card.json con una tarjeta del servidor: URL del esquema, versión, versión del protocolo, información del servidor, transporte (streamable-http con endpoint /mcp, o stdio), capacidades declaradas y las entradas de las herramientas. Se compila una vez al iniciar y se sirve con un encabezado de caché público de cinco minutos. Lee los detalles internos en Introspection.

Códigos de error gestionados por el SDK

La revisión define códigos de nivel de protocolo para discrepancias de encabezados, ausencia de una capacidad obligatoria del cliente y versión de protocolo no compatible. Los emite la capa de servidor del SDK v2 bajo el framework; el contrato de errores propio del framework es el envoltorio <tool_error> documentado en Errors.

Próximos pasos

• Runtime architecture: los transportes en la práctica
• Introspection: tarjeta y manifiesto del servidor
• Streaming and cancellation: MRTR en detalle