MCP Events y webhooks: cuando el servidor avisa al agente

MCP Events es un borrador del Working Group Triggers & Events de MCP. Su objetivo es que un servidor pueda avisar a un cliente cuando ocurre algo, por tres vías de entrega: poll, push y webhook. No forma parte de la especificación. Es un design sketch experimental que se fusionó el 8 de septiembre de 2026 en el repositorio del grupo.

Aun así, ya tiene un implementador comercial, ChatGPT, y está dentro de la primera área del roadmap oficial. En este artículo vas a ver qué problema resuelve y qué se sabe del borrador a 3 de octubre de 2026. También verás cómo encaja con lo que ya existe en la versión 2026-07-28, es decir, subscriptions/listen y la extensión Tasks. Y, por último, qué puedes preparar en tu servidor sin atarte a algo que todavía puede cambiar.

El problema: el servidor no puede llamar a la puerta

En MCP 2026-07-28 el servidor responde, pero no inicia. La especificación lo dice sin rodeos: un servidor no puede iniciar peticiones JSON-RPC. Lo que envía al cliente son respuestas o notificaciones ligadas a una petición que el cliente abrió antes. Si no conoces todavía el núcleo sin estado de esta versión, el artículo sobre MCP 2026-07-28 lo cuenta entero.

La única vía para recibir avisos sin preguntar es subscriptions/listen: el cliente abre una petición cuya respuesta es un stream que se queda abierto. Por ese stream le llegan las notificaciones que haya pedido. Funciona bien mientras alguien lo mantenga abierto.

El caso que no cubre es justo el que más interesa a un agente: el evento ocurre cuando no hay nadie escuchando. Piensa en una alerta de rotura de stock a las tres de la mañana, un pago que se confirma horas después o un despliegue que termina cuando la conversación ya se cerró.

Tampoco puedes recibir cualquier cosa por ese stream, porque la lista es cerrada. El filtro de subscriptions/listen admite cuatro campos: cambios en la lista de tools, de prompts y de resources, y actualizaciones de URIs concretas de resources.

La extensión Tasks añade un quinto, el estado de tareas. No hay sitio para “ha entrado un pedido nuevo” como evento de dominio.

El design sketch del WG Triggers & Events

MCP tiene un grupo de trabajo Triggers and Events con estatuto propio. Se dedica a las notificaciones que inicia el servidor. Su primer resultado visible es el design sketch de MCP Events, fusionado el 8 de septiembre en el repositorio experimental del grupo.

Con las fuentes revisadas, esto es lo que se puede afirmar del borrador:

• Tres modos de entrega. En poll, el cliente pregunta. En push, el servidor envía. En webhook, el servidor hace una petición HTTP a una URL del cliente siguiendo la especificación Standard Webhooks.
• Es un experimento. Vive en un repositorio experimental-ext-* del grupo, fuera del repositorio de la especificación. No es una extensión oficial ni parte del núcleo.

flowchart LR
  E["Evento en el servidor<br/>p. ej. rotura de stock"]
  P["Poll<br/>el cliente pregunta<br/>por eventos nuevos"]
  U["Push<br/>el servidor envía<br/>el evento"]
  W["Webhook<br/>petición HTTP a una URL<br/>según Standard Webhooks"]
  C["Cliente MCP / agente"]
  G["ChatGPT: entrega por webhook<br/>y verificación del callback"]
  E --> P
  E --> U
  E --> W
  P --> C
  U --> C
  W --> C
  W -.-> G

Aquí no vas a encontrar nombres de métodos ni la forma de los mensajes. El borrador puede cambiar en cualquier momento, y copiarlos a un artículo solo sirve para que alguien los implemente tal cual. Si vas a programar contra él, lee el sketch directamente y fija la versión del commit que usas.

El modo webhook importa porque el servidor entrega el evento llamando a una URL. No espera a que el cliente pregunte ni a que mantenga un stream abierto. Ese es justo el hueco que deja subscriptions/listen.

Cómo encaja con Tasks y subscriptions/listen

El roadmap del 22 de agosto pone los eventos en su primera área, “primitivas de mensajería agéntica”. Sus responsables son Caitie McCaffrey, Clare Liguori y Peter Alexander. Según la página del roadmap, el área incluye tres cosas:

• eventos iniciados por el servidor (canales, suscripciones y webhooks), a cargo del WG Triggers & Events
• una revisión de cómo encajan Tasks y Triggers entre sí
• madurar Tasks (SEP-2663) hasta incluirlo en el núcleo.

El anuncio en el blog oficial añade que las SEP que caen en estas áreas tienen revisión preferente. El resto de áreas lo repasa el artículo sobre el roadmap de MCP.

Esa “revisión de cómo encajan” importa porque hoy ya hay dos mecanismos que se solapan en parte con los eventos:

subscriptions/listen es una petición cuya respuesta queda abierta. El servidor envía primero notifications/subscriptions/acknowledged con lo que acepta. Cada notificación posterior lleva en _meta el identificador de la suscripción, que es el ID JSON-RPC de la propia petición.

No hay reanudación. Si el stream se corta, lo que se envió mientras tanto se pierde y el cliente vuelve a abrir la suscripción. En stdio, el servidor tampoco guarda estado de suscripción entre reconexiones. Por eso sirve bien para “algo ha cambiado, vuelve a leer”, pero no para eventos que no se pueden perder.

El 5 de agosto, el SDK de C# v2.1.0 añadió un handler público para subscriptions/listen (SEP-2575) y se convirtió en el primer SDK Tier 1 que expone estas suscripciones.

Tasks resuelve otra cosa: una tool que tarda. El servidor decide convertir la llamada en tarea y devuelve un taskId con un pollIntervalMs sugerido. Después, el cliente consulta con tasks/get hasta que la tarea llega a un estado terminal. Si quiere, el cliente también puede pedir notifications/tasks añadiendo taskIds al filtro de subscriptions/listen (resumen oficial de la extensión). Es decir, Tasks ya combina poll y push, pero solo para el ciclo de vida de una operación que el cliente inició.

MCP Events generaliza la idea a eventos que el cliente no inició y añade la entrega sin conexión. Por eso el roadmap pide revisar cómo encajan. Si Tasks entra en el núcleo y los eventos llegan después, no tiene sentido que haya dos formas distintas de hacer polling o dos formas de recibir push.

Mientras tanto, Tasks sigue moviéndose. El repositorio ext-tasks publicó v0.2.0 el 23 de septiembre, y v0.2.1 y v0.2.2 el 30 de septiembre (releases). SEP-3392, en borrador, propone clasificar la extensión como Beta. El 2 de octubre, además, el SDK de TypeScript publicó un aviso alto porque “Experimental tasks were not tied to the session that created them” (GHSA-22jm-h49p-29qw).

ChatGPT implementa los webhooks del borrador

OpenAI no ha esperado a la especificación. Su documentación de MCP Events dice textualmente: “ChatGPT supports webhook delivery and callback verification from the draft MCP Events specification”. La misma página exige la versión 2026-07-28 del protocolo, a la que llama “MCP 2.0 (protocol version 2026-07-28)”. Ese apodo no es una versión oficial distinta, como explica el artículo sobre MCP 2.0.

Tres matices antes de sacar conclusiones:

• Implementa un modo, no el borrador entero. La frase de OpenAI habla de entrega por webhook y verificación del callback. No dice nada de poll ni de push.
• Implementa un borrador. Lo dice la propia OpenAI (“draft”). Si el WG cambia el diseño, la implementación de ChatGPT y la futura extensión pueden no coincidir.
• La fecha de lanzamiento no está verificada. La función está documentada, pero no hay una fuente primaria consultable que fije cuándo se activó.

Si mantienes un servidor, lo que te interesa es que ya existe un cliente comercial que llamará a tu URL si implementas esta parte del borrador. Es una razón para probarlo, pero no para tratarlo como estándar. Lo que la guía de OpenAI pide en concreto a tu servidor, paso a paso, lo contamos en agentes que despiertan con MCP Events.

El 13 de octubre de 2026, Cloudflare anunció un evento MCP para Workers Issues y enlazó al repositorio experimental del grupo. Ahí Cloudflare hace de servidor, no de cliente. Lo contamos en el caso de Cloudflare Workers Issues.

Qué preparar ya en tu servidor

Ninguna de estas recomendaciones depende de los detalles del borrador. Son decisiones de diseño que te sirven hoy y que reducen el trabajo cuando haya una extensión oficial.

1. Separa la fuente de eventos del canal de entrega. Registra los eventos de tu dominio (pedido creado, stock por debajo del mínimo, informe listo) en un almacén propio, con un identificador estable y una marca de tiempo. Poll, push y webhook pasan a ser adaptadores sobre esa fuente. Si mañana el borrador cambia el formato del webhook, cambias un adaptador, no tu lógica de negocio.
2. Usa subscriptions/listen para lo que ya cubre. Los cambios en la lista de tools y las actualizaciones de resources son núcleo de 2026-07-28, no un borrador. Trata cada notificación como una invalidación. La especificación ya dice que una notificación relevante invalida la caché del cliente aunque el TTL no haya vencido. Si una se pierde por un corte, el cliente vuelve a leer y no pasa nada.
3. Para operaciones largas, Tasks con polling. Es el camino oficial hoy, y el polling con tasks/get no necesita conexión abierta. Comprueba qué cubre tu SDK. El SDK oficial de TypeScript 2.x no implementa el lado servidor de la extensión, porque el paquete @modelcontextprotocol/ext-tasks es de cliente. El oficial de Python tampoco lo hace en la 2.2.0, aunque fastmcp 4 sí lo hace con su paquete fastmcp-tasks. Si usas tareas en TypeScript, revisa el aviso del 2 de octubre y actualiza.
4. Si apuestas por los webhooks de ChatGPT, aíslalos. Ponlos en un módulo propio, detrás de un interruptor de configuración, y anota en el código la versión del sketch que implementas. Implementa la verificación de callbacks que describe el borrador y no reutilices ese endpoint para otra cosa.
5. Sigue el WG, no solo el roadmap. Desde el PR #3336, fusionado el 28 de septiembre, cualquier idea tiene que discutirse en un WG o IG antes de abrir una SEP. Si tus casos de uso necesitan algo que el sketch no cubre, el sitio para decirlo es el WG Triggers & Events.

No hay fecha para que MCP Events llegue a la especificación. La próxima versión del protocolo se propone para el 30 de marzo de 2027, pero eso es un borrador de calendario y no implica que los eventos entren en ella. Lo cuenta el artículo sobre la próxima versión de MCP.

Si quieres dominar lo que ya es estable, el curso trata los streams, subscriptions/listen y las notificaciones en el nivel Avanzado. Tasks y el marco de extensiones están en la lección «Interacción con el usuario y extensiones». Puedes ver el temario.