Timeline

MCP Events: who writes the first prompt now?

MCP Events lets a server wake your AI agent when something happens. Here’s what shipped and why it changes security.

Marcel Marais

Updated 6 min read

Every agent starts the same way. A human types something, a cron job fires or that mess of webhooks you built to keep track of external tools delivers something.

MCP Events changes that. It's a draft extension to the Model Context Protocol (SEP-3415) that lets a server tell your agent something happened, like a Slack message, a failed deploy or a comment on a doc, so the agent can act without anyone prompting it.

It's easy to file this under "webhooks for MCP". I think it's a bigger shift than that. For the first time, the first message in an agent run can come from someone other than the user (& effortlessly for the dev building the agent).

How it works

Until now MCP has been pull-based. The client calls tools, reads resources and maybe polls a long-running task. If something changed on the server, you found out next time you asked. In my opinion this totally breaks the experience.

Something happens upstream, the MCP server pushes an event, and the agent wakes up. Timeline's events are imagined; it doesn't send any today.

The Events draft comes from the Triggers & Events Working Group (Clare Liguori at AWS and Peter Alexander at Anthropic). It adds:

  • events/list: the server advertises event types, each with an inputSchema for subscription arguments (repo, label, channel) and a payloadSchema
  • three delivery modes, none of them mandatory:
    • events/poll for plain request/response
    • events/stream, a long-lived push stream (SSE over HTTP, notifications over stdio)
    • events/subscribe for webhooks, signed per Standard Webhooks with a client-supplied whsec_ secret
  • opaque cursors so a client can resume after a disconnect, with truncated: true when events were skipped
  • subscription TTLs that the client has to keep refreshing

It's pretty well thought through. The webhook section of the design sketch covers SSRF (it checks the resolved IP at delivery time and doesn't follow redirects), endpoint verification before the first delivery, and secret rotation (someone has clearly been burned by webhooks before).

What actually shipped

OpenAI announced ChatGPT support at DevDay on 29 September. The Vercel AI SDK added experimental support on 15 October, and Cloudflare's API MCP server now emits Workers issues as events. The reaction on X has been mostly excitement, eg. agents hiring other agents.

But look at which mode everyone picked:

  • ChatGPT supports webhooks only. No poll, no stream, and none of the gap or terminated notifications.
  • Vercel supports webhooks only.
  • Claude Code, Cursor and VS Code support nothing yet.
  • The official Python and TypeScript SDKs have no events/* either, so everyone is bolting it on.

That makes sense. Hosted clients have a public HTTPS endpoint, and webhooks are the mode that fits them. Push via events/stream is the mode built for local agents, the ones on your laptop with no public URL, and nobody big ships it. The agents that would gain most from being woken up are the ones that can't be reached.

The real change is security

With pull, the user's prompt always came first. Whatever untrusted text the agent read (an email, an issue, a web page), it read it because someone asked it to, and that someone was usually watching.

With Events, the stranger's text comes first. A GitHub comment or an inbound email wakes the agent, lands in context, and the agent has tools and nobody looking over its shoulder. That's the lethal trifecta (private data + untrusted input + a way to act) with the human taken out of the loop.

The spec's guidance is to treat payloads like tool results and keep them minimal. That's correct, but it feels thin for a run that no human started.

If I were wiring this up today:

  • Send thin events: an ID and a type, then let the agent fetch the details through a normal, permissioned tool call.
  • Use the inputSchema filters so the agent wakes for one repo and one label, not "all activity".
  • An event can start a draft. Sending, merging or paying still needs a human.

Cool use cases I thought of

I build Timeline, a location history app for iPhone with an MCP server for agents. Today it's all pull: an agent calls get_current_location or search_visits when you ask it something.

Now imagine it emits visit.started and visit.ended, with a saved place as the subscription argument. That's when it gets kinda magic:

  • You walk into the supermarket and your phone buzzes with the three things you said you'd run out of, pulled from a chat two days ago.
  • You land in Lisbon. By the time you're at baggage claim, the agent has found the metro line to your hotel and when the next train leaves.
  • You're still at the office at 19:40 and the dinner booking is at 20:00 across town. The agent works out you won't make it and drafts the "running 15 min late" message for you.
  • You pull up at your parents' place, and before you're through the door you get the stuff you meant to bring up (the passport form, the broken laptop).
  • Ten days without a gym visit is its own event, place.not_visited, and it's way more useful than a streak counter.
  • A trip ends, and the agent writes a little travel journal from every place you stopped, in order, with the coffee places you'll forget otherwise.

And outside location:

  • CI goes red at 2am. By breakfast there's a draft PR with a bisected fix and a test that reproduces it.
  • A customer's payment fails, and a follow-up in your voice is sitting in drafts.
  • Someone leaves "can you tighten this?" on your doc, and the suggested edits are there before you've opened it.

Every one of these ends in a draft or a nudge, not an action. That's the point of the rule above. The agent does the boring 90%, you tap send.

Where this leaves us

I'm quite bullish. Agents that only wake on a cron job or a chat message are underpowered, and a standard way for servers to push is overdue. The working group's design is careful, and the August roadmap put server-initiated events in its top priority area.

But right now we have one major host, one delivery mode, no SDK support and a spec that's still moving. I'd still build event servers now. Just keep the events thin and assume nobody is watching when they land.

Questions

What is MCP Events?

A draft extension to the Model Context Protocol, proposed in SEP-3415, that lets an MCP server notify a client when something happens upstream. Clients can poll, hold a push stream open, or register a signed webhook.

Does Claude support MCP Events?

Not yet. As of October 2026, Claude Code, Cursor and VS Code don't support it. ChatGPT supports the webhook mode in Work chats.

Is MCP Events part of the MCP spec?

Not yet. SEP-3415 is an open pull request, and the error codes and some details are still provisional.

Sources

Checked on 18 October 2026.