Events Notifications in MCP | Aman Singh | MCP Release Party - Seattle
Summary
The talk introduces a proposed protocol extension for MCP (Messaging/Communication Protocol) designed to enable structured event streams. Currently, MCP only provides lightweight notifications that something has changed without specifying *what* changed or providing a payload. The new Events feature allows agents to subscribe to real-world events (e.g., incidents, emails), supporting three delivery modes—polling, push, and webhooks—to ensure reliable, low-latency communication while maintaining stateless server architecture.
Key takeaways
-
Structured Event Streams
2:03
Events allow MCP servers to declare event types with a name, input schema for subscription parameters, payload schema, and supported delivery modes. This moves beyond simple URI notifications to structured data payloads.
-
Three Delivery Modes
4:00
The proposed system supports three non-mandatory delivery methods: Simple Polling (self-contained requests using a cursor), Push (for low-latency, long-held connections), and Webhooks (server posts events to a client-provided URL).
-
Stateless Architecture
6:25
The new design maintains MCP server statelessness. Polling is inherently stateless, allowing servers to sit behind load balancers and scale horizontally. The SDKs are expected to abstract the complexity of managing these modes for developers.
Technical details
-
MCP Event Mechanics
160s
Servers declare events similar to tools, requiring a name, input schema (for subscription parameters), payload schema, and supported delivery modes. The event message is intentionally minimized in size to reduce the injection surface.
-
Polling vs. Push vs. Webhooks
240s
- **Polling:** Client sends Name/Arguments/Cursor; receives events plus a new cursor. Ideal for serverless environments or clients behind NAT. - **Push:** Used for low-latency scenarios requiring a long, live connection. - **Webhooks:** Server posts events to a client-provided URL. Requires signing and hardening against SSRF due to security concerns.
-
State and Reliability
385s
The system is designed to be stateless at the server level. Clients maintain an opaque cursor for resumability. While servers using durable logs (like Kafka) can honor this cursor, it is not mandatory. Stable IDs are supported to allow clients to deduplicate events and achieve 'at least once' delivery guarantees.
-
Task Management Future
580s
Currently, tasks use a polling-driven model. The working group plans to introduce a reserved event type (e.g., `MCP.task.updated`) to allow servers to provide progress notifications and final callbacks for long-running jobs.
Mentioned resources
- Design Sketch PR
- Triggers and Events Working Group
Channel & topics
Watch on YouTube · Back to latest
This independent, AI-assisted summary is provided for commentary and informational purposes. It may contain errors or omit important context. Please watch the original video for the creator's complete presentation. Video, thumbnail, and related copyrights belong to their respective owners.