ChatGPT now supports MCP Events, letting servers push updates to agents

What happened

According to a dev.to walkthrough, ChatGPT began supporting the proposed MCP Events specification following OpenAI's DevDay on September 29, 2026. The support covers protocol version 2026-07-28, described as MCP 2.0, and is available on all ChatGPT plans. The change reverses the usual direction of communication: instead of an agent repeatedly calling a tool to check for changes, an MCP server now pushes updates to ChatGPT the moment something happens.

The specification comes from the MCP Triggers and Events Working Group and remains experimental. The dev.to guide, which draws on OpenAI's MCP Events documentation and a design sketch draft, recommends pinning implementations to version 2026-07-28 for that reason.

How the mechanism works

A server offering events declares an events capability alongside its tools in the server/discover response, then implements three methods at the same authenticated endpoint as its tools: events/list, events/subscribe and events/unsubscribe.

Each event definition includes a stable name such as comment.created, a description of when it fires, a delivery mode, and two JSON schemas: an input schema describing the filters a subscription can pass, for example document_id, and a payload schema describing the data object in each delivery. Filters are applied server-side, and the guide stresses listing only events the connected account is actually permitted to see and subscribe to.

ChatGPT accepts webhook delivery only. The dev.to article notes there is no polling, no streaming, and no gap or terminated notifications.

Subscriptions and delivery

When a user asks ChatGPT to watch something, ChatGPT sends an events/subscribe call containing the event name, filter arguments and a webhook delivery object with the callback URL and a signing secret. Before accepting, the server is expected to check the user's authorization for the event and its arguments, validate them against the event definition, confirm the secret format (a whsec_ prefix plus base64 that decodes to between 24 and 64 bytes), and store the owner, filters, callback URL, secret and expiry.

Subscription IDs are deterministic, derived from the authenticated principal, the callback URL, the event name and the arguments, with the design sketch suggesting a truncated SHA-256 hash of that key. Re-subscribing with the same identity should update the existing record rather than create a duplicate, and arguments must be canonicalized as JSON so that key ordering does not split one logical subscription into several. ChatGPT renews subscriptions before a refreshBefore timestamp; if a renewal carries a new secret, the server should sign with both keys during a short transition window and return a null cursor for non-replayable events.

Deliveries are individual POST requests capped at 256 KiB (262,144 bytes), one event per request, and each is signed with Standard Webhooks HMAC-SHA256. Headers include webhook-id, webhook-timestamp, webhook-signature and X-MCP-Subscription-Id.

Security requirements

Before any application data is sent, the server must verify the callback endpoint by posting a signed verification message containing a single-use, short-lived challenge. The subscriber must respond with a 2xx status and echo the challenge back, which the server compares in constant time. Failures surface as JSON-RPC error -32015 (CallbackEndpointError) with a reason such as challenge_failed or timeout in the response data. Successful verifications can be cached for a limited period per principal and URL so renewals do not always trigger a fresh challenge.

The challenge matters because the subscriber supplies the signing secret; without it, an attacker could trick a server into flooding a third-party URL with requests. The guide also instructs hardening every outgoing request: allow HTTPS only, resolve DNS at connection time and check the target address, block private, local and other non-public IP ranges, and never follow HTTP redirects.

Why it matters

Polling wastes requests when nothing has changed and delays updates when something has. For agent workflows, the documented examples include watching a project board so ChatGPT can read linked documents and draft a plan when a new task arrives, turning bug reports in a channel into draft pull requests via message.created, and applying new review comments to a document via comment.created. Push delivery makes agents reactive in near real time while cutting traffic on both sides.

It also sets a pattern. OpenAI adopting a still-experimental working-group spec across all plans signals that event-driven MCP servers may become a baseline expectation for tool integrations rather than a differentiator. Developers building MCP servers now have a concrete, if version-pinned, target to implement and test against.