MCP ya tiene un calendario de lanzamientos: qué significan SEP-3398, Server Cards y la ola de seguridad de octubre para los despliegues B2B

Conclusiones clave

• La especificación de MCP ahora se publica en un calendario fijo — SEP-3398, aceptada el 14 de octubre de 2026, fija versiones cada seis meses el último martes de marzo y de septiembre y mueve el objetivo de diciembre de 2026 a finales de marzo de 2027.
• Server Cards ya es final — SEP-2127 se completó como Final el 6 de octubre de 2026, dando a los servidores MCP un documento de metadatos estándar para descubrir transports, versiones del protocolo y guías de conexión antes de establecer la conexión.
• 31 avisos de seguridad en 28 días en los repositorios oficiales — según el recuento de State of MCP October de eSEOspace, incluidos dos críticos en MCP Inspector corregidos en la versión de seguridad 1.0.3 del 21 de octubre.
• El proxy de Smithery y la identidad gestionada se apagaron el 31 de octubre de 2026 — el propio aviso de Smithery retiró las URLs de run.tools y server.smithery.ai — la prueba más clara del mes de que las rutas de distribución alquiladas son riesgo operativo.
• Planea sobre la especificación 2026-07-28 durante el invierno — el núcleo sin estado no cambia; la próxima versión llega a finales de marzo de 2027, así que los pasos de la migración se planifican en el calendario, no se reaccionan al changelog.

El proxy MCP de Smithery y el servicio de identidad gestionada se apagaron el 31 de octubre de 2026 — hoy. Cualquier despliegue de agentes que aún resolviera servidores a través de URLs de run.tools o server.smithery.ai dejó de funcionar con ello; el propio aviso de Smithery lista lo que murió: las URLs de servidores alojados, la API, Connect y Toolbox, las cuentas, las API keys y la CLI. La migración pasa por el endpoint del propio proveedor — mcp.linear.app/mcp en lugar de linear.run.tools — y los equipos que nunca tuvieron uno tuvieron que escribir uno hoy.

En los mismos 28 días, los mantenedores de MCP aceptaron el primer calendario de lanzamientos fijo del protocolo, completaron el estándar de descubrimiento Server Cards como Final y — según el recuento de eSEOspace — registraron 31 avisos de seguridad en los repositorios oficiales de MCP, con dos calificados como críticos en MCP Inspector.

Esa combinación es una sola transición vista desde tres direcciones — el calendario, el descubrimiento y las operaciones. MCP ha dejado de comportarse como pegamento de movimiento rápido y ha empezado a comportarse como infraestructura gestionada. Este artículo lee el registro de octubre como una sola señal y traza el ritmo operativo que implica: fije la versión de la especificación, ponga en el calendario los pasos de cada versión, mantén los SDK en la vía de seguridad y deje de alquilar rutas de distribución.

Esto se basa en MCP 2026-07-28: qué significa el protocolo sin estado para los despliegues de agentes B2B, que cubrió el núcleo sin estado, el patrón de handles explícitos y la matemática de despliegue de la especificación del 28 de julio. Aquí el foco es lo que cambió alrededor de esa especificación en octubre — el calendario, la capa de descubrimiento, el flujo de avisos y la caída de distribución. La tesis sin estado en sí no la toca nada de esto.

El registro de octubre en una sola vista

Leyenda: cinco eventos en 28 días convirtieron a MCP de una especificación rodante en una plataforma con calendario, un estándar de descubrimiento, una vía de versiones de seguridad y su primera caída de distribución de terceros.

Un calendario de lanzamientos aceptado y luego completado

SEP-3398 es un SEP de proceso, y los SEP de proceso rara vez dan titulares — este debería haberlos dado. Aceptado el 14 de octubre y completado el 27 de octubre, fija por escrito el ritmo de lanzamientos de MCP: versiones de la especificación cada seis meses, «generalmente el último martes de marzo y de septiembre», con un ciclo de trabajo de ocho meses por versión — dos meses de planificación, una ventana de revisión de Core Maintainers programada y una fase de estabilización — donde los ciclos sucesivos se solapan dos meses. La cláusula de transición hace el resto: el objetivo de la versión de diciembre de 2026 pasa a finales de marzo de 2027.

Para los mantenedores esto es gestión de capacidad de revisión. Para un despliegue B2B es infraestructura de planificación:

• Las ventanas de obsolescencia ahora son planificables en el calendario. Roots, Sampling, Logging y el transporte HTTP+SSE obsoleto ya llevaban una ventana de anotación de 12 meses desde la especificación del 28 de julio. Un calendario fijo convierte «12 meses desde el 28 de julio» en un hito de la misma hoja de ruta que las ventanas de release de los ERP.
• El trabajo sin terminar se mueve; la fecha no. Las propuestas ligadas a la versión deben ser Final y completarse antes del soft freeze; las propuestas sin terminar pasan a un ciclo posterior sin mover la fecha de la versión. Ese es el comportamiento que los equipos esperan de los proveedores de plataforma — previsibilidad sobre completitud.

La declaración práctica inmediata es la que eSEOspace extrajo de los datos de octubre: no se publicó ninguna versión nueva de la especificación — la última sigue siendo 2026-07-28, y el calendario mueve la siguiente a finales de marzo de 2027. El núcleo sin estado al que apunta su despliegue hoy sigue vigente durante el invierno.

Server Cards: el descubrimiento deja de ser un archivo de configuración

SEP-2127 (MCP Server Cards) se completó como Final el 6 de octubre — antes del SEP del calendario — y cierra la segunda mitad del problema de despliegue. La especificación sin estado define cómo habla un agente con un servidor una vez conectado. Server Cards define cómo un agente encuentra un servidor sin configuración manual: un documento de metadatos estandarizado que describe transports, versiones del protocolo y guías de conexión, expuesto por el servidor y legible por los clientes antes de que se abra cualquier conexión.

La mecánica, tomada del propio SEP: cada servidor expone su card — las cards pueden alojarse en cualquier URI no reservada, con <streamable-http-url>/server-card como ubicación recomendada — bajo el identificador de extensión io.modelcontextprotocol/server-card. Un «AI Catalog» de nivel de dominio puede enlazar o incrustar las cards relevantes, que es lo que hace posible el rastreo de registros y la autodetección de servicios sin tocar cada endpoint a mano.

El paralelo B2B es la agent card de A2A — .well-known/agent-card.json — que nuestra cobertura de A2A ya trata como punto de partida para el descubrimiento de máquina a máquina. Server Card es la misma idea para servidores de protocolo, y elimina el artefacto que la mayoría de los despliegues de agentes mantienen hoy: la lista escrita a mano de endpoints de servidores y sus esquemas de herramientas. Cuando esa lista se convierte en metadatos descubribles, la postura operativa cambia en tres sentidos — los servidores nuevos anuncian su propia superficie; los endpoints antiguos se vuelven auditables (una card que ya no coincide con el servidor vivo es un hallazgo); y las actualizaciones de proveedores dejan de requerir reconfiguración en el lado del cliente.

El soporte de SDK y clientes es el siguiente paso declarado del SEP, así que el movimiento pragmático es diseñar ya: construye los endpoints pensando en una ubicación de card y deja la lista de servidores lista para convertirse en metadatos en lugar de configuración.

La ola de seguridad de octubre: los avisos forman parte del ritmo operativo

Las filas más afiladas del registro de octubre son de seguridad, y se leen como el martes de parches de un proveedor de plataforma más que como el changelog de un proyecto aficionado. Dos críticos de MCP Inspector se publicaron el 21 de octubre, ambos corregidos en la versión de seguridad 1.0.3:

• GHSA-6x67-4w4w-9f3w — una MCP App remota puede robar el token de autenticación del proxy y ejecutar comandos locales arbitrarios (RCE). Versiones afectadas: Inspector 0.20.0 a 1.0.2.
• GHSA-4fc4-wcmh-4g86 — un callback OAuth malicioso de MCP puede cambiar el transporte a stdio y ejecutar comandos locales arbitrarios (RCE). Versiones afectadas: 0.13.0 a 1.0.2.

Fuera de Inspector, el aviso de octubre del TypeScript SDK es el que tiene dientes B2B: GHSA-jm63-cq47-j5jp — «un transporte compartido o instancias de servidor entregaban los mensajes de un cliente HTTP a otro» — calificado alto, vulnerable desde la 2.0.0 y corregido en la 2.3.0. Una fuga de datos entre clientes por transporte compartido es exactamente la clase de defecto que un despliegue B2B no puede tolerar, y aterrizó en el paquete central del SDK, no en una esquina experimental.

Las fechas de las versiones cuentan la historia de la plataforma con tanta claridad como las severidades. Python SDK 2.3.0 se publicó el 2 de octubre con comprobaciones de cabeceras más estrictas al registrar herramientas; TypeScript SDK 2.4.0 se publicó el 23 de octubre añadiendo compatibilidad con Skills-over-MCP (SEP-2640); Kotlin 0.16.0 se publicó el 27 de octubre cerrando huecos de agotamiento de memoria y dejando obsoleto SSE (release; la caracterización según la revisión de notas de release de eSEOspace). Todos los SDK oficiales principales se publicaron al menos una vez en el mes y, según la revisión de eSEOspace, el tema que los atraviesa es el endurecimiento: límites duros de tamaño de petición, número de sesiones y memoria. Su recuento de avisos en los repositorios oficiales — 31 en 28 días — es su propia contabilidad, pero la forma que describe es verificable: la vía de versiones de seguridad es ahora continua, no episódica.

La lectura para el operador es sencilla. Si su estado de MCP tiene una política de actualización de SDK, octubre es el mes en que la política tuvo que dispararse dos veces. Si no la tiene, los avisos anteriores son lo que se acumula.

Smithery: el contrato de la capa de distribución venció

El tercer evento es el que su equipo de operaciones siente hoy. El aviso de Smithery es inequívoco: el 31 de octubre de 2026, Smithery apagó sus servicios de gestión de conexiones — lo que significa que cada URL de servidor de run.tools y server.smithery.ai, la ruta del proxy alojado, la API, las cuentas, las API keys y la CLI dejaron de funcionar. El directorio smithery.ai sigue en línea como directorio público, ahora gestionado por Arcade.dev.

La migración es directa para los servidores con endpoints nativos del proveedor — el propio ejemplo de Smithery es apuntar a mcp.linear.app/mcp en lugar de linear.run.tools. Es una carrera contrarreloj para los despliegues que construyeron sobre un proxy como estrategia de distribución: sin URL nativa del proveedor, sin contrato de qué la reemplaza en su plano de control y sin auditoría de quién se conecta ahora que el proxy que registraba el tráfico ya no existe.

La lección generaliza más allá de un proveedor: si el endpoint a través del cual su flota de agentes resuelve servidores MCP pertenece a un tercero, el ciclo de vida de ese endpoint es una dependencia que no eligió ni rastrea. Octubre entregó esa prueba en el mismo mes en que el protocolo estandarizó los metadatos de descubrimiento y fijó su propio calendario de lanzamientos. La posición duradera son endpoints nativos del proveedor, según la propia guía de migración de Smithery, o endpoints que opere su equipo — la línea buy-vs-build que nuestro análisis de protección de servidores MCP dibuja para el límite, y que este registro prueba para la distribución.

La lista de control operativa para los despliegues B2B de MCP

Leyenda: seis controles que convierten la señal de octubre en política de despliegue — cada uno responde a un evento fechado del mes.

#	Control	El evento de octubre al que responde	Cómo se ve en el despliegue
1	Fija la versión de la especificación	Ninguna versión nueva de la especificación en octubre; próxima versión a finales de marzo de 2027	Apunte explícitamente a 2026-07-28; usa SDK que declaren esa versión como soportada; revisa el pin en cada hito del calendario
2	Pon en el calendario los pasos de la versión	SEP-3398: último martes de marzo y de septiembre	Pon el soft freeze (T−2,5 meses) y el hard freeze (T−1 mes) en la roadmap del equipo como ventanas de revisión, no como sorpresas
3	Mantente en la vía de seguridad de los SDK	31 avisos en octubre; dos críticos en Inspector 1.0.3	Fija el suelo de los SDK en la versión de seguridad (TS ≥ 2.3.0, Inspector ≥ 1.0.3); suscríbete a los feeds de avisos de los repositorios oficiales
4	Prefiere endpoints nativos del proveedor u operados por ti	El EOL de run.tools / server.smithery.ai de Smithery el 31 de octubre	Incluye en el inventario cada endpoint de terceros de la lista de servidores; termina las rutas dependientes del proxy u opéralas usted mismo
5	Diseña para metadatos de Server Cards	SEP-2127 Final el 6 de octubre, soporte de SDK/clientes por delante	Diseñe los endpoints pensando en la ubicación de la card; deje la lista de servidores lista para convertirse en metadatos descubribles, no en configuración
6	Trata la presencia en registros como no verificada	52.141 servidores en el registro oficial, 66% con endpoints remotos (según el recuento de eSEOspace)	Un listado no es una señal de seguridad; aplique la puerta de aprobación de módulos de la checklist de gobernanza antes de conectar un servidor de terceros

Dónde deja esto al patrón de despliegue 2026-07-28

El núcleo sin estado que nuestro análisis anterior estableció es la parte de MCP que octubre no tocó — y ese es el punto que vale la pena enunciar sin rodeos. SEP-3398 re-programa las versiones futuras; no altera la especificación a la que está fijado durante el invierno. Server Cards añade descubrimiento sin cambiar el transporte. Los avisos endurecen los SDK sobre la misma versión del protocolo. El cierre de Smithery es una decisión comercial de un tercero, no un evento del protocolo.

Si su patrón de despliegue asumía que MCP se mueve demasiado rápido para fijarlo y demasiado joven para tenerlo en el calendario, octubre es el registro de desconfirmación. Los equipos que pasan de vigilar el changelog a vigilar el calendario tratarán la versión de finales de marzo de 2027 como una revisión programada; el resto se enterará por una caída.

Lecturas relacionadas

• MCP 2026-07-28: qué significa el protocolo sin estado para los despliegues de agentes B2B — el análisis original: el núcleo sin estado, el patrón de handles explícitos y la matemática de despliegue de la especificación del 28 de julio, más la propuesta Server Cards en su estado previo a Final
• Seguridad MCP: módulos gobernados — la capa de gobernanza que convierte los flujos de aviso y aprobación en controles a nivel de módulo
• Protección de servidores MCP: comprar o construir — la pregunta del límite que este registro de octubre extiende a la distribución: qué partes del camino de conexión son suyas

---

Un ejemplo representativo: la plataforma de agentes de un distribuidor que conecta NetSuite, BigCommerce y tres catálogos de proveedores ejecuta cada módulo MCP en un endpoint nativo del proveedor u operado por ellos, fijado a la especificación 2026-07-28, con los pasos de versión de marzo/septiembre y los feeds de avisos en su runbook — de modo que un cierre del estilo de Smithery y una versión de seguridad del estilo de 1.0.3 sean ambos tiques rutinarios, no caídas. Ese despliegue sigue el método de cuatro pasos Descubrimiento → Gobernanza → Automatización → Expansión y suele estar en producción en 5–8 semanas.

Solicita un proyecto con alcance definido. Descubrimiento de una semana. Obtienes un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — decidas o no construir con nosotros.