Básico Lección 14 de 17 ≈ 30 min de lectura Especificación 2026-07-28

Estado actual y evolución

Especificación MCP 2026-07-28 · revisada el 15 de octubre de 2026

La versión 2026-07-28 de un vistazo, cómo cambia el protocolo (SEP, ciclo de vida de features y ventana de deprecación), extensiones oficiales, estado real del Registry y cómo mantener un servidor MCP al día atendiendo dos versiones.

Qué aprenderás

  • Explicar qué decisiones de diseño definen la versión 2026-07-28 y qué consecuencia operativa tiene cada una
  • Leer el registro de deprecaciones y calcular a partir de qué momento puede retirarse una feature
  • Distinguir core, extensión oficial, servicio en preview y borrador antes de depender de algo
  • Diseñar la política de versiones de un servidor: qué versiones atiende, cómo lo mides y cuándo dejas de atender una
  • Montar una rutina de seguimiento del changelog que no dependa de la memoria de nadie

Contenido de la lección

  1. 01 El problema
  2. 02 La versión 2026-07-28 de un vistazo
  3. 03 Cómo cambia el protocolo: SEP y ciclo de vida
  4. 04 Fuera del core: extensiones, Registry y borradores
  5. 05 Mantener un servidor al día
  6. 06 Del nivel Básico al Avanzado
  7. 07 En producción
  8. 08 Lo siguiente: llevarlo a producción

Además: quiz de comprobación y desafío práctico.

Extracto

Nortia tiene cuatro servidores MCP en producción y un agente de soporte que los usa a diario. En la revisión anual de riesgos, la controller financiera hace a la ingeniera de plataforma una pregunta que no es técnica: «si el protocolo cambió de raíz en julio, ¿cuándo vuelve a cambiar, y cuánto nos cuesta cada vez?».

La pregunta tiene respuesta, porque MCP publica sus reglas de cambio. Dicen qué estados recorre una feature antes de desaparecer y cuánto dura, como mínimo, el aviso. También dejan claro qué está ya programado para retirarse. Con eso puedes escribir una política de versiones para nortia-pedidos, nortia-facturacion, nortia-soporte y nortia-almacen que no dependa de enterarse por casualidad.

Fin del extracto · la lección sigue con 7 secciones más

Artículos relacionados

Preguntas frecuentes

¿Qué cambia en la versión 2026-07-28 de MCP?

El protocolo deja de tener estado: desaparecen el handshake initialize, las sesiones y las peticiones que iniciaba el servidor, y cada petición lleva su versión y sus capacidades en _meta. Para pedir algo al usuario el servidor contesta con input_required y el cliente repite la petición; un stream cortado ya no se reanuda, sino que la petición se reenvía con otro id; y Tasks sale del core y pasa a ser una extensión. Además quedan deprecados Roots, Sampling, Logging y el registro dinámico de clientes OAuth.

¿Cuándo se retiran Roots, Sampling y Logging de MCP?

Como pronto, en la primera versión de la especificación publicada a partir del 28 de julio de 2027: las tres se deprecaron en 2026-07-28, y las reglas de deprecación de MCP garantizan al menos doce meses de aviso contados desde la versión que las marca. Esa es la fecha más temprana posible (earliest removal) y no la de retirada real, que deciden los Core Maintainers, quizá más tarde; hasta entonces siguen funcionando. Para migrar, Roots se sustituye pasando los directorios como argumentos, como URIs o en la configuración; Sampling, llamando directamente al proveedor del modelo; y Logging, escribiendo en stderr y usando OpenTelemetry.

¿Qué es el MCP Registry y se puede publicar en él un servidor privado?

Es el catálogo oficial y centralizado donde se publican los metadatos de servidores MCP públicos; no guarda código, solo un server.json por servidor que remite a su paquete (npm, PyPI, Docker Hub) o a la dirección del servidor remoto. No acepta servidores privados, sigue en preview y puede cambiar de forma incompatible, no revisa la seguridad de lo que se publica y no deja retirar una versión una vez publicada. Para servidores internos se recomienda un registro privado propio que siga la misma especificación OpenAPI.

Temario del curso