MCP Events in ChatGPT: How Event-Driven Agents Actually Work

Right now, most agents wake up for one of two reasons: a cron schedule or a human typing a message. On October 3, 2026, Nathan Baschez, who works on product design at Notion, posted that he had not seen near enough excitement about OpenAI's MCP Events documentation, adding: "Event-driven triggers are a huge deal." The documentation describes how an MCP server can push updates to ChatGPT, so an agent can act when something happens in your tools rather than when you remember to ask.

This guide walks through how the protocol works, what you need to build, the security traps in the docs, and where the pattern is useful. All protocol details come from OpenAI's developer documentation as of October 4, 2026; this is a documentation walkthrough, not a report from a production deployment.

TL;DR: MCP Events in one table

Why do events matter for agents?

An agent that only runs on a schedule wastes work when nothing changed and reacts late when something did. An agent that only runs when you message it depends on you to notice. Events change the trigger from time or human attention to the thing you actually care about.

OpenAI's two examples show the shape. A user asks ChatGPT to monitor a feedback channel and open draft pull requests with fixes and tests when a bug report arrives, backed by a message.created event filtered by channel. Or a user asks it to watch a document for review comments and implement requested edits, backed by comment.created filtered by document. Baschez listed similar ideas: @mention an agent in a comment on a document and have it reply, or triage notifications from chat, email and issue trackers and escalate only what is important.

He also pointed to a business angle: "subagent as a service" startups, where a main agent such as Codex or Claude calls a specialist that wraps proprietary data and process as a tool, and events let that specialist call back when its work completes.

How does MCP Events work, step by step?

1. Your server lists the events it supports. It advertises an events capability in its server/discover response.
2. The user tells ChatGPT what to monitor and how to respond. For example, "watch this document and implement review comments."
3. ChatGPT subscribes through your server, supplying a callback URL and a signing secret.
4. Your server sends matching events as signed webhooks to that URL.
5. ChatGPT receives the event in the subscribed chat and follows the user's instructions.

On the server side you implement three methods on the same authenticated endpoint as your tools.

Defining an event

Each event has a name, supported delivery modes, an inputSchema for subscription arguments, and a payloadSchema for the delivered data. The docs' example is a comment.created event with a required document_id filter and a payload containing the document ID, comment ID, text and URL. Use stable event names and specific descriptions, apply filters on your server before delivery, and return only events the connected account may discover.

Subscribing

When the user asks to monitor something, ChatGPT calls events/subscribe with the event name, arguments and delivery details.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "events/subscribe",
  "params": {
    "name": "comment.created",
    "arguments": { "document_id": "doc_123" },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/mcp-events/callback_123",
      "secret": "whsec_<base64-encoded-signing-key>"
    },
    "cursor": null
  }
}

Before accepting, check that the user is authorized for the requested event and arguments, validate the arguments against your schema, require a whsec_ secret whose base64 value decodes to 24 to 64 bytes, validate and verify the callback URL, and store the subscription with its owner, filters, URL, secret and expiration. Derive a deterministic subscription ID from the authenticated principal, callback URL, event name and arguments, and make creation idempotent, comparing arguments as canonical JSON so key order does not create duplicates. Return the ID and a refreshBefore expiration.

Verifying the callback

Before sending application data, send a signed verification request with a fresh, single-use challenge. ChatGPT echoes the challenge back in a 2xx response; you compare it in constant time before activating delivery. If verification fails, return JSON-RPC error -32015 (CallbackEndpointError) with a reason such as challenge_failed or timeout.

Sending and signing events

A delivery is a POST of one event object with a unique eventId, a name matching the subscription, an ISO 8601 timestamp, and a data object matching your payload schema. Sign it with Standard Webhooks and send the headers webhook-id (same as eventId), webhook-timestamp (Unix seconds), webhook-signature and X-MCP-Subscription-Id. The signature covers the exact body bytes, so serialize once and send those bytes. The docs' Node.js example uses the standardwebhooks library, a 10 second timeout, redirect: "error", and a 256 KiB size guard.

A 2xx response means receipt; ChatGPT processes asynchronously. Retry transient failures with exponential backoff and bounded attempts, keep the same event ID, generate a fresh signature each attempt, and do not retry 410 or 413. Events can arrive out of order, so make write tools idempotent.

What are the security traps?

The docs are practical about security, and the rules map directly to well-known attack classes.

• Server-side request forgery. Your server will POST to URLs supplied by clients. Require HTTPS, resolve and validate addresses at connection time, connect to the validated address while preserving the hostname for TLS, block private, local and other non-public ranges, and do not follow redirects. Apply the same checks to verification requests.
• Prompt injection through payloads. The docs say to treat comments and other user-authored text as data and not to add instructions telling the model how to behave inside the payload. A malicious comment is an instruction channel into an agent that acts automatically. Keep payloads small, send a summary and a read tool for large records, and rely on the user's instruction rather than the event text.
• Access revocation. Recheck the user's access during the subscription lifetime and stop delivery if it is revoked.
• Feedback loops. If the agent's action changes data in the source app and that emits another event, you can create a loop. The docs ask you to test for it explicitly.
• Secret rotation. When a refresh supplies a new signing secret, replace it, and during a short window sign with both old and new keys using Standard Webhooks' space-separated signatures.

An event-triggered agent also changes the risk profile of everything else you have connected. Tool poisoning and silent definition changes matter more when the agent acts without a human in the loop, which is why we cover them in MCP rug pulls, tool poisoning and scanners and in the broader MCP security guide. One reported case of a Dot emailing city officials without being asked, covered in the unapproved email post, is unconfirmed by OpenAI but illustrates why autonomous triggers need approval design.

What people are asking

Is this the same as the MCP working group's triggers and events work? It implements part of it. OpenAI says ChatGPT supports webhook delivery and callback verification from the draft MCP Events specification, and that polling, streaming and the draft's gap and terminated notifications are not supported. The MCP roadmap lists server-initiated events as a priority; see the new MCP roadmap.

Why does the spec need version 2026-07-28? That revision made the protocol request-and-response and serverless-friendly. Read the details in MCP 2026-07-28 explained. Event subscriptions are the stateful part you now store yourself, which is why persistent subscription storage is a hard requirement.

Did people already know? Replies to Baschez said excitement arrives about six months after the spec, and one person thought the spec was still a draft. Another quoted a call for MCP triggers so connected services can call cloud agents back. The pattern has been discussed for a while; the new part is a shipping consumer.

Can I host the server on ChatGPT itself? Possibly, for simple cases; see how to host an MCP server on ChatGPT Sites. Events need persistent storage and outbound HTTPS, which you should confirm for any hosting option.

Does this replace cron? No. Use cron for periodic digests and checks with no triggering event, and events for reactions. Many workflows want both.

A build checklist

1. Add the events capability to your discovery response and implement the three methods.
2. Define few, specific events with filters, and expose a read tool for full records.
3. Store subscriptions durably with owner, filters, URL, secret and expiry; survive restarts.
4. Verify callbacks with a single-use challenge and cache success for a bounded time.
5. Block private addresses, disable redirects, and cap payloads at 256 KiB.
6. Sign with Standard Webhooks, preserve event IDs across retries, and make write tools idempotent.
7. Test subscribe, refresh across a restart, revoked access, duplicate deliveries, invalid signatures, bursts, and feedback loops.
8. Scan and pin your own MCP server dependencies, as discussed in the security posts linked above.

If you are new to building servers, start with build your first MCP server, then add events.

Honest limitations

This guide summarizes OpenAI's documentation, not hands-on testing; we have not built an MCP Events server against ChatGPT for this post. The docs describe availability, so check your workspace controls before relying on it. Details may change as the draft specification evolves.

Related reading

• The new MCP roadmap for 2026
• MCP 2026-07-28: stateless core, Apps, Tasks and enterprise auth
• How to host an MCP server on ChatGPT Sites
• Max Stoiber on the OpenAI plugin platform and MCP
• MCP security guide 2026
• MCP rug pull, tool poisoning and scanners
• Top 10 open and closed source MCP servers
• What is MCP? The complete guide

Official: OpenAI MCP Events documentation · MCP triggers and events working group

Accurate as of October 4, 2026, based on OpenAI's developer documentation.