Updated 14 hours ago
ChatGPT plugins can now react to MCP events, with signed webhooks and clear limits

OpenAI DevDay

ChatGPT plugins can now react to MCP events, with signed webhooks and clear limits

OpenAI's DevDay MCP Events launch lets a plugin start a ChatGPT workflow when its server reports a relevant change. The current integration uses verified, signed webhooks and leaves several mechanisms in the broader draft specification unsupported.

An event can start work without a user returning to the chat

OpenAI's [September 29 DevDay recap](https://openai.com/index/devday‑2026‑recap/) says ChatGPT plugins can start automations from events in a connected app. Its example is a new project‑board task: ChatGPT can read linked documents and draft a plan after the task arrives, including while the user is away. The announcement says the feature is available to all plans. The practical shift for a plugin builder is from asking the user to check a source repeatedly to letting the source report a specific change. The user still chooses what to monitor and what ChatGPT should do. OpenAI's full [MCP Events developer guide](https://developers.openai.com/plugins/build/mcp‑events) describes a subscription tied to a named event and filters, not a blanket stream of everything in an app. A server can expose, for example, a new message in one channel or a review comment on one document. The connected account's access controls still determine which events may be listed or subscribed to.

The plugin server must support a subscription lifecycle

The [implementation guide](https://developers.openai.com/plugins/build/mcp‑events) requires the plugin's MCP server to use MCP 2.0, protocol version 2026‑07‑28, and advertise an `events` capability. It then implements `events/list`, `events/subscribe` and `events/unsubscribe` on the same authenticated endpoint as its tools. Event definitions include their filters and payload schema, so a subscription can target a document or project instead of watching all activity. The server must persist the subscription and check that the connected user still has access during its lifetime. When ChatGPT subscribes, it supplies a callback URL and signing secret. The server validates the destination, then sends a signed, single‑use challenge before activating delivery. Matching updates are subsequently delivered as signed HTTPS webhooks. This is application work, not merely a switch in the ChatGPT interface: the source service must map its own changes to event names, store subscriptions, sign payloads and honor revocation. OpenAI's [example plugin image](https://cdn.openai.com/devhub/docs/plugins/mcp‑events/plugin‑tools‑and‑events.webp) shows discovered events alongside tools, but that example does not prove a particular third‑party plugin has implemented them.

Webhook receipt is not the same as finished automation

OpenAI says a `2xx` callback response acknowledges receipt; ChatGPT processes the event asynchronously. The [delivery guidance](https://developers.openai.com/plugins/build/mcp‑events) calls for one event per request, a body no larger than 256 KiB, bounded retries for transient failure and a stable event ID across attempts. Events can arrive out of order, so a plugin's write tools should be idempotent. A team that needs a once‑only downstream action should test duplicates and ordering rather than infer exactly‑once execution from a successful webhook response. The current ChatGPT integration supports webhooks and callback verification from a draft MCP Events design. The same guide explicitly excludes polling, streaming and the draft's `gap` and `terminated` control notifications. For an event type without replay, an interruption can lose events; a replayable type instead needs a cursor and history that the server actually retains. The MCP [Triggers and Events working group](https://modelcontextprotocol.io/community/working‑groups/triggers‑events) is still defining the broader standardized callback and ordering behavior. OpenAI's launched integration should not be mistaken for full support of every proposed protocol feature.

The useful launch test spans authorization, delivery and the action

A builder can start with one narrow event and filter, then confirm discovery, subscription, callback verification, a matching delivery and the resulting response in ChatGPT. OpenAI's [test checklist](https://developers.openai.com/plugins/build/mcp‑events) also calls out a nonmatching event, unsubscribe, restart and refresh, revoked access, bad signatures, duplicate deliveries and feedback loops when an action writes back to the source app. Event payloads that contain user‑written comments should be treated as data rather than instructions to the model. This is a feature of [ChatGPT](https://opentools.ai/tools/chatgpt) from [OpenAI](https://opentools.ai/organizations/openai). The strongest initial use is a specific, permissioned update whose arrival should prompt a user‑defined task. It is not a reason to assume every connected plugin can trigger work, that a webhook acknowledgment means the task succeeded, or that the draft specification's optional modes are already available in ChatGPT.

Share this article

PostShare

Related News