Mastra incorpora eventos MCP

Un cambio externo puede ser el punto de partida

Mastra anunció el 23 de octubre de 2026 eventos para MCP, que conecta clientes con capacidades de servidores. El servidor emite avisos y los clientes se suscriben para recibirlos mediante push, consultas periódicas o webhooks. La extensión sigue siendo experimental.

Imaginemos la biblioteca documental ficticia Faro. Cuando aparece una nueva versión de una guía, quiere crear una ficha pendiente de revisión y, después, preparar un resumen. No quiere publicar nada automáticamente ni crear dos fichas porque un aviso llegue repetido. En la maqueta, un conector detectaría la versión y publicaría el aviso. No suponemos que el framework descubra archivos por sí solo. Ese problema pequeño permite entender qué cambia al trabajar con eventos.

En este ejemplo, el servidor es la aplicación que ofrece capacidades y el cliente es Faro, que se conecta a ellas. Un modelo interviene sólo si la aplicación lo invoca.

Un evento comunica que ocurrió algo. La reacción sigue necesitando una regla: qué dato se acepta, a qué documento corresponde y qué trabajo debe comenzar. Nuestra biblioteca distinguirá recibir un aviso, registrar una ficha y producir un borrador. Son estados diferentes, aunque una demostración los muestre seguidos.

Quién avisa y quién pregunta

Para visualizar las formas de entrega, usemos la misma novedad: la guía de atención ya tiene una versión nueva. La siguiente tabla describe opciones para nuestro diseño; no es código de configuración ni una comparación de rendimiento del producto.

En las tres opciones necesitamos saber qué ocurre si el receptor no está disponible. Escoger una forma de contacto no decide por sí solo cuánto se conserva un aviso ni si una tarea terminó. Para quien toma decisiones, esa separación evita comprar una promesa de automatización sin preguntar por recuperación.

Define el hecho antes de elegir la reacción

En el ejemplo, el aviso significa que existe una versión concreta de un documento dentro de un espacio de trabajo. Este mensaje es una maqueta editorial, sin llamadas a una API ni conexión con una instalación real:

{
  "eventId": "notice-42",
  "workspaceId": "docs-A",
  "documentId": "guide-17",
  "version": 3,
  "action": "create-review-card"
}

El identificador del evento permite reconocer esta ocurrencia. Documento y versión identifican el material que queremos revisar. El espacio evita confundir dos bibliotecas que usan el mismo nombre de guía. Ningún campo concede por sí mismo permisos para leer un archivo o ejecutar una acción.

También conservaríamos una huella del contenido del aviso. Si el mismo identificador aparece con datos diferentes, no lo trataríamos como una repetición normal: abriríamos un conflicto para revisar. El sistema necesita distinguir un envío repetido de una identidad reutilizada por error.

También decidiríamos qué hacer con versiones anteriores. Si ya existe una ficha de una versión más reciente, un aviso retrasado no debería hacerla retroceder. Esa regla pertenece a la biblioteca; no se deduce de que dos mensajes hayan llegado en cierto orden.

Un aviso repetido no tiene que crear otra ficha

La guía documenta entrega al menos una vez, deduplicación reciente por eventId y cursores limitados por la historia retenida.

En nuestra prueba imaginaria, el mismo aviso llega dos veces. Deduplicar significa reconocer la repetición y evitar procesarla como una novedad. La idempotencia describe otra propiedad: repetir la operación no añade un efecto distinto al que queríamos obtener una vez.

Faro usaría una clave de negocio que reúna biblioteca, documento, versión y creación de ficha. Aunque dos avisos diferentes describan la misma versión, ambos apuntarían a esa clave. Así separamos la identidad del mensaje de la identidad del trabajo.

La creación tendría que ser una operación indivisible con una restricción de unicidad en el repositorio. Consultar si existe una ficha y crearla después, como dos pasos independientes, deja una ventana para que dos trabajadores creen la misma. En este ejemplo sólo registramos una ficha: no pretendemos que esa transacción controle también un correo o un servicio externo.

Si mañana agregáramos un envío a otro servicio, sería otra frontera. Crear la ficha una vez no garantiza que ese envío ocurra una vez. Tendríamos que conocer la identidad de esa operación y cómo consultar su resultado antes de repetirla. Este ejemplo termina en el registro pendiente; no concede esa garantía adicional.

Por eso un filtro de mensajes recientes ayuda, pero no sustituye la regla que protege el resultado del negocio.

El cursor no sustituye el trabajo terminado

Un cursor funciona como una referencia para continuar una lectura. En Faro no lo interpretaríamos como un número de documentos aprobados ni como prueba de que un resumen quedó listo. Posición y resultado responden preguntas distintas.

Supongamos que registramos la ficha y el proceso se interrumpe antes de conservar la posición. Al retomar, podría aparecer otra vez el aviso. La clave de negocio permitiría reconocer que la ficha ya existe. Si guardáramos primero la posición y falláramos antes del registro, en cambio, podríamos avanzar dejando el trabajo pendiente sin reconocerlo.

El diseño conservaría un estado verificable de cada ficha y retomaría desde el último trabajo registrado. Guardar una marca de recepción no bastaría para declarar completada una tarea. La política exacta depende de dónde se conserva el trabajo y de qué se puede recuperar.

La lectura sobre contexto compartido entre herramientas ofrece otro problema de continuidad. Compartir información y saber qué trabajo terminó son capacidades que conviene describir por separado.

Dos instancias necesitan una memoria común

El búfer de emit vive en un proceso. Para recuperación duradera, la guía pide consultas respaldadas por almacenamiento compartido.

Pensemos ahora en dos copias del receptor de Faro. Si cada una conserva sus fichas sólo en memoria, ambas podrían creer que una versión es nueva. Reiniciar una copia también borraría lo que esa copia recordaba. Un identificador bien elegido no vuelve persistente un registro que desaparece con el proceso.

La biblioteca tendría que decidir dónde conserva los avisos recuperables, las fichas únicas y las posiciones de lectura. Son responsabilidades relacionadas, pero distintas. Compartir el registro de fichas no reconstruye automáticamente avisos que ninguna fuente haya conservado.

Para una aplicación con instancias que aparecen y desaparecen, pediríamos una demostración de recuperación con esa arquitectura. No trasladaríamos el comportamiento de un ejemplo local a un despliegue distribuido. Tampoco llamaríamos garantía de entrega ilimitada a una historia cuyo tiempo o tamaño desconocemos.

El agente interpreta datos dentro de un límite

Una vez creada la ficha, Faro podría preparar un borrador de resumen. El nombre del documento y su contenido seguirían siendo datos de entrada, no instrucciones que concedan nuevos permisos. Un texto que pida enviar archivos a otra dirección no cambiaría el objetivo definido para el receptor.

El equipo limitaría el trabajo a documentos del espacio correspondiente y a la acción prevista: crear una ficha o preparar un borrador. Un valor distinto en el campo de acción no habilitaría operaciones arbitrarias. La revisión del material y su posible publicación seguirían fuera del evento que diseñamos.

Ante cada aviso, la ficha señalaría la versión exacta que se intenta leer. Si el archivo fue retirado o el receptor ya no puede acceder, registraría ese estado pendiente; no reemplazaría silenciosamente el documento por otro que conserve un nombre parecido.

Esta frontera permite discutir el resultado con precisión. Podríamos registrar que el aviso produjo una ficha y que el resumen requiere revisión, sin presentar esa secuencia como una publicación concluida. El caso de coordinación entre interpretación y ejecución aporta otra aplicación de esa distinción; no demuestra una integración entre ambos productos.

Prueba duplicados, interrupciones y mensajes atrasados

La prueba propuesta para Faro incluiría cuatro situaciones: un aviso nuevo, el mismo aviso repetido, un aviso diferente sobre la misma versión y una versión anterior que llega después. Para cada una escribiríamos cuántas fichas esperamos y qué estado debe conservarse.

Después interrumpiríamos el proceso en dos momentos del diseño: antes de registrar una ficha y después de registrarla, pero antes de guardar la posición. Observaríamos qué reaparece al recuperar el trabajo. Estas son condiciones de una prueba futura, no ensayos que hayamos ejecutado para el artículo.

Mediríamos también si los avisos llegan más rápido de lo que se revisan las fichas. Un receptor que acumula trabajo necesita una política explícita para sus pendientes; abrir más copias sin comprender ese atraso no demuestra que pueda recuperarlos.

El registro incluiría mensajes recibidos, fichas únicas, tareas pendientes y errores. Una ejecución rápida que omita un documento no sería una mejora aceptada. No hay aquí una medición de ahorro ni de fiabilidad de Mastra: el ejemplo enseña qué evidencia pedir antes de automatizar un trabajo propio.

Adopta una extensión experimental con una pregunta precisa

SEP-3415 sigue en borrador; la API y el formato pueden cambiar. El anuncio indica @mastra/mcp 2.5.0 y @mastra/core 1.79.0 o posteriores.

El equipo fijaría las versiones de su prueba y revisaría compatibilidad antes de actualizar. La noticia describe una función del framework, no el alta de un servicio alojado para todas las cuentas o países. No verificamos una instalación, un proveedor ni acceso de consumidores.

Faro terminaría con una pregunta acotada: ¿podemos registrar una sola ficha por versión y recuperar trabajo pendiente con nuestra forma de despliegue? La respuesta requiere observaciones propias. Tener eventos disponibles no completa ese diseño.

Comparte en la Comunidad de Álvaro un cambio externo que quieras atender, la clave que identificaría su trabajo y el fallo que necesitas poder recuperar. Empieza por un efecto pequeño y reconocible.

Fuentes: anuncio de Mastra y documentación de eventos.