MCP Events would let agents subscribe to structured event streams instead of learning about changes only through an open connection and a resource reread.
2
The proposal supports polling, push connections, and webhooks so servers and clients can choose a delivery mode that fits their deployment.
3
Event subscriptions could let agents sleep while they wait, then wake up through a webhook when an incident, email, or long-running task changes.
Summary
Aman Singh presents a design sketch for Events, a proposed Model Context Protocol extension. Current MCP notifications require an open connection and usually carry only a resource URI, so the client must fetch the changed resource separately. Events would let an agent subscribe with a name and parameters, then receive a structured event payload. The proposal includes polling with cursors, long-lived push connections, and signed webhooks. Each mode fits different environments, including serverless MCP servers and clients behind NAT. Singh explains how the design fits MCP's move toward explicit state, how cursors and stable event IDs could support resumption and at-least-once delivery, and how SDKs could hide delivery negotiation. He also describes a possible MCP.task.updated event for long-running tasks. The design is intentionally narrow and remains open for feedback. Its most ambitious outcome is a serverless agent that sleeps until an event wakes it.
Current MCP notifications lose events and leave the client to fetch details
Singh opens with a P1 incident example. An agent may have access to a PagerDuty tool and be able to acknowledge, resolve, page people, or start a rollback, but MCP does not currently tell it that the incident happened unless a client connection is open. Existing notifications usually contain only a URI. The client must reread the resource to discover what changed. If the connection drops, the notification never arrives. This makes the protocol poorly suited to agents that need to react while they are idle or disconnected.
Events would give agents named subscriptions and structured payloads
The proposed Events extension would let MCP servers declare event types with a name, subscription input schema, payload schema, and supported delivery modes. An agent could subscribe to email events with a filter such as messages from a particular domain. When the parameters match, the server sends a real event. Singh's example includes the sender, subject, and message ID, while leaving out the email body. The smaller payload reduces the injection surface and limits sensitive data in event infrastructure and logs.
Polling, push, and webhooks cover different connection constraints
The design sketches three delivery modes. Polling is a self-contained request containing the subscription name, arguments, and cursor, followed by events and a new cursor. It can work with serverless servers and clients behind an application or NAT. Push uses a long-lived connection for lower latency and also fits local servers. Webhooks let the server post to a client-provided URL when an event occurs. Webhook deliveries would be signed, endpoints would prove they want the traffic, and the delivery path would be hardened against SSRF.
The proposal keeps subscription state explicit and limited
Singh distinguishes the removed implicit session state from ordinary backend state. Polling stores nothing on the server, so the client owns its cursor and stream position. Push state exists only while the stream remains open. Webhook subscriptions are a contained exception because the server initiates delivery, but the client keeps the canonical subscription list and refreshes it periodically. The server-side subscription has a TTL and need not be persisted. If the server crashes, the client repairs the subscriptions during its next refresh.
Cursors and stable event IDs support resumable delivery
Events would move replay and resumability up to the event-stream layer. A client would keep an opaque cursor and present it after reconnecting. A server backed by a durable log such as Kafka could resume from that cursor. Other servers could tell the client that events may have been missed and require a new subscription. Stable event IDs would let clients deduplicate. Singh describes at-least-once delivery as achievable for servers with a durable upstream log, while making clear that the guarantee is optional.
One server function could produce all three delivery modes
Singh's adoption goal is that implementing an event should feel like implementing a tool. The server author would write one function that accepts an opaque cursor, checks for changes after that position, and returns events. The SDK could derive polling, push, and webhook delivery from that implementation. This keeps the protocol surface small for server authors while allowing the transport details to vary by deployment.
Webhooks could let agents scale down and wake up on demand
Singh connects webhook delivery with serverless agents. An agent could subscribe, stop consuming compute while it waits, and wake when the server invokes its endpoint. He describes experiments involving a Rust-based MCP server that detects Postgres changes through a CNCF project called Rusi, along with a Dapr agent whose actors scale down to zero and start again when an event arrives. The pattern is sleep, receive an event, act, and return to sleep.
A task event could replace repeated polling for long-running work
MCP tasks are currently polling-driven, so an agent repeatedly asks whether a long-running task has finished. The working group is considering a reserved event type with a name such as MCP.task.updated. It could carry progress notifications, intermediate status or results, and a final completion callback. This would also fit a sleeping agent. The agent could start a job, scale down, and return when the server sends the completion event.
Version one deliberately excludes broader streaming features
The first version is intended to cover discrete events that agents can react to. Singh says the proposal will avoid media streams, message queue bindings, and exactly-once delivery guarantees for now. He asks people with production experience of MCP servers and event systems to review the public design sketch and contribute to the working group's discussion.
