{"slug": "mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check", "title": "MCP Events Explained: Webhooks, Push and Polling for Agents, and What to Check Before Subscribing", "summary": "The MCP Triggers and Events working group has published MCP Events, an explicitly experimental draft extension in the experimental-ext-triggers-events repository that adds events/list, events/poll, events/stream and events/subscribe methods so an MCP server can push notifications to agents rather than only answering requests. The draft defines three delivery modes — stateless poll, a long-lived SSE stream with a heartbeat at least every 30 seconds, and Standard Webhooks-based callbacks secured with HMAC-SHA256 signatures over id.timestamp.body, a nonce verification envelope, https-only callback URLs and IANA special-purpose registry IP validation — and ChatGPT has been reported to support the proposal at protocol version 2026-07-28. Because an event feed is a new third-party path into an agent's context, the draft requires caller identity for webhook mode and adds JSON-RPC error codes -32023 through -32027.", "body_md": "# MCP Events Explained: Webhooks, Push and Polling for Agents, and What to Check Before Subscribing\n\nMCP Events is a draft extension adding events/list, events/subscribe and Standard Webhooks delivery. What it defines, and a checklist to audit an events server.\n\nUntil now an MCP server could only answer when an agent asked. **MCP Events** is a draft extension that lets a server tell the agent when something happens: a new order, a failed build, an incident opened. It is being developed by the MCP Triggers and Events working group in the `experimental-ext-triggers-events` repository, and it is explicitly **experimental**: the repository states that its contents do not represent official MCP specifications. ChatGPT has been reported to support the proposal at protocol version 2026-07-28, so servers that implement it are starting to appear.\n\nAn event feed is also a new path from a third party into an agent's context. That is the reason to read the design before connecting to one. This post summarizes what the draft defines, then lists what can be checked from the outside.\n\n## What the draft defines\n\nA server advertises the capability as `capabilities.events`. Four methods sit on the same endpoint as `tools/list`:\n\n| Method | Purpose | \n|---|---|\n| `events/list` | Returns the event types the server can emit | \n| `events/poll` | Client asks for events since a cursor | \n| `events/stream` | Long-lived request; events arrive as SSE messages (or stdio notifications) | \n| `events/subscribe` /`events/unsubscribe` | Register or remove a webhook callback | \n\nEach event type descriptor carries a `name`, a `description`, a `delivery` array that is a subset of `poll`, `push` and `webhook`, an `inputSchema` for subscription arguments and a `payloadSchema` for the event data. An actual occurrence has an `eventId` for deduplication, a timestamp, the payload, and an optional `cursor` for replay.\n\n### The three delivery modes\n\n- **Poll** is stateless. The client sends a cursor and gets back events, a new cursor and a`nextPollMs` hint.\n- **Push** keeps one`events/stream` request open per subscription. The server sends a heartbeat at least every 30 seconds carrying the current cursor.\n- **Webhook** is the one with the most moving parts. The client calls`events/subscribe` with a callback URL and a secret it generated (`whsec_` followed by base64 of 24 to 64 random bytes). The server returns a subscription id and a`refreshBefore` time; the client must refresh before then, or the subscription lapses.\n\n### How webhook delivery is secured\n\nThe draft borrows the [Standard Webhooks](https://www.standardwebhooks.com) profile. Every delivery carries `webhook-id`, `webhook-timestamp` and `webhook-signature`, where the signature is `v1,` plus the base64 HMAC-SHA256 of `id.timestamp.body` using the subscriber's secret. Receivers verify over the raw body bytes, reject timestamps older than five minutes and deduplicate on `webhook-id`.\n\nBefore a server sends real data to a new callback, it POSTs a verification envelope containing a nonce, and the endpoint must echo that nonce in a 2xx response. Callback URLs must be `https://`. The server must validate the destination IP at delivery time against the IANA special-purpose registries, connect to the validated address, and refuse redirects. That is the draft's answer to server-side request forgery: a subscription API is a way to make a server send HTTP requests to an address you choose.\n\nThe draft also requires a caller identity. A subscription is keyed on principal, callback URL, event name and arguments, so a server with no authentication cannot offer webhook mode. New JSON-RPC codes -32023 to -32027 cover not found, forbidden, resource exhausted, unsupported, and callback endpoint failure.\n\n## What to check before an agent subscribes\n\nMost of this can be read from `events/list` without receiving a single event.\n\n1. **Are the descriptions safe to hand to a model?** An agent decides whether to subscribe from the event's`description` . Zero-width characters, \"ignore previous instructions\" phrasing and hidden`<important>` blocks belong in the same review as tool descriptions.\n2. **Is there a `payloadSchema`?** It is the contract for what will land in the agent's context. An event with no schema, or one whose type is not`object` , cannot be validated by the consumer.\n3. **Do the delivery modes make sense?** An event with no`delivery` entry, or one with a mode outside poll, push and webhook, is a server that has not followed the draft.\n4. **Does a server with no authentication offer webhook delivery?** The draft says that combination is not allowed. Either the server is not implementing the draft as written or the subscription is not tied to an identity.\n5. **Does it refuse bad callbacks?** A compliant server rejects`http://` callbacks and loopback or private addresses, or fails the verification challenge. One that accepts them without a challenge has skipped the draft's main safeguard.\n6. **Will you notice when the definition changes?** The set of events, their descriptions and especially their`payloadSchema` can change under a client that subscribed last month. Pin them, and compare on every scan.\n\n## Doing it from the outside\n\nThe ContextIQ [MCP Inspector](https://contextiq.trango-compute.com/mcp-inspector) runs these checks on any public server URL. When `server/discover` reports the events capability, the scan calls `events/list`, shows each event with its delivery modes and schemas, and lints the catalog against the rules above. Each event definition is pinned, so a later scan of the same server reports which event changed and which part of it (description, schema or delivery modes).\n\nFor servers that answer without authentication and offer a webhook event that needs no arguments, the scan also sends two `events/subscribe` requests whose callbacks cannot deliver anywhere: a plain `http://` address on the reserved `.invalid` domain, and `https://127.0.0.1:9`. A refusal is recorded as a pass. An acceptance is flagged and the scan unsubscribes immediately. Anything else, such as a login wall or an unrelated error, is reported as inconclusive rather than as a pass, because the draft's wire format may still change.\n\nThe scan never opens `events/stream` and never calls `events/poll`, since both return real event data. It cannot verify replay behavior, heartbeat timing or signature correctness, and it is not a conformance test for a draft that has no conformance suite.\n\n## Where this is going\n\nIf Events becomes part of the core specification, expect the details above (method names, the delivery object, error codes) to shift. The shape is unlikely to: servers push, agents react, and the callback is the attack surface. Reviewing the catalog and the callback rules now is cheaper than doing it after an agent has been wired to a feed.\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check", "canonical_source": "https://contextiq.trango-compute.com/blog/mcp-events-draft-extension-webhooks-subscriptions-checklist", "published_at": "2026-10-14 00:00:00+00:00", "updated_at": "2026-10-15 00:08:27.912336+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "developer-tools", "artificial-intelligence"], "entities": ["MCP Events", "MCP Triggers and Events working group", "ChatGPT", "Standard Webhooks", "Model Context Protocol"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check", "markdown": "https://wpnews.pro/news/mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check.md", "text": "https://wpnews.pro/news/mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check.txt", "jsonld": "https://wpnews.pro/news/mcp-events-explained-webhooks-push-and-polling-for-agents-and-what-to-check.jsonld"}}