# Events Notifications in MCP | ​Aman Singh | MCP Release Party - Seattle

## Executive 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: 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: 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: 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: 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: - **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: 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: 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.

## Practical implications

- Enables the creation of 'serverless agents' that can scale down to zero cost and only wake up when a relevant event (e.g., an incident or email) occurs via webhooks.
- Significantly improves agent responsiveness by moving from continuous polling loops to event-driven, asynchronous communication.
- The design goal is to simplify adoption: developers should write one function that checks for changes since a cursor, and the SDK handles all three delivery modes (polling, push, webhook).

## Topics

MCP, Event Streams, Agentic Software Engineering, Stateless Architecture, Webhooks, Polling, Durable Logging, Design Sketch PR, Triggers and Events Working Group

Source: https://www.youtube.com/watch?v=XptRJZzPsdw