ChatGPT MCP Events: Trigger Tasks from Gmail, Slack, and GitHub

OpenAI is pushing ChatGPT from a "you ask, it answers" chat box toward an automation workbench that can be driven by external events. The new MCP Events feature lets developers turn actions in Gmail, Slack, and GitHub — a new email, a channel message, a code commit — directly into triggers for ChatGPT Work tasks. This means the starting point of a workflow is no longer opening a chat window, but the event itself.

What Problem Does MCP Events Actually Solve

Traditionally, connecting ChatGPT to business processes requires polling: periodically checking whether the inbox has new mail or the repository has a new PR, then deciding whether to invoke the model. Polling wastes resources and adds latency. MCP Events takes a different approach based on signed Webhook callbacks — when an event occurs, the external service actively pushes data to ChatGPT, and the platform handles signature verification and launching the preset task.

According to the official documentation, trigger sources include built-in connectors like Gmail, Slack, and GitHub, as well as events emitted by developers' own MCP servers. This "built-in + custom" combination puts the boundary of triggerable scenarios in developers' hands.

MCP (Model Context Protocol) is an open protocol standard proposed and open-sourced by Anthropic in late 2024 to unify how large language models connect to external tools and data sources — think of it as the "USB-C port for AI applications." Before MCP, connecting each external system (database, calendar, code repository) required writing separate adapter code with inconsistent interfaces; MCP defines standardized interfaces for tool invocation, resource reading, and prompt templates, allowing the same client to reuse any compliant server. A fairly complete ecosystem has formed around MCP, including official reference implementations and hundreds of community-provided open-source MCP servers covering search, file systems, cloud services, and more. OpenAI's addition of event push capability on top of the protocol means MCP has expanded from "passively responding to model calls" to "actively driving task initiation" — a substantial extension of the protocol's capability boundary.

Configuration Paths for Three Typical Trigger Scenarios

Gmail: Email as Task

Once Gmail is connected, you can set tasks to launch when an email arrives from a specific sender or containing specific keywords. Suitable scenarios include automatic classification of support tickets, automatic extraction of key points from contract emails, and automatic entry of sales leads into the CRM. The core of configuration is narrowing the trigger conditions to avoid triggering a task on every email and creating noise.

Slack: Channel Messages Driving Collaboration

Slack-side triggers are typically bound to specific channels or specific message patterns. For example, when a message in an alert format appears in the ops channel, ChatGPT can automatically summarize the context and generate handling recommendations. The key here is to clearly define the message format, otherwise the trigger conditions will be too broad.

GitHub: Code Events Triggering Review

GitHub events are well suited for hooking into nodes like PR creation, Issue opening, and comment mentions. A typical use is triggering a structured code review task when a new PR is created, passing the diff to the model to generate review comments. Compared to manual copy-paste, the event-driven approach ensures every commit is covered.

Custom MCP Server

For internal systems, developers can implement event push in their own MCP server and use signed Webhooks for authentication. The official implementation guidance is: the request body must be signed, and ChatGPT only launches the task after verification passes, preventing forged events from consuming quota.

What Does the 30 Triggers/Hour Limit Mean

The official documentation specifies a hard constraint: at most 30 task runs triggered per hour. This number is not large, and it determines that MCP Events is positioned not as a high-throughput batch processing pipeline, but as a low-frequency, high-value automation node.

High-frequency scenarios require aggregation design: for example, rather than triggering on every Slack message, merge messages over a period into a single summary task; or use pre-filtering to block most events before they trigger. Spending the 30-run quota on events that genuinely need model judgment is the core engineering decision when implementing this mechanism.

Security Design of Signed Webhooks

A common risk in event-driven architectures is forged requests. MCP Events requires signature verification of callbacks; developers need to compute a signature over the request body using a secret key on the server side and compare it with the signature in the request header. A few implementation points are worth noting: signature computation must be based on the raw request body rather than re-serialized content after parsing, otherwise byte-level differences will cause verification to fail; secrets should be injected via environment variables rather than hardcoded; and when verification fails, the request must be rejected outright — no fallback handling.

This design is consistent with mainstream Webhook practices, and it also shows that MCP Events targets teams with some engineering capability, not purely end users.

A Webhook is a "reverse notification" mechanism between services: instead of the caller repeatedly asking "is there new data?", the data source actively sends an HTTP POST to a pre-registered URL when an event occurs. Because that URL is usually open to the public internet, anyone could send forged requests to it, so mainstream services attach an HMAC signature computed from a shared secret and the request body in the request header — for example, GitHub uses the X-Hub-Signature-256 header with the HMAC-SHA256 algorithm. The receiver recomputes with the same secret and compares, confirming the request genuinely came from a trusted source and the content was not tampered with. HMAC is a hash-based message authentication code whose security depends on keeping the key secret rather than the algorithm secret. In practice, replay attack prevention is also needed; common approaches include validating request timestamps with a tolerance window, or including a one-time nonce in the signed content.

Implementation Recommendations

Start with a clearly defined single scenario, such as new PR review or ticket email classification, get signature verification and task templates working, then gradually expand trigger sources. At the same time, set up monitoring for the 30 runs/hour quota to prevent an anomalous event source from exhausting it and blocking critical tasks. The value of MCP Events is not in replacing workflow engines, but in embedding the model's judgment capability into existing business event flows.

One-line Summary

ChatGPT adds MCP Events, replacing polling with event triggers, limited to 30 per hour.

Paragraph Summary

OpenAI has launched MCP Events for ChatGPT Work, allowing built-in connectors like Gmail, Slack, and GitHub, as well as developers' own MCP servers, to actively push and trigger preset tasks via signed Webhooks when events such as new emails, channel messages, or code commits occur — replacing the traditional scheduled polling model. The article outlines configuration paths for four trigger sources and emphasizes narrowing trigger conditions to avoid noise. The platform imposes a hard limit of 30 task runs per hour, indicating its positioning as a low-frequency, high-value automation node rather than a high-throughput pipeline; in practice, high-frequency events need aggregation and pre-filtering. On security, signatures must be computed over the raw request body, secrets injected via environment variables, and failed verification rejected outright. The author recommends starting with a single scenario, getting signature verification and task templates working, and setting up quota monitoring.