Skip to content
Today
Sections

Build Independently confirmed2 publishers 2 min read Published

ChatGPT's MCP Events require servers to store subscriptions and sign every webhook

ChatGPT has accepted MCP Events in all plans since OpenAI's DevDay on 29 September 2026, delivered only by HMAC-signed webhook. Swapping a polling tool for events means running subscription storage and callback checks against an experimental spec.

The Engineer · Build desk

Send a correction

Illustration accompanying ChatGPT's MCP Events require servers to store subscriptions and sign every webhook
Generated illustration

What happened

  • Servers advertise an events capability in server/discover and implement events/list, events/subscribe and events/unsubscribe.
  • OpenAI requires servers to provide persistent subscription storage and outbound HTTPS access to the callback URLs ChatGPT supplies.
  • ChatGPT's integration leaves out the draft spec's gap and terminated control notifications.
  • OpenAI's documented cases include turning channel bug reports into draft pull requests via message.created, filtered by channel_id.
  • The spec comes from the MCP Triggers and Events Working Group and is experimental, so the dev.to guide advises pinning to 2026-07-28.

Why it matters

  • What it costs cost A server that answered tool calls statelessly now has to keep subscription records through restarts and refresh them on schedule, so event support costs a database and an outbound HTTPS sender.
  • Who's exposed exposure Filtering and access control run on the server, so a subscribe handler that skips the authorization check would deliver one account's events into another user's chat.
  • Who has to decide decision Pinning to one experimental protocol version leaves teams deciding whether to keep their polling tools for clients that do not speak 2026-07-28.

Next story · Build · yesterday

Anthropic and OpenAI fund separate firms to station engineers inside customers

Confirmed2 publishers

When a user asks ChatGPT to watch a document or a channel, ChatGPT calls events/subscribe with the event name, the filter arguments and a webhook destination made of a callback URL and a signing secret [8]. OpenAI's documentation lists what the server does before it accepts [9]:

1. Check that the user is authorized for that event and those arguments. 2. Validate the name and arguments against the event definition, and require a secret prefixed `whsec_` whose base64 value decodes to 24 to 64 bytes. 3. Validate the callback URL, then verify it with a signed request carrying a fresh, single-use, short-lived challenge [10]. 4. Store the subscription with its owner, filters, callback URL, secret and expiration.

That byte range gives an HMAC key of 192 to 512 bits [22]. The `whsec_` prefix also makes the secret easy to find in a log file, for better and for worse. Deliveries are signed under the Standard Webhooks scheme, according to the dev.to guide [3].

The subscription ID has the strictest rules. OpenAI asks for an ID derived deterministically from the authenticated principal, the callback URL, the event name and the arguments [11]. The draft design sketch proposes a truncated SHA-256 hash of that key, the dev.to guide says [12].

The refresh loop is why. According to the guide, ChatGPT calls events/subscribe again before `refreshBefore`, with the same identity and the last stored cursor, and expects a new expiry in the reply [13]. A matching identity has to update the existing subscription [14]. OpenAI also requires arguments to be compared as canonical JSON, so a change in key order does not create a duplicate [14]. The guide adds that when a refresh carries a new secret, the server replaces the stored one [15]. Event types that cannot replay return a null cursor [18].

I think the draft gets the hard parts right. Subscribe is idempotent, grants expire, and no application data leaves the server until the callback has answered a challenge [14] [13] [10].

The dev.to guide makes the case against polling this way: an agent calling a tool on a timer sends requests when nothing has changed and can see updates late [16]. With events, the server detects the change and pushes it to ChatGPT straight away [17]. The documentation does not describe how the server learns of a change. If the system behind the MCP server can only be polled, I think the polling moves from the agent into the server. The saving then depends on whether one server-side check covers many subscriptions.

What to watch

  • A new MCP Events draft from the Triggers and Events Working Group would force servers pinned to 2026-07-28 to migrate.
  • ChatGPT adding the draft's gap and terminated notifications, or polling and streaming delivery, would change what a server has to build.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence72
Adoption
Not scored
Hype gap+5
Incentives40
Confidence70
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Since OpenAI DevDay on 29 September 2026, ChatGPT supports the proposed MCP Events specification in protocol version 2026-07-28 (MCP 2.0) in all plans.

    Reported SupportedView cited source
  2. [2]

    ChatGPT accepts only webhook delivery for MCP Events.

    Reported SupportedView cited source
  3. [3]

    The server verifies callback endpoints and signs every delivery with Standard Webhooks HMAC.

    Reported Supported Source: dev.to guideView cited source
  4. [4]

    The server implements events/list, events/subscribe and events/unsubscribe and advertises events in server/discover.

    Reported SupportedView cited source
  5. [5]

    Polling, streaming, and the draft's gap and terminated control notifications are not supported by ChatGPT's integration.

    Reported SupportedView cited source
  6. [6]

    Documented cases include turning bug reports in a channel into draft pull requests using message.created filtered by channel_id, and applying review comments to a document using comment.created filtered by document_id.

    Reported SupportedView cited source
  7. [7]

    The specification comes from the MCP Triggers and Events Working Group and is experimental; implementations should be pinned to 2026-07-28.

    Reported Supported Source: dev.to guideView cited source
  8. [8]

    When a user asks to monitor an event, ChatGPT calls events/subscribe with the event name, filter arguments, and webhook destination including a callback URL and signing secret.

    Reported SupportedView cited source
  9. [9]

    Before accepting a subscription, the server checks the user is authorized for the event and arguments, validates the event name and arguments, requires a whsec_ signing secret whose base64 value decodes to 24-64 bytes, validates and verifies the callback URL, and stores the subscription, owner, filters, callback URL, signing secret and expiration.

    Reported SupportedView cited source
  10. [10]

    Before sending application data, the server verifies the callback by sending a signed request with a fresh, single-use, short-lived challenge.

    Reported SupportedView cited source
  11. [11]

    The server derives a deterministic subscription ID from the authenticated principal, callback URL, event name and arguments.

    Reported SupportedView cited source
  12. [12]

    The MCP Events design sketch proposes a truncated SHA-256 hash of the subscription identity key.

    Reported Supported Source: dev.to guide citing the draft design sketchView cited source
  13. [13]

    ChatGPT calls events/subscribe again before refreshBefore with the same identity and the last stored cursor; the server responds with a new expiration.

    Reported Supported Source: dev.to guideView cited source
  14. [14]

    Subscription creation must be idempotent, updating the existing subscription when identity matches, with arguments compared as canonical JSON so object key order does not create duplicates.

    Reported SupportedView cited source
  15. [15]

    If a refresh contains a new secret, the server replaces the stored secret.

    Reported Supported Source: dev.to guideView cited source
  16. [16]

    Without events, an agent regularly calls a tool to find new review comments, which creates unnecessary requests when nothing has changed and can detect updates late.

    Reported Supported Source: dev.to guideView cited source
  17. [17]

    With MCP Events, the server detects changes and sends the update immediately to ChatGPT.

    Reported SupportedView cited source
  18. [18]

    The server returns cursor: null for event types that do not support replay.

    Reported SupportedView cited source
  19. [19]

    The three event methods are implemented on the same authenticated MCP endpoint as the server's tools.

    Reported SupportedView cited source
  20. [20]

    Servers apply filters such as document, project or queue IDs before delivery and return only events the connected account is allowed to discover.

    Reported SupportedView cited source
  21. [21]

    MCP Events in ChatGPT requires the server to provide persistent subscription storage and outbound HTTPS access to callback URLs.

    Reported SupportedView cited source
  22. [22]

    A signing secret of 24 to 64 bytes is a key of 192 to 512 bits.

    Derived Supported

Sources

2 independent publishers whose own reporting we read for this story.

  1. dev.to

    1 article · October 2, 2026

    MCP Events erklärt: Webhook-MCP-Server für ChatGPT erstellen und testen
  2. developers.openai.com

    1 article

    MCP Events – Plugins | OpenAI Developers

Topics and entities

Topics

Entities