El 22 de agosto de 2026, los mantenedores del Model Context Protocol (MCP) publicaron un nuevo roadmap. El titular para quien construye agentes es sencillo: se acaba el polling. Entre las prioridades aparecen los server-initiated events (webhooks y canales, "para que los clientes no se queden sondeando resultados") y la maduración de la extensión Tasks (SEP-2663) hasta llevarla dentro de la especificación. Si mantienes un producto que ejecuta trabajo largo a través de MCP, esto afecta directamente a tu arquitectura. Aquí va nuestra lectura, sin humo.

Qué ha pasado

En julio, la especificación 2026-07-28 convirtió MCP de un protocolo bidireccional con estado en uno request/response sin estado: se eliminaron las sesiones y el handshake de inicialización, de modo que cualquier petición puede aterrizar en cualquier instancia detrás de un balanceador. Fue un cambio necesario para escalar, pero tuvo un coste: el trabajo de larga duración pasó a la extensión io.modelcontextprotocol/tasks con un modelo basado en polling (tasks/get y tasks/update). El cliente pregunta "¿ya está?" una y otra vez.

El roadmap del 22 de agosto reconoce esa deuda y la pone en primera línea. Además de los eventos iniciados por el servidor y de estabilizar Tasks, enumera otras prioridades: unificación del transporte HTTP-nativo, identidad de agente con credenciales estandarizadas, mejores primitivas de tool-calling y una mejor experiencia de desarrollo en los SDK. No es una release: es una declaración de rumbo. Y por eso mismo conviene leerla como lo que es, una promesa con fechas por confirmar.

Qué implica para tu producto

El polling funciona, pero tiene tres costes que hoy pagas tú: latencia entre que la tarea termina y tu cliente se entera, coste de peticiones repetidas (relevante cuando multiplicas por miles de sesiones de agentes) y complejidad de gestionar backoff, timeouts y reintentos. Los webhooks y canales del roadmap atacan justo eso.

La tentación es doble y las dos versiones son un error:

  • Sobre-invertir hoy en un bus de eventos propio, callbacks a medida y colas para simular lo que el protocolo va a estandarizar. Te construyes una jaula que tendrás que desmontar.
  • Bloquearte esperando la especificación futura y no enviar. El roadmap no trae fechas firmes; server-initiated events es una prioridad, no una fecha de release.

El punto medio es el de siempre en ingeniería honesta: una costura de abstracción. Encapsula el "estado de la tarea" detrás de una interfaz propia (algo como TaskTracker con await(taskId)) implementada hoy sobre tasks/get con polling. El día que lleguen webhooks o Tasks entre en la spec, cambias la implementación sin tocar el resto de la aplicación.

Nuestra recomendación

No hay una respuesta única; depende de qué estés construyendo.

  • Si envías un MVP de agentes o cargas de bajo volumen: quédate con el polling. Es lo más simple, está en la extensión estable y para la mayoría de casos la latencia de sondeo es irrelevante. No construyas infraestructura de eventos "por si acaso".
  • Si operas a escala o con tareas sensibles a latencia (miles de sesiones concurrentes, trabajos largos donde cada segundo cuenta): diseña ya la costura de abstracción y, si el coste del polling duele, monta un callback propio detrás de esa interfaz, sabiendo que es temporal. Vigila SEP-2663: cuando Tasks entre en la especificación, migra a ello y jubila tu implementación.
  • Si vendes a enterprise: la prioridad que más te conviene mirar no es webhooks, es identidad de agente con credenciales estandarizadas. Alinéate desde ya con el enfoque OAuth/OIDC que la spec de julio reforzó; es lo que te van a pedir en seguridad.

Nosotros, con un cliente en producción hoy, no reescribiríamos nada para perseguir webhooks que aún no existen. Pero tampoco acoplaríamos la lógica de negocio al polling: la abstracción cuesta una tarde y te ahorra una migración. El roadmap de MCP es una buena noticia precisamente porque es aburrido —convergencia hacia HTTP, identidad y menos sondeo—; lo aburrido, en infraestructura, suele ser lo que dura.

¿Estás montando agentes en producción y no tienes claro dónde poner esas costuras? En Dribba llevamos MCP a producción y orquestación multiagente con equipo senior in-house. Hablemos.