Mastra adds experimental MCP Events with push, polling and webhook delivery

Mastra introduced MCP Events on October 23, giving its MCP servers a way to emit events to subscribed clients. The intended use is reacting to changes outside an agent conversation, such as a merged pull request, a failed deployment or an updated order status.

The release requires @mastra/mcp 2.5.0 and @mastra/core 1.79.0, or later versions. Mastra explicitly labels the feature experimental and warns that the API may change between releases. This is a release of Mastra’s implementation, rather than evidence that every MCP server or client supports the same event mechanism.

The [official example](https://mastra.ai/blog/introducing‑mcp‑events) defines a repository event on a Mastra MCPServer with an input schema, a payload schema and a matching function. The input identifies which repository a subscriber wants to follow; the payload carries the data associated with a change. Server code emits the event, and client code subscribes to it. That separates the application’s event model from how an update reaches the client. A subscription can select a particular repository without treating every repository change as relevant to every connected agent. The example demonstrates the programming pattern; OpenTools has not installed the packages or run the sample integration.

Mastra documents three delivery choices. Push, the default, holds one events/stream request open while listening for server events. Polling repeatedly requests new events, at most once a second by default. Webhook delivery sends each event as a signed POST to a client URL and requires webhook settings on MCPClient.

The polling default describes request behavior, rather than a promise of one‑second end‑to‑end delivery. Likewise, a signed POST describes the webhook mechanism; it is not an independent security assessment. The post does not establish exactly‑once delivery, durable replay, ordering or automatic prevention of repeated application side effects.

Using MCPEventsSignalProvider, a subscribed event can reach an agent’s thread as a notification. A workflow subscription can instead use an event to start a workflow run with its data. When observability is configured, Mastra says event traces are captured automatically. These behaviors are described in the release post.

For an application developer, the practical decision is which event should notify an agent and which should start a workflow. Receiving a notification does not itself grant permission to take an external action. Access controls and the behavior of the triggered application still need their own review, especially while the event API remains experimental.

AI‑generated conceptual illustration by OpenTools Team: a bell and relay switches represent event notifications reaching agents and workflows. This is illustrative artwork, not an actual product interface, company location, hardware device or tested result.