ChatGPT MCP Events: Build Your First Event-Triggered Plugin Automation, Step by Step

With MCP Events, ChatGPT subscribes to updates from your MCP server, and users choose what to monitor and what ChatGPT should do when an update arrives. If your team already runs an MCP server or a SaaS API, you may find that a connector can now start an automation on its own instead of waiting for a prompt.

We'll go through the build in the order you will write the code. We call it the Advertise-Subscribe-Verify-Deliver (ASVD) loop: advertise the events you emit, make subscriptions idempotent, verify every callback before it goes live, then deliver signed events with retries that know when to stop. We'll also flag where the specification is still a draft, because some of those unsettled details end up in your code.

What MCP Events Are and What ChatGPT Actually Supports

OpenAI's developer documentation keeps the description short: ChatGPT subscribes to updates from your MCP server, such as new messages, content updates or status changes, and the user decides what happens next. The draft design sketch aims higher. It wants an MCP client to subscribe to events in an upstream system, such as a Slack message, a GitHub push or a PagerDuty incident, so the agent can react without the user being present.

The design fact that matters most is what ChatGPT leaves out. ChatGPT supports webhook delivery and callback verification from the draft MCP Events specification. Polling, streaming, and the draft's gap and terminated control notifications are not supported by this integration.

Svix, a webhook infrastructure company, calls ChatGPT the first major client to support MCP Events. It also notes that your server delivers events to ChatGPT as Standard Webhooks. A third-party build guide on DEV Community says ChatGPT support began at OpenAI DevDay on September 29, 2026, at protocol version 2026-07-28. Confirm both in OpenAI's own documentation before you hard-code anything around them.

So build for webhooks and nothing else. Polling and push-stream code paths would need upkeep for as long as they exist, and they do nothing for this integration.

Before You Build: SDK Reality and Spec Status

After DevDay, a developer on the OpenAI Developer Community reported that the official Python SDK (mcp 2.2.0) did not yet support MCP Events, and that the TypeScript SDK did not either. That may have changed, so read the current release notes. We would still budget time for some hand-written plumbing.

Go is in better shape. An open Go SDK issue notes that its custom method support already lets you implement events/list, events/subscribe and events/unsubscribe. What's missing is a way to advertise the top-level events capability.

The spec itself is still moving. The working group charter says that clients currently learn about server-side updates by polling or holding an SSE connection open, and that the group plans to specify a standardized callback mechanism so servers can push notifications instead. On 2026-10-16 the group was renamed the Tasks and Events WG, and it took over the Tasks scope from the Agents WG. Expect more revisions.

Our advice is to write thin custom handlers now and keep them walled off. Give the JSON-RPC method handlers their own module, and do the same for subscription storage and for signing and delivery. When SDK support lands, you swap out the protocol glue and your business logic stays put.

ASVD Step 1 (Advertise): Declare the Capability and Define events/list

Declare the events capability

Your server has to advertise the top-level events capability during initialization. We suggest treating this declaration as a launch blocker rather than a detail to fill in later. In the Go SDK this is exactly the gap the open issue describes, so check where it stands before you pick a workaround.

Design each event type for two readers

We suggest designing each entry in events/list around these parts:

• A clear name that stays stable over time.
• A description that works for the user and the model alike. The user reads it while picking what to monitor; the model reads it while deciding what to do.
• An inputSchema defining the filters a subscriber can set.
• A payloadSchema describing exactly what you will send.

The example below is illustrative. Check the exact field names against OpenAI's documentation before copying it.

{
  "name": "ticket.status_changed",
  "description": "A support ticket in a project you can access changed status.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project_id": { "type": "string" },
      "status": { "type": "string", "enum": ["open", "pending", "closed"] }
    },
    "required": ["project_id"]
  },
  "payloadSchema": {
    "type": "object",
    "properties": {
      "ticket_id": { "type": "string" },
      "new_status": { "type": "string" },
      "summary": { "type": "string" }
    }
  }
}

Keep filters narrow and meaningful to the user. A project or a ticket status works well, so people get the events they asked for and little else. Treat the payloadSchema as a public contract: version it, don't break it, and keep payloads lean.

Scope events to the authenticated user

The draft states that authorization uses the same MCP principal as your tools. In practice, list only the event types the authenticated user is allowed to see, and accept only filters that point at resources that user can reach.

ASVD Step 2 (Subscribe): Idempotent events/subscribe and events/unsubscribe

Clients retry. Networks lose responses. If a repeated subscribe request creates a second subscription, every event goes out twice and someone's automation fires twice. Design both methods so that calling them again changes nothing.

Subscribe

Store each subscription with its event type, normalized filters, callback URL, signing secret and owner. Build a deterministic key from the owner, event type, normalized filters and callback URL. When an authorized user repeats the request, they get the existing subscription back.

authorize(owner_id, event_name, filters)   // always first, even on repeats
key = hash(owner_id, event_name, canonical_json(filters), callback_url)
if store.exists(key): return store.get(key)
verify_callback(callback_url)              // ASVD Step 3
sub = store.create(key, secret=new_secret(), status="active")
return sub

Authorization runs before the existence check on purpose. Swap them, and a user whose access was revoked could resend an old subscribe call and quietly get the subscription back.

Unsubscribe

Unsubscribe should be safe to call twice. If the subscription is already gone, return success, not an error. The caller wanted it removed, and it has been.

Persistence and authorization

Keep subscriptions in durable storage. An in-memory map loses everything on the next deploy, and deliveries stop without any visible error. Check authorization at subscribe time and again at delivery time, since access can be revoked in between.

You also need a cleanup path. OpenAI's docs say not to retry a delivery that returns 410. Our reading is that the receiver no longer wants the subscription, so mark it retired rather than letting it fail on every future event.

ASVD Step 3 (Verify): Confirm the Callback With the Signed Challenge

Before any subscription goes active, send a signed verification challenge to the callback URL and confirm the expected response. That way your server never pushes events to an endpoint that hasn't proved it is the intended receiver.

If verification fails, OpenAI's docs say to return JSON-RPC error -32015 (CallbackEndpointError) with a categorized data.reason, such as challenge_failed or timeout.

Watch for drift here. The current draft sketch says its earlier revisions used -32011 to -32015, a sub-range the specification never assigns, and that implementations of those revisions need to renumber. Put simply, the code in OpenAI's docs comes from an older sketch revision. Follow OpenAI's documentation for now, because ChatGPT is the client you are building for, and define the code once as a named constant so a future change is a one-line edit.

Give the challenge request a bounded timeout and log the reason category on every failure. When a user tells you their automation never started, that log line is the first place to look. If you already instrument agent runs, our OpenTelemetry GenAI tracing playbook is a natural home for verification and delivery telemetry.

ASVD Step 4 (Deliver): Sign and Send Events as Standard Webhooks

Deliveries follow the Standard Webhooks specification. According to Svix, X-MCP-Subscription-Id is the only MCP-specific header, and it tells the receiver which subscription, and therefore which secret, to verify the signature with.

Size and shape

OpenAI's docs say to send one event per request, with a complete request body no larger than 256 KiB (262,144 bytes). ChatGPT can group separately delivered events into one task run, based on the task's batching settings. Don't treat 256 KiB as a target. Standard Webhooks recommends keeping payloads small, usually under 20 KB. Send identifiers and a short summary, and let ChatGPT call your tools when it needs the full record.

Retries and stop conditions

OpenAI's docs say to retry transient failures with exponential backoff and bounded attempts, preserving the event ID and generating a fresh signing timestamp and signature for each attempt. Keeping the same event ID gives the receiver something to deduplicate on, and the fresh timestamp and signature keep the request from being rejected as stale.

OpenAI's docs also say not to retry deliveries that return 410 or 413. When a delivery is refused this way, we suggest reviewing your subscription state and payload design rather than sending the request again.

Standard Webhooks recommends a request timeout of 15 to 30 seconds. Pick your number on purpose instead of inheriting whatever your HTTP library ships with.

Use an official library

Sign with an official Standard Webhooks library, such as the Standard Webhooks JavaScript library or the official one for your stack, instead of writing your own HMAC code. A library built against the specification is the safer way to produce signatures that receivers can verify.

Test Before You Ship: A Pre-Release ASVD Checklist

Run through this list in staging, connected to a real ChatGPT subscription, before you release. Each item exercises one stage of the loop.

Retries keep the event ID, refresh the signature, and stop on 410 and 413.

• [ ] Advertise, filters: Events outside a subscription's filters never get delivered. Test with events that match some filters but not all.
• [ ] Subscribe, duplicates: Repeating a subscribe call returns the existing subscription and creates nothing new.
• [ ] Subscribe, unsubscribe: After unsubscribing, nothing else goes out, including retries already queued. A second unsubscribe call returns success.
• [ ] Subscribe, restarts: After a restart and a redeploy, subscriptions and secrets persist and deliveries resume.
• [ ] Subscribe, authorization: Revoke a user's access to a filtered resource. Deliveries for it stop, and a repeated subscribe call is refused.
• [ ] Verify, callback challenge: Run one passing challenge and one failing one. The failure returns the documented error code with a data.reason.
• [ ] Deliver, replayed events: Replay the same event ID and write down what ChatGPT does with it. Don't assume deduplication you haven't observed.
• [ ] Deliver, size limits: Payloads just under and just over 256 KiB are each handled the way you intended.

Common Mistakes When Building MCP Events Servers

• Building modes nobody calls. Polling, streaming, and gap or terminated notifications aren't part of ChatGPT's integration. Heartbeats belong in the same bucket. The draft says a server should send a heartbeat at least every 30 seconds, but that applies to push-mode streaming, which ChatGPT does not support.
• Getting retries backwards. A new event ID on each retry takes away the receiver's deduplication key. Reusing the old timestamp and signature invites a rejection for staleness.
• Retrying dead ends. OpenAI's docs say not to retry deliveries that return 410 or 413. The same body will bounce again.
• Shipping whole records. Full documents push payloads toward 256 KiB when Standard Webhooks suggests staying under 20 KB.
• Holding subscriptions in memory. They disappear on restart, and nothing warns you.
• Trusting payload text. When an event carries user-generated text, a customer message for example, that text can contain instructions aimed at the model. Treat payloads as untrusted input, the same way you treat tool results, and strip or clearly delimit that text.

Caveats: Spec Drift and Operational Limits

The spec is a draft. OpenAI's error code and the current sketch's renumbering already disagree, and the working group is still adjusting its scope. Build against OpenAI's documentation and re-read it on a regular schedule.

Your custom code is temporary. SDK support is uneven. Plan to replace the handlers once official support ships.

Unattended automation needs guardrails. Before an event-triggered task touches production systems, decide which actions it may take without a person signing off. Add audit logs and rate limits, and give each subscription its own kill switch. For more on narrowing what a triggered task can reach, see our note on how to contain a compromised agent's reach. If triggered work grows into multi-step jobs, our durable AI agents runtime selection checklist can help you decide where that state should live.

Confirm secondhand details. The launch date and protocol version mentioned above come partly from third-party guides. Check them against OpenAI's documentation.