| Filename | Latest commit message | Latest commit date |
|---|---|---|
1590d923f7Follow-ups to keep the new additions consistent with the rest of the doc: - Recommended-grants paragraph no longer implies a server can grant no expiry unprompted; it points long-lived needs at an explicit ttlMs: null request and notes the range is a default, not a ceiling. - The throttled prose drops 'coalesced' and routes outright event-skipping to the gap signal instead of conflating it with throttling. - The well-known verification path states the result is still recorded per (principal, url); only the document fetch is cached per origin. - The bounded retry window pauses while delivery is suspended, matching the resume-pending-events behaviour on refresh. - The flow-control note lists the throttled/retryAfterMs visibility hint. - The secret-generation decision row says 'endpoint verification' instead of naming only the challenge; one leftover 'param' becomes 'argument'. |
||
| .github | ||
| docs | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
Triggers & Events Working Group
⚠️ Experimental — This repository is an incubation space for the Triggers & Events Working Group. Contents are exploratory and do not represent official MCP specifications or recommendations.
Mission
The Triggers & Events Working Group exists to define how MCP servers proactively notify clients of state changes. Today, clients learn about server-side updates by polling or holding an SSE connection open. This WG will specify a standardized callback mechanism — webhooks or similar — that lets servers push notifications when new data is available, with defined ordering guarantees that hold across all transports.
See the full Working Group Charter for scope, authority, and operations.
Scope
In Scope
- Specification work: SEPs defining the trigger/callback mechanism, subscription lifecycle, delivery semantics, and event ordering guarantees
- Reference implementations: SDK components demonstrating server-initiated notifications and client-side callback handling
- Cross-cutting concerns: Coordination with the Transports WG on transport-specific delivery behavior, and with the Agents WG where task completion notifications intersect with event triggers
- Documentation: Specification sections covering event-driven patterns and migration guidance from polling-based approaches
Out of Scope
- Changes to the transport wire format or session model (owned by the Transports WG)
- General-purpose pub/sub infrastructure beyond what the MCP protocol requires
- Modifications to existing notification primitives (
notifications/resources/updated,notifications/tools/list_changed, etc.) that do not relate to proactive server-initiated delivery
Related Groups
| Group | Overlap |
|---|---|
| Transports WG | Delivery and ordering guarantees depend on transport capabilities; callback semantics must be coherent across stdio, Streamable HTTP, and future transports |
| Agents WG | SEP-1686 (Tasks) identifies webhook-style task completion notifications as a future consideration; this WG owns that mechanism |
Leadership
| Role | Name | Organization | GitHub |
|---|---|---|---|
| Lead | Clare Liguori | Amazon Web Services | @clareliguori |
| Lead | Peter Alexander | Anthropic | @pja-ant |
Repository Contents
This repository will hold proposals, reference implementations, and experimental findings as the WG's work progresses. See CONTRIBUTING.md for how to participate.