OpenAI announced support for proposed MCP Events on September 29, 2026, allowing plugins to trigger work when a connected application changes. This is a move from scheduled checking toward event-triggered tasks, with specific integration requirements and a protocol still under development.
Product support does not finalize a protocol
The ChatGPT integration guide describes subscriptions, outbound HTTPS callbacks, and callback verification against a draft specification. It lists supported Work and Dots surfaces and identifies unsupported delivery modes and control notifications.
The MCP working-group charter separately defines goals for subscription lifecycle, delivery semantics, and ordering. A working implementation in one product is useful evidence of adoption; it is not evidence that every MCP client supports the same contract.
An event is a trigger, not permission for every action
A new task on a project board can legitimately trigger a draft plan. It should not automatically authorize access to every linked resource or permit the agent to send a commitment to a customer. Keep the user’s instruction, application permissions, and action-review policy attached to the triggered workflow.
When an event links to external content, treat that content as evidence rather than instructions. Test a malicious description, an inaccessible document, and a deleted resource. The correct result may be a visible blocker instead of an improvised plan.
Delivery behavior is part of correctness
Webhook consumers must account for duplicate delivery, retries, and work arriving out of order. Use a stable event identity and an explicit record of whether a consequential action has already happened. Retrying a failed read is different from retrying a customer message or payment.
Define what happens when a subscription expires or the destination is unavailable. A monitoring workflow should surface a loss of coverage so a user does not assume it remains active. Keep event retention and logs proportionate to their operational purpose, and avoid recording private payloads unnecessarily.
Begin with a reviewable event response
A low-risk pilot can generate a draft summary from a newly created issue. Verify the triggering event, source links, permission checks, and completion record. Then test a replay and a stale event before granting write access to the downstream system.
The opportunity is less idle polling and faster response to meaningful changes. The reliable implementation is the one that can explain what triggered the work, why the action was allowed, and how a repeated event avoids creating duplicate consequences.