Most AI agents today just sit there waiting for you to ask them something. Since DevDay on September 29, a plugin in ChatGPT can ring their doorbell on its own when something happens in a connected app.
This week a viral post went around X and LinkedIn claiming almost nobody had noticed. It gets the main point right: an agent no longer has to keep asking whether there's anything new, it can just subscribe. And you can build something with it today.
What OpenAI announced at DevDay
According to InfoQ, OpenAI announced support for the proposed MCP Events specification. A plugin, meaning an MCP server, can now start an automation the moment something happens in a connected app.
OpenAI didn't invent the proposal, though. It's written by a working group around the MCP protocol, and OpenAI has now wired it into ChatGPT.
The example OpenAI showed: ChatGPT watches a project board. When a task appears, it reads the linked documents and drafts a plan. You don't have to be at your computer in the meantime.
According to WorkOS, which took the ChatGPT implementation apart in detail, automations via MCP Events are available on all ChatGPT plans.
From pull to push: the agent gets a doorbell
Until now, an agent worked like someone who keeps walking to the mailbox to check for post. It's usually empty, and when something does arrive, they only find out on the next round. That's polling: asking over and over whether anything has changed.
MCP Events give the agent a doorbell. It doesn't check anything. When something happens, the server rings and the agent gets to work.
In practice, that means less supporting infrastructure. Today, if you want AI to react to a new ticket or email, you build a cron job that asks every few minutes, or a Zapier scenario that catches the event and forwards it. It works, but every one of those middlemen is something you have to monitor and pay for.
With events built into MCP, one piece is enough: the server that gives the agent its tools also tells it that something happened.
What you can build with it
Every scenario has the same shape: when X happens, the agent does Y. What matters is who runs the MCP server.
On your own server, it works today and you don't have to wait for anyone. Take an online shop (the names are just illustrative):
- The
order.complaint_createdevent fires when a customer files a complaint. - The payload carries only the minimum:
orderIdand a short complaint text. - Using the same server's tools, the agent looks up the order, checks whether the item is under warranty, and writes you a suggested resolution plus a reply to the customer in the chat.
You can build a broken-build alert from your own CI, a low-stock warning, or an incident summary from internal monitoring the same way.
The scenarios from the viral post, where GitHub announces every PR, Linear every new ticket, and Superhuman every email, don't work yet. Those tools first have to implement events in their MCP servers, and that hasn't happened.
How it works under the hood
The server first announces the events capability. With the events/list method, it returns a catalog of events to the client. Each one has a name, a description, an inputSchema (subscription parameters), and a payloadSchema (the shape of the data that will arrive).
The proposal defines three delivery modes:
- poll: the client asks via
events/polland sends a cursor so it knows where it left off, - push:
events/streamholds an open connection over SSE (Server-Sent Events, a one-way stream of messages from the server), - webhook: the client registers its own callback URL via
events/subscribe, and the server POSTs to it when something happens. It unsubscribes viaevents/unsubscribe.
The webhook doesn't belong to the server: the agent supplies the URL, the server just calls it. According to WorkOS, ChatGPT only supports webhooks, not poll or push.
A subscription looks roughly like this (simplified, based on the draft):
{
"method": "events/subscribe",
"params": {
"name": "ticket.created",
"arguments": { "project": "web" },
"delivery": { "url": "https://agent.example.com/mcp/events" },
"ttlMs": 3600000
}
}
name and arguments define what you want to subscribe to, delivery.url where it should go. ttlMs is the proposed lifetime of the subscription, one hour here. The spec also allows ttlMs: null, a subscription that never expires. That's risky, and I explain why in What to watch out for. The server replies with a refreshBefore time, and the client must renew the subscription before it expires:
{
"result": {
"refreshBefore": "2026-10-04T21:00:00Z"
}
}
A delivered event then (again simplified) carries an eventId, which lets the client spot duplicates, and the data itself:
{
"eventId": "evt_01",
"name": "ticket.created",
"payload": { "title": "New task on the board" }
}
Every request is signed according to Standard Webhooks (HMAC-SHA256 with a whsec_… secret). The callback URL has to be verified first: before activation, the server sends a signed challenge to the URL and the client has to confirm the address is its own. The URL must be https only, with no redirects, and the server has to protect itself against SSRF (being abused to call internal addresses).
The spec also has a terminated control message, which the server uses to tell the client a subscription has ended, for example after permissions were revoked. ChatGPT doesn't support it, so it only finds out about the cancellation when it fails to renew the subscription.
A community developer showed on October 2, 2026 that this isn't just paper. The developer connected a server to ChatGPT, had it reload the tools, and the event the server offers showed up on the plugin page. When told to “watch this company”, ChatGPT created the subscription on its own and verified the callback. After a test event, it posted in the chat within a few seconds, without anyone asking.
Who is behind MCP Events
MCP Events is a proposed extension of the open MCP protocol. It's written by the MCP Triggers & Events Working Group, founded in March 2026 and led by Peter Alexander from Anthropic and Clare Liguori from AWS. The design sketch dates from February 19, 2026, was revised in September, and lives in full in a public repository in docs/design-sketch-proposal.md.
This is where the viral post is right. Less vendor lock-in is a win. Among the big clients, we only know of support in ChatGPT so far, but because it's an open standard, once other clients support it, the same server will wake them too.
Other proposals show more people are moving in this direction. SEP-2495 is about letting a server directly start a new LLM turn. And the Hermes agent repository from Nous Research has an issue asking to use MCP Events as a wake-up source instead of polling.
What to watch out for
- It's a draft. The official SDKs don't support events yet: neither the Python SDK
mcp2.2.0 nor the TypeScript SDK. The specification may still change. - A subscription is a credential. WorkOS points out that a subscription is created under the user's token, but delivery continues after the token expires. The spec requires a permission check at subscribe time, only recommends re-checking later, and doesn't set an interval. So when an employee leaves and the company revokes their access to the app, the server can keep sending company data, like contract changes or new tickets, to their ChatGPT. They see it in the chat and run automations on it until the TTL ends or the next renewal fails.
- So use short TTLs, never subscriptions without expiry (
ttlMs: null), and re-check permissions continuously; WorkOS suggests every 15 minutes, for example. - The payload is untrusted input. The same defenses against prompt injection (instructions smuggled into data) apply as for tool results.
- Expect repeats. Make writes idempotent, filter duplicates by
eventId, and send only the minimum data in the payload. Check permissions at the moment the agent actually acts.
How to get started
Start with one event, not a whole catalog. Pick the thing you keep refreshing a page for today and turn it into an event.
- Read the design in the working group's repository.
- Add
events/listand a webhook subscription viaevents/subscribeto your MCP server. - In Python, you can start from the community package
mcp-webhook-events, which the author used for the ChatGPT test. It's an extension on top of the official SDK: it adds the missingevents/*methods viaadd_request_handler. - Watch out for two gotchas from that test. The transport requires an
Mcp-Methodheader that has to match the method in the request body, otherwise you get error -32020. And you have to inject theeventscapability via middleware, because the SDK drops unknown capability keys during serialization. - Connect the server to ChatGPT, have it reload the tools, and write “watch X for me”.
Give the subscription a short TTL. Today ChatGPT will catch that event, and because it's an open standard, tomorrow maybe your own agent will too.
