MCP Event-Driven Extension: Freeing AI Agents from the Chat Window

From Conversational Agents to Event-Driven Agents

Most people still think of AI Agents in terms of conversational interaction — you type a command into a terminal, browser, or dedicated chat window, and the Agent springs into action. But a senior principal engineer at AWS and MCP core maintainer points out that how Agents get triggered is quietly changing.

More and more Agents are no longer waiting for human input. Instead, they're awakened by external events: messages from WhatsApp, Telegram, or Slack; PR events, Issue events, and CI build events from GitHub; alerts from monitoring systems like Datadog; even payment events. These events flow in through message queues, newsfeeds, and other systems, becoming the new starting point that drives Agents to run.

The problem is that MCP (Model Context Protocol) is fundamentally a request-response model: tools are called by the Agent, which then receives results or resources in return. It has no native ability to receive external events — and that's exactly the gap the MCP community is now working to fill.

MCP's Blind Spot: Why Event Ingestion Is So Hard

Under the current architecture, getting external events into an Agent is surprisingly painful. Imagine a GitHub webhook firing, or a long-running task dropping a message into a queue when it finishes, or a file being modified that needs to notify someone — getting any of these events to an LLM typically requires developers to build a custom, one-off mechanism.

In practice, you either poll a system constantly, or manually wire up a webhook service and figure out how to translate incoming events into messages your Agent framework can understand. Every integration is a bespoke solution — non-standard and nearly impossible to reuse.

To address this gap, the MCP community is developing an experimental extension called Triggers and Events. It allows clients to register subscriptions with an MCP server — for example, declaring "notify me when a GitHub PR is opened" or "notify me when a build completes" — and then receive those events through a well-defined mechanism. The MCP client notifies the Agent when an event is ready and injects it into the conversation stream as a message.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to give LLMs a standardized interface for tool invocation and context retrieval. Its core architecture has three layers: the MCP Host (e.g., Claude Desktop, IDE plugins), the MCP Client (the protocol client embedded in the Host), and the MCP Server (the server that exposes tools, resources, and prompt templates). The existing protocol is built on JSON-RPC 2.0, with all interactions initiated by the client and responded to by the server — a strictly synchronous request-response model. This design works well for tool-calling scenarios, but falls short when the server needs to proactively push data, such as notifying an Agent when an external system generates an event. Understanding this architectural baseline helps explain why "getting events into an Agent" requires so much glue code under the current standard.

Three Event Delivery Modes: Pull, Push, and Webhook

This experimental extension proposes three event delivery approaches, each suited to different architectural scenarios.

Pull

As the name suggests, the client repeatedly sends the same request to the server, asking whether new events are available, and the server responds when events are ready. The clever design detail here is the cursor mechanism: the client can include a cursor representing "the last event I received," and the server returns the next batch of events along with a new cursor — similar to pagination. On first subscription, a null cursor is used for bootstrapping.

What's particularly interesting is that the polling frequency is entirely up to the client — once per second or once per hour, either works. The server can also suggest when the client should poll next, such as "come back in 5 minutes" or "come back in an hour," and the client can choose whether to follow that hint.

Push

Push reuses MCP's existing stream mechanism to establish a persistent event stream between client and server. Once the connection is open, both sides maintain it via heartbeats, and whenever an event is available the server pushes it directly down that stream.

This approach is ideal for scenarios that demand low latency and high throughput. Compared to batching events and returning them all at once, a persistent connection gets events to the client much faster.

Webhook

Webhook is the most common pattern in event-driven applications, but it has never been part of the MCP ecosystem — until now. If a client has a webhook endpoint capable of receiving events, it can provide that inbound URL to the server when creating a subscription, after which the server POSTs events directly to that endpoint.

This is based on the Standard Webhooks specification, which defines how shared secrets are exchanged and how payloads are signed, allowing clients to verify that events genuinely originate from a trusted MCP server and not from a malicious actor.

It's worth noting that Webhooks are better suited to serverful Agents — those with a persistently running server. A coding assistant running on your laptop typically doesn't have a publicly exposed webhook endpoint. However, as part of a larger system, a webhook can first drop events into a queue before they flow into the Agent application.

These three delivery modes correspond to classic event consumption patterns in distributed systems, each with clear trade-offs. Pull is client-driven polling — simple to implement and requires no persistent connection, but inherently introduces latency (dependent on poll interval) and unnecessary request overhead. The cursor mechanism borrows from message queue concepts (like Kafka offsets) to solve event replay after reconnection. Push reuses HTTP SSE (Server-Sent Events) or similar long-lived connections for near-real-time server-initiated delivery, but demands stable network connectivity and is difficult to maintain in serverless or NAT environments. Webhook hands delivery control to the server and works best when the server has well-defined trigger points, but requires the client to expose a publicly accessible HTTP endpoint — making it a poor fit for locally running lightweight Agents. These three modes aren't mutually exclusive; in real deployments they can be combined based on the Agent's runtime environment and latency requirements.

Live Demo: A Serverless Earthquake Monitoring Agent

To demonstrate the extension in action, the author built an earthquake monitoring Agent. The data source is the U.S. Geological Survey (USGS) real-time earthquake feed — publicly accessible and global in coverage. The demo subscribes to earthquakes of magnitude 2.5 or greater over the past day; at the time of the demo, roughly 39 earthquakes occurred worldwide in a single day — enough to ensure data is always available, without creating high-throughput pressure.

In the application interface, the author configured a periodic report as a "customer": subscribe to earthquakes in all regions, with a briefing prompt set to run every 4 hours. At runtime, an MCP server fetches the USGS feed, then pushes newly discovered events to the Agent application via webhook, where they are injected directly into the Agent's conversation.

In the demo, a magnitude 4.6 earthquake near Tonga entered the conversation, complete with detailed USGS information and links, and the Agent immediately provided analysis. Every few hours, the Agent generates a summary briefing based on earthquakes accumulated during that window — the demo's four-hour window received 6 events — highlighting notable items such as the 5.1-magnitude event forming a significant cluster. The final output can be delivered via email or displayed on a webpage.

Architectural Highlight: Event-Driven and Fully Serverless

What makes this system particularly noteworthy is that it achieves both event-driven operation and serverless deployment simultaneously.

Typically, both MCP servers and Agents require a continuously running process. But with only a few dozen earthquakes per day, keeping a process running 24/7 is wasteful. The author's solution was to redesign the entire system as a serverless architecture: the MCP server wakes up approximately every 5 minutes, fetches the USGS API, identifies earthquakes it has never seen before, looks up which clients have subscribed to those events, and then dispatches them to the corresponding webhook URLs.

There's also a separate MCP server acting as a message scheduler, responsible for configuring briefing triggers — for example, sending one client a briefing every 4 hours and another every 8 hours, dispatching to the webhook receiver on schedule.

The flow for waking up the Agent is also elegantly designed: everything arriving via webhook first enters a queue, which then wakes the Agent. The Agent "hydrates" its conversation history from cold storage (S3 in this case), appends the new event — whether a briefing request or an earthquake — runs one LLM loop, then shuts down. Each turn of the conversation is just a single function invocation: truly serverless.

Security and concurrency are also addressed: webhooks carry HMAC signatures, verified against the shared secret agreed upon at subscription time; per-customer locking prevents concurrent Agent executions from scrambling conversation order. Generated briefings are ultimately stored via a dedicated API.

Serverless architecture, in this context, means that the Agent's execution unit doesn't exist as a persistent process. Instead it's invoked on demand, runs to completion, and is torn down — with compute costs and resource usage incurred only during active execution. The core challenge is state management: traditional conversational Agents rely on in-process memory to maintain session context, but a serverless Agent has no running process between invocations and must persist conversation history to external storage (such as S3 or a database), re-"hydrating" it into memory on each activation. The architecture demonstrated here decouples event reception from Agent execution via a queue, which also handles buffering and ordering guarantees. The locking mechanism prevents multiple concurrent function instances triggered by the same customer's events from creating race conditions on session state. This pattern maps cleanly onto existing AWS Lambda + SQS or similar cloud-native solutions, demonstrating that event-driven Agents don't necessarily require dedicated persistent services — they can be layered directly on top of mature serverless infrastructure.

A Direction Still in Experimental Stage

The author repeatedly emphasizes that Triggers and Events is currently an experimental extension. Scenarios like GitHub subscriptions shown in the examples are hypothetical rather than production-ready; the demo code is not a production-grade system and is intended purely for reference and inspiration. The MCP community holds weekly discussion sessions on Fridays, and the full proposal along with deployable demo code is publicly available. Developers are encouraged to participate and evaluate whether these three delivery modes fit their own systems.

For developers building Agents, the significance of this extension lies in its potential to standardize something that has long required everyone to reinvent the wheel — how to get external events into an Agent — making event-driven and even serverless Agent architectures far more accessible.