Qué cambió en realidad
Las versiones de MCP son fechas, y la fecha solo se mueve cuando algo rompe la compatibilidad hacia atrás. La nuestra decía 2025-06-18. La revisión actual es 2026-07-28, y la diferencia no es cosmética: elimina por completo el handshake initialize, elimina ping, mueve la versión del protocolo y las capacidades del cliente a metadatos por solicitud, exige un campo resultType en cada resultado, abandona los identificadores de sesión y la reanudación de flujos, y reemplaza las solicitudes iniciadas por el servidor con un patrón basado en reintentos.
Dicho de otro modo: aquello alrededor de lo cual están construidos nuestros servidores, un handshake que establece una sesión, ya no existe en el protocolo. Eso es reescribir el transporte, no una actualización.
Por qué no basta con subir la cadena
Un número de versión en el handshake de un protocolo no es documentación. Es una afirmación ante la otra parte sobre qué mensajes va a entender y qué formas va a devolver. El cliente la lee y cambia su comportamiento: deja de enviar cosas que usted habría necesitado, empieza a esperar campos que usted no emite y omite alternativas de respaldo que de otro modo habría usado.
Así, una versión que no implementó convierte una falla limpia, temprana y legible en una tardía y confusa. Anuncie 2025-06-18 con honestidad y un cliente moderno sabe exactamente dónde está parado desde el handshake. Anuncie 2026-07-28 en falso y lo descubre a la mitad de una llamada a herramienta, con un campo faltante y sin un culpable evidente.
Una versión vieja que es verdadera se degrada con elegancia. Una versión nueva que es falsa se rompe de forma misteriosa.
Antes de alarmarse, revise a quién le toca la compatibilidad
Antes de programar cualquier migración, lea la cláusula de compatibilidad de la especificación: a menudo dice que el trabajo no le toca a usted. La nueva revisión de MCP se lo asigna al cliente: un resultado que llega sin el campo obligatorio resultType debe tratarse como un resultado completo, precisamente para que los servidores en revisiones anteriores sigan funcionando.
Esa sola oración cambia la prioridad de toda la tarea. Nuestros servidores no estaban rotos y ninguna integración estaba en riesgo. “Vamos una revisión atrás” y “estamos rotos” son afirmaciones muy distintas, y confundirlas es como los equipos terminan convencidos de hacer reescrituras que no necesitaban.
El camino intermedio barato: implementar el descubrimiento y mantener honesta la versión
Seguía habiendo una brecha real. La nueva revisión hace obligatorio un método de descubrimiento, server/discover, porque así es como un cliente moderno le pregunta a un servidor qué revisiones habla antes de comprometerse con una. Un servidor que solo conoce initialize no puede responder, así que el cliente sondea a ciegas y falla sin saber por qué.
Así que implementamos ese único método en ambos servidores y dejamos en paz la cadena de versión. Un cliente 2026-07-28 ahora pregunta qué hablamos, recibe 2025-06-18 y negocia hacia abajo sin problema. Un cliente más antiguo nunca lo llama y no se ve afectado. Treinta minutos, sin reescribir el transporte, sin promesas falsas.
La forma general: cuando va atrasado con un protocolo, implemente primero su superficie de descubrimiento o de anuncio de capacidades. Casi siempre es la pieza más pequeña, y es la que convierte una incompatibilidad silenciosa en una negociación.
Dos cosas que nos ahorraron tiempo
Lea el esquema, no el registro de cambios. Las notas de versión en prosa nombraban los conceptos pero no los nombres de los campos, y la página de la especificación pensada para personas devolvió un cuerpo vacío dos veces. El archivo de esquema legible por máquina dio las interfaces exactas (campos obligatorios, tipos, qué tipo de resultado devuelve cada método) en una sola consulta. Para cualquier cosa que vaya a implementar, y no solo a entender, el esquema es más rápido y además es la fuente autorizada.
Deje por escrito lo que pospone. Nuestro commit nombra con precisión lo que todavía falta: la eliminación del handshake, los metadatos por solicitud, resultType en todas partes y el nuevo patrón de varias idas y vueltas. Algo pospuesto y documentado es una decisión que alguien puede revisar. Algo pospuesto sin documentar es solo deriva que se redescubrirá como sorpresa, que es el mismo modo de falla que un filtro que nadie revisó durante diez semanas.
Un límite que vale la pena decir: verificamos la respuesta de descubrimiento contra el esquema publicado y confirmamos que no hubo otras regresiones, pero ningún cliente 2026-07-28 ha negociado todavía contra ella en uso real. Esa es la parte que todavía no se ha probado, y preferimos nombrarla antes que insinuar una completitud que no nos hemos ganado.