2026-09-30

ChatGPT's MCP Events: webhook triggers from your own MCP server, with real gaps

MCP Events lets ChatGPT act on webhooks from your MCP server. For teams running a remote MCP plugin who can own subscription storage and delivery.

Picture a product manager at a six-person B2B software shop. Bug reports land in a feedback channel on the team's own internal tool. Twice a day she skims it, copies the promising reports into ChatGPT, asks for a likely fix, and pastes the result into a ticket for an engineer. On quiet days that works. On busy days reports sit for hours, the copy-paste drops the surrounding context, and anything posted Friday evening is stale by Monday. The model can do the work. The problem is that it only runs when she remembers to prompt it.

That's the gap MCP Events targets. OpenAI's docs say it "lets ChatGPT subscribe to updates from your MCP server, such as new messages, content updates, or status changes." The user picks what to watch and what ChatGPT should do when an update arrives. OpenAI's own example request is "Monitor #product-feedback for bug reports and open draft pull requests with fixes and tests." Nerd's Chalk places the launch at DevDay on September 29, 2026. Apidog's DevDay status table lists it as available on all ChatGPT plans, with no fee stated, on a proposed spec.

What it is

What shipped is ChatGPT-side support for part of a draft MCP spec. OpenAI's docs say ChatGPT supports "webhook delivery and callback verification." Polling, streaming, and the draft's gap and terminated control notifications are not supported. Here's how each piece maps to the PM's problem:

Push, not remembering. When a matching event happens, your server POSTs it to a callback URL that ChatGPT supplied. ChatGPT processes it asynchronously in the subscribed chat. Nerd's Chalk describes this as working "even while you're away."
Scoped watching. Your server lists its events via events/list. Each event has an inputSchema for its filters (a channel_id or document_id, say) and a payloadSchema for the data. OpenAI tells servers to apply the filters before delivery and to return only events the connected account is allowed to discover.
Trust in the pipe. ChatGPT hands your server a whsec_ signing secret. Your server verifies the callback with a signed, single-use challenge that ChatGPT echoes back, then signs every delivery with Standard Webhooks HMAC headers.
Lifecycle. Subscriptions carry a refreshBefore expiry. ChatGPT refreshes them by calling events/subscribe again. Your server derives a deterministic subscription ID so repeat calls update rather than duplicate.

Prerequisites, per OpenAI: MCP 2.0 (protocol version 2026-07-28), persistent subscription storage, and outbound HTTPS access to callback URLs.

Alternatives:

First-party connectors in ChatGPT. KuCoin's brief frames MCP Events as opening event triggers to third-party apps, following support from Gmail, Slack and GitHub. Trade-off: if your source is one of those, there may be nothing to build. If it's your own system, they don't reach it.
ChatGPT scheduled tasks. Our sources don't document these for this use case. The trade-off in principle, and this is our analysis, is timer versus trigger: a schedule runs whether or not anything happened.
MCP Triggers & Events WG reference work, such as mcpkit's experimental/ext/events. It tracks more of the draft, including polling fields like nextPollMs and maxAgeMs. Trade-off: that issue says the package lives under experimental/ and "is not on the release train."

Who it's for

Pick it up if you already run, or are ready to run, an authenticated remote MCP server behind a ChatGPT plugin, your users work in ChatGPT, and your events are either replayable or cheap to miss now and then.

Skip it if you need this to work in Claude or another non-ChatGPT client. None was confirmed in our research, so treat this as ChatGPT-first. Also skip it if your source is already covered by a first-party connector, or if a missed event is a real incident and you have no replay story.

Before and after

Before:

The PM checks the feedback channel when she remembers.
She copies a report into ChatGPT, often without the surrounding thread.
She asks for a fix and reads the answer.
She pastes it into a ticket or hands it to an engineer.

After (as OpenAI describes the flow):

The team's MCP server advertises a message.created event, filtered by channel_id.
The PM tells ChatGPT once what to watch and how to respond, for example by opening draft PRs.
ChatGPT subscribes through the server and supplies a callback URL and signing secret.
The server verifies the callback, then POSTs each matching message as a signed event.
ChatGPT follows the standing instructions in that chat. Per OpenAI, it can group separately delivered events into one task run according to the task's batching settings.

Try it

The smallest real step, per OpenAI's guide, is to add events to your server's server/discover capabilities:

{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "complete",
"supportedVersions": ["2026-07-28"],
"capabilities": {
"tools": {},
"events": {}
}
}
}

Then implement events/list, events/subscribe and events/unsubscribe on the same authenticated endpoint as your tools. For signing, OpenAI's Node example starts with:

npm install standardwebhooks

To test, connect the server to ChatGPT through a plugin. Confirm it receives server/discover and events/list, and check that your events appear on the plugin page alongside your tools. Rescan whenever you change tools or events. On cost, Apidog reports no fee stated. Your own costs are hosting and storage.

For a sense of real scope, the mupot spike plans:

one event source
a single subscriptions table (agent, callback URL, secret hash, refresh_before, revoked_at)
an append-only receipt per delivery
the callback URL routed through an SSRF guard
body-free hints

The Neotoma issue treats events as notifications only, with writes still going through existing MCP tools.

Where it breaks

No gap recovery in ChatGPT. For event types without replay, OpenAI states plainly that "events missed during an interruption cannot be recovered through the protocol." Replayable events can resume from a cursor. Without gap and terminated, how ChatGPT handles expired subscriptions is unconfirmed. So are its own retry and deduplication behavior and how long it asks subscriptions to last. We also didn't check the exact spec semantics of gap and terminated against the working group repo.
Your server owns delivery. OpenAI puts retries with exponential backoff on your side, each with a fresh signature, and no retries on 410 or 413. Events can arrive out of order, so write tools must be idempotent. Payloads are capped at 256 KiB, so send summaries and expose a read tool for full records.
Review gates are unconfirmed. The only safeguard we saw is the "draft pull requests" wording in OpenAI's example. We found no documented per-action confirmation for event-triggered actions. OpenAI does warn that comments and other user-authored text in payloads should be treated as data, and that servers shouldn't add instructions to the model inside events. That's a prompt-injection surface you now expose on a timer you don't control.
SSRF. Callback URLs come from outside. OpenAI requires HTTPS, blocking private and local addresses, and no redirects. Neotoma calls the subscriber-supplied URL "an SSRF surface" that needs security review.
Filter quality decides the noise. In a WG field report, a synthetic 10,000-event workload reached the runtime as 10,000, 500 or 100 events depending on server-side filtering quality. The same report did not test webhook delivery or TTL refresh.
Draft-spec drift. The WG repo says its contents "do not represent official MCP specifications." The mcpkit issue says the design sketch merged on 2026-09-08 and documents months of field-name drift. The field report notes that 2026-07-28 removed the initialize handshake. The mupot team lists as open whether negotiating the new version breaks existing 2025-06-18 clients.
Idle sessions, unclear. Nerd's Chalk says events work while you're away. The mupot team's reading is that it "does not wake an idle session or a dot." We couldn't reconcile the two, so check the behavior yourself.
Lock-in. The WG is led by people from AWS and Anthropic, but the only client we confirmed is ChatGPT.