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

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.