MCP Events: let ChatGPT follow up when your product changes

What MCP Events adds

Consider a product document that needs sign-off. Today, someone notices a new comment, opens an assistant, pastes the feedback and asks for an edit. The useful work is obvious; the repeated handoff is the friction.

With MCP Events, the user can ask ChatGPT to monitor that document and prepare edits when review comments arrive. The product’s MCP server publishes a matching event, and ChatGPT follows the task in the subscribed chat. OpenAI documents this pattern for messages, comments and other product updates. Read the official MCP Events guide.

Tools and events have different roles. A tool retrieves a document or makes an authorised edit. An event reports that something has changed. A useful workflow often needs both: a small event to bring the change to ChatGPT, then tools to retrieve context and carry out the agreed response.

The user chooses what to monitor and what should happen. Connecting a server alone does not subscribe the user to every update or grant access to every record.

Three workflows worth scoping

Document feedback → a proposed edit

A reviewer adds a comment to one selected document. The event identifies the document and comment. ChatGPT can retrieve the surrounding text and prepare a revision using the connected document tools. Our suggested first version keeps review in the loop: prepare the change, then let the user assess it.

Bug reports → an investigation or draft fix

A user subscribes to a feedback channel and asks for help with actionable bug reports. A new message can provide the trigger. A draft pull request also needs authorised repository access, enough evidence to reproduce the problem and tools for making the change. An event cannot supply those capabilities by itself.

Job updates → an explanation of a failure

A SaaS product could define a job-status event for an import or report. The user chooses a job and asks for a summary if it fails. The server sends the status update; a read tool supplies permitted diagnostics. This is an illustrative product-defined event, rather than a universal event name every server already supports.

For the first implementation, select the workflow with the clearest resource boundary and the easiest result to review. A narrow event filter is often more useful than a subscription to everything.

From subscription to delivery

1. Discover: the server describes its events and available filters.
2. Subscribe: the user sets the monitoring task. ChatGPT requests a subscription with filter arguments, a callback URL and a signing secret.
3. Verify and store: the server checks access, verifies the callback and persists the subscription with its owner and lifetime.
4. Deliver: a matching product update is sent as a signed webhook. The payload contains the event’s data.
5. Follow up: ChatGPT processes the update asynchronously and follows the user’s task with the tools and permissions available.
6. Refresh or stop: subscriptions are renewed before expiry or removed when the user stops monitoring.

A successful HTTP response acknowledges receipt. It does not prove the downstream task succeeded. Our recommended monitoring separates delivery status from the later outcome, such as whether a proposed edit or draft pull request was actually created.

What the server needs

OpenAI’s current integration requires MCP 2.0 with protocol version 2026-07-28. Events are advertised through server/discover. The server implements three methods on the authenticated endpoint:

Subscription state must survive restarts. Ownership, resource filters, destination, signing secret and expiry belong in durable storage. Repeated subscribe requests should update the same subscription instead of creating copies.

Delivery is a backend responsibility

The integration uses webhook delivery and callback verification from the draft Events specification. It does not support polling, streaming, or the draft’s gap and terminated notifications. A server needs outbound HTTPS access and a delivery process, rather than just another tool definition.

Requests use Standard Webhooks signatures. Verify callbacks before sending product data, validate public destination addresses when connecting and block redirects. Preserve event IDs across retries, sign each attempt with a fresh timestamp, and keep payloads within the documented 256 KiB limit. OpenAI explains the delivery contract.

Payloads carry data

A comment’s text may contain a request, a quotation or malicious instructions. Send it as application data; the user’s monitoring task remains the authority for the response. For larger records, send a concise event and provide a read tool for the full context.

Access also changes over time. A user who loses permission to a document should stop receiving its events. Check authorisation during the subscription’s lifetime, rather than only at creation.

What to test before shipping

Start with one complete ChatGPT workflow: discover the event, subscribe, verify the callback, generate a matching update, confirm delivery, inspect the response and stop monitoring. That is the first end-to-end test, rather than a successful webhook in isolation.

Then exercise the conditions that can change the result:

• A resource outside the chosen filter must produce no delivery.
• A server restart must preserve subscriptions and their expiry.
• Refreshing and repeating a subscription must not create duplicates.
• Revoked access, account disconnection and unsubscribe must stop delivery.
• Retries, duplicate events and out-of-order updates must not duplicate writes.
• Bursts should be checked with the task’s batching settings.
• A workflow that edits the source product must avoid triggering an endless feedback loop.

If an event type supports replay, test its cursor behaviour and unavailable history. Without replay, updates missed during an interruption cannot be recovered through the protocol. Decide that requirement while scoping the source, not after an outage.

How to scope a first project

Bring one sentence describing the desired workflow: “When a new review comment appears on this document, prepare the requested edit for my review.” Then identify the event source, the authenticated user, the resource filter, the tools needed for the response and the evidence that would show it worked.

We check the existing MCP server, any protocol migration, access controls, storage, delivery requirements and the target ChatGPT connection. The Events extension receives its own written scope, price and timeline. It is not included in our standard $4,900 Build.

The ChatGPT integration is documented against a draft event specification. We do not assume the same behaviour in Claude or another client; additional client support needs its own verification.

A useful first result is modest and observable: one subscribed resource, one meaningful change, one reviewed follow-up. Expand when that path works reliably.