Sección 09

Versionado y cambios

Versión de este contrato

Contrato	Revisión del protocolo	Estado
v1	MCP `2026-07-28`	Vigente

Cambio compatible (herramienta nueva, campo opcional nuevo, código de error nuevo): se publica y entra en vigor de inmediato. No requiere acción de su parte.
Cambio incompatible (campo obligatorio nuevo, límite más estricto, código de error retirado): se anuncia con 90 días de antelación y las dos versiones conviven durante ese periodo.
Cambio de revisión del protocolo: se adopta con un periodo de convivencia anunciado. La propia especificación incorpora desde 2026-07-28 una política formal de obsolescencia. Un servidor ya certificado no deja de funcionar por un cambio de versión del estándar.

Relevante si su equipo conoce revisiones anteriores o encuentra ejemplos antiguos:

Cambio	Efecto en su servidor
Protocolo sin estado	Desaparecen el saludo de inicialización y el identificador de sesión. Cada petición es autónoma; puede desplegar en serverless o edge.
Nuevo `server/discover`	Su servidor debe implementarlo para anunciar versiones, capacidades e identidad.
Fuera la reanudación de flujo	Una respuesta cortada se reintenta como petición nueva. Por eso la idempotencia es obligatoria.
`resultType` en todo resultado	El Gateway solo acepta `complete`.
`subscriptions/listen`	Sustituye la suscripción anterior para avisar cambios de catálogo. Opcional.
Cabeceras `Mcp-Method` y `Mcp-Name`	Requeridas en cada POST. Las pone el SDK.
Orden determinista en `tools/list`	Recomendado por la especificación para preservar la caché del modelo.
Registro dinámico de cliente obsoleto	Sustituido por documentos de metadatos de cliente. No lo requiera.

Los SDK oficiales de TypeScript, Python, Go y C# implementan esta revisión en su línea v2.

Fecha	Versión	Cambio
2026-08-14	v1.0	Publicación inicial. Contrato anclado a MCP `2026-07-28`.