Wakeshift vs Hookdeck, MCP Events toolkits and built-in wakes

Four ways to tell an agent that something it's waiting on has happened. They solve different problems, and for some cases Wakeshift isn't the right one.

The short answer

Wakeshift is the right choice when you run an MCP server whose jobs finish later, and your users' agents are Claude Code, Codex, Cursor, Copilot CLI and others. One emit wakes the conversation that asked, in whichever agent it is.

Something else may fit better when:

Side by side

Wakeshift Hookdeck's MCP Events bridge MCP Events toolkits Each agent's built-in wakes
What it is A service and SDK for MCP servers: your events wake your users' agents An open-source MCP server that turns third-party webhooks into MCP Events, with a Claude Code plugin Server-side libraries for the MCP Events draft (Upstash, Vercel's mcp-handler, Alpic's Skybridge, Hookdeck Outpost) Features inside each agent: MCP tasks, Channels, codex queue, Cursor and Copilot automations
Who it's for MCP builders Developers wiring webhooks into their own agent MCP builders Each agent's own users
Agents it reaches Every client in the next two columns, plus the conversations users already have open in Claude Code, Codex, Cursor, Copilot CLI, opencode, Antigravity CLI, Claude Cowork, OpenClaw, Hermes Agent and more The clients that subscribe to MCP Events, plus Claude Code through its plugin Clients that subscribe: ChatGPT's Work chats and dots, OpenClaw, Hermes Agent, Mastra, TanStack AI, the Vercel AI SDK Only that agent
What wakes The conversation that subscribed, while it's idle. In a ChatGPT Work chat, a new run starts in the chat A new run in the clients that subscribe; in Claude Code, a running session between prompts A new run, or your own code, in each client (Mastra's signal provider adds it to the subscribing thread) Varies: an idle Claude Code terminal session (MCP tasks), a new cloud session (automations), or a message as if the user typed it (codex queue)
Events from Your own code (emit), or any webhook through a publish URL Third-party webhooks Your own code GitHub, Slack, schedules, and each agent's own triggers
Consent Adding your app is the consent; any install runs only if the user agrees; consents and revocations kept in an audit log Each client's own Each client's own Each agent's own
Standard Serves MCP Events (SEP-3415) to clients that subscribe, and its own adapters to agents that don't MCP Events MCP Events Mostly each agent's own; Claude Code's MCP tasks follow the MCP Tasks extension
Price Free up to 50,000 deliveries a month; Starter $29; Custom Free (MIT); runs on a Hookdeck account, free tier or paid Free (Vercel bills the receiving side at $0.95 per 1,000 deliveries on Pro) Included in each agent's plans (some only on paid ones)
Open source The SDKs, connector and plugins (Apache 2.0); the service isn't Yes (MIT) Yes, mostly Codex's CLI, with codex queue, is (Apache 2.0); the rest aren't

Hookdeck's MCP Events bridge

What it does well. Hookdeck's bridge (launch post) turns webhooks from GitHub, Resend, Stripe, Slack and any signing sender into MCP Events, on Hookdeck's mature event gateway, with retries, deduplication, replay and observability. It's MIT-licensed and free, and Hookdeck verifies signatures for many more webhook senders than Wakeshift's publish URLs, which can require Standard Webhooks signatures (Svix, OpenAI, Clerk and others). For a developer who wants third-party webhooks in their own agent, it's a strong choice.

Where it stops. Beyond the clients that subscribe to MCP Events, it reaches one coding agent: Claude Code, through a plugin. It doesn't wake Codex, Cursor, Copilot CLI, opencode or Antigravity CLI, and it has no per-user consent or sessions for an MCP builder's users: each bridge has one owner (mcp-events-bridge). Hookdeck says it's building subscriptions into Event Gateway, so clients can subscribe without running a bridge.

How Wakeshift relates. Different buyer, mostly. Hookdeck brings other companies' webhooks to one developer's agent. Wakeshift lets an MCP builder's own events reach every one of its users' agents, under consent each user gives once.

MCP Events toolkits

Free toolkits implement the server side of MCP Events (SEP-3415), the protocol's draft standard for events. If your users are only in ChatGPT's Work chats or dots, a toolkit and a few handlers are enough (OpenAI's MCP Events guide). They reach only the clients that subscribe, which start a new run for each event; the main local coding agents don't subscribe, and some toolkits leave the subscription store and delivery to your code. Wakeshift serves the same standard and wakes the coding agents too, from the same emit: hosted MCP Events has the detail.

Each agent's built-in wakes

What they do well. They're built in and come with the agent's plans, and inside one agent they're often the best answer:

Where they stop. Each wakes only its own agent. None takes events from another company's MCP server into whichever agent the user runs. Some deliver in ways an MCP builder can't use: codex queue delivers as if the user typed it, and Channels blocks third-party plugins outside the allowlist (claude-code#82571).

How Wakeshift relates. Wakeshift uses each agent's own mechanisms where they fit, such as Claude Code's MCP tasks for its wait tool, and adds the agents each built-in wake doesn't cover. It never delivers as the user.

Webhook and workflow platforms

Svix, Composio, Inngest and Trigger.dev often come up as ways to handle events. They're complements, not alternatives: each gets an event to your code, and none wakes an agent by itself.

What Wakeshift doesn't do

Next