In response to a post discussing the power of MCP Events, a [reply](https://x.com/ow/status/2106447707242209791) wished Resend supported MCP Events, so their agent could have its own inbox and wake up when they emailed it. This got us thinking... what if Event Gateway provided MCP Events for providers who have yet to add support yet? Afterall, Resend sends an [`email.received` webhook](https://resend.com/docs/webhooks/emails/received) when a message arrives at an inbound address. GitHub and Stripe send webhooks too, as do most services an agent might want to hear from. So we created the [MCP Events bridge](https://github.com/hookdeck/mcp-events-bridge) to turn those webhooks into MCP events. It's an open-source (MIT) MCP server built on [Hookdeck Event Gateway](/event-gateway). In the video, an email reaches ChatGPT, a new GitHub issue reaches an agent built with the Vercel AI SDK, and a comment wakes Claude Code. Video: [Turn any webhook into an MCP event with the MCP Events bridge](https://youtu.be/TmjbnuxesPQ) > We're building the same capability into Hookdeck Event Gateway. The bridge works today, and we're releasing it now to learn from how you use it. [Tell us what you need](#tell-us-what-you-need). What the MCP Events bridge does: * **Turns webhooks into MCP events.** Resend inbound email and GitHub are built in, and `setup` registers their webhooks for you. Stripe, Slack and many more services work through Event Gateway's source types, and your own services through signed or authenticated webhooks. * **Verifies every webhook.** Event Gateway checks each webhook's signature or credentials before it becomes an event. * **Lets subscribers choose what wakes them,** with filters such as an email's sender, or a GitHub repository and action. * **Delivers to ChatGPT and other MCP Events clients by webhook.** Event Gateway signs each delivery with the subscriber's secret, drops duplicates and retries failures. * **Wakes Claude Code through a plugin,** including while Claude is idle between prompts. * **Offers poll tools for other MCP clients,** and callback URLs from the Hookdeck CLI for agents on your laptop. * **Replays missed events from a cursor,** read back from Event Gateway's history. * **Keeps no database.** Each subscription is an Event Gateway connection, so deliveries continue while the bridge restarts. * **Sets up with a coding agent,** through the bridge's Agent Skill. ## How a webhook becomes an MCP event MCP Events has three delivery modes. In webhook mode, the MCP server POSTs each event to a callback URL the client gives it when it subscribes. In poll mode, the client calls `events/poll`. Push mode streams events over `events/stream`. The bridge supports webhook and poll, and this is how a webhook delivery works: 1. The service sends its usual webhook to the Event Gateway [source](/docs/sources) URL that the bridge's `setup` command created. 2. Event Gateway [checks the service's signature](/docs/authentication#http-and-webhook-signature-verification) and keeps the [request](/docs/requests). A request that fails verification goes no further. 3. Event Gateway turns the webhook into an MCP event with a [transformation](/docs/transformations) that the bridge sets up. Events are named `{source}.{event}`, such as `resend.email.received` or `github.workflow_run`, where `source` is the source's ID in your config and `event` is the service's own name for the event. Each one includes an ID, a timestamp and the webhook's data, which is a summary for Resend and GitHub, and the JSON body, or the fields you choose, for other sources. 4. Event Gateway delivers the event to each subscriber whose [filters](/docs/filters) it matches, through one [connection](/docs/connections) per subscription. It [signs every attempt](/docs/destinations#add-destination-authentication) with the secret the subscriber gave when it subscribed, [drops repeats](/docs/deduplication) and [retries](/docs/retries) on failure. **Diagram:** Services that send webhooks reach Hookdeck Event Gateway, which turns each one into an MCP event and delivers it to the subscribed agent. The MCP Events bridge sets up each subscription in Event Gateway. 1. Few MCP servers offer events yet, but many services already send webhooks. 2. The MCP Events bridge: an open-source MCP server, built on Hookdeck Event Gateway. 3. Event Gateway turns the webhook into an MCP event and delivers it, with retries. 4. No public URL? Poll the bridge, or use a callback URL through the Hookdeck CLI. The bridge is the MCP server beside Event Gateway. It lists the events on offer, takes subscriptions and sets each one up as an Event Gateway connection with its own filter, dedupe and retry [rules](/docs/connections#connection-rules). It keeps no database, and Event Gateway doesn't relay events through it, so deliveries continue while it restarts or redeploys. A bridge that stored subscriptions and delivered events itself would need a database, a queue and a retry scheduler next to every deployment. Event Gateway already runs those, so the bridge is an MCP server that configures Event Gateway, and little else. Event Gateway's record of every request also serves the bridge's poll mode, replay, and its `get_event` and `list_events` tools. Each delivery includes a cursor, and a client that subscribes again with its latest cursor gets the events it missed, as far back as Event Gateway keeps requests (3 days on the Developer plan). ## Sources for Resend, GitHub, Stripe and your own services Sources are listed in `bridge.config.ts`: ```ts import { defineConfig, env } from '@hookdeck/mcp-events-bridge'; import { github, resend, source } from '@hookdeck/mcp-events-bridge/sources'; export default defineConfig({ sources: [ resend({ apiKey: env('RESEND_API_KEY') }), github({ // only setup uses the token; a deployed bridge runs without it token: env('GITHUB_TOKEN', { optional: true }), scope: { repos: ['your-org/your-repo'] }, }), ], }); ``` * **Resend:** inbound email, offered as `resend.email.received`, with the sender, recipients and subject. The body stays in Resend; the agent reads it with Resend's own tools. Subscribers filter by `from` and `to`. * **GitHub:** 26 webhook types, such as `github.issues`, `github.pull_request` and `github.workflow_run`, filtered by repository, action or sender. Seven are on by default (issues, issue comments, pull requests, reviews, pushes, releases and workflow runs); choose others with `events: [...]`, or `['*']` for all. `setup` adds the repository webhooks with a fine-grained token, or you add them by hand. * **Stripe, Slack, Shopify, Linear and many more:** `source({ type })` uses Event Gateway's own source type for the service. Event Gateway checks the service's signatures, including the timestamped ones Stripe and Slack send, and answers Slack's URL verification when you register the URL, so neither needs code. You name the events, say where the service puts each event's type and ID, and paste the URL `setup` prints into the service's webhook settings. The TypeScript types list each type's credentials, so a config with a missing or unknown one doesn't compile. We've tested it with requests signed as Stripe and Slack sign them, and authenticated as Postmark does, but not yet from accounts at those services. * **Your own services:** a `webhook` source takes any sender that signs the request body with HMAC or Standard Webhooks, or sends Basic auth or an API key. Event Gateway verifies every request, and there's no unverified option, because anyone with the URL could otherwise wake your agent with whatever they sent. Stripe, for example, is one more entry in `sources`, and its events are offered as `stripe.invoice.paid` and `stripe.customer.subscription.deleted`: ```ts source({ type: 'stripe', secret: env('STRIPE_WEBHOOK_SECRET'), // the signing secret, whsec_... events: { 'invoice.paid': { description: 'A Stripe invoice was paid.' }, 'customer.subscription.deleted': { description: 'A Stripe subscription ended.', }, }, eventType: { field: 'type' }, // where Stripe names the event eventId: { field: 'id' }, // evt_..., stable across Stripe's retries occurredAt: { field: 'created' }, }), ``` Once the bridge is installed (see the next section), you can also add a source from the command line. A trading server that sends a webhook when an order fills, for example, becomes `fills.order.filled`, and an agent subscribes to fills for the symbols it trades: ```sh npx mcp-events-bridge sources add fills --type webhook \ --event order.filled --event-id-header x-delivery-id \ --filter symbol --filter side ``` That creates the Event Gateway source, prints its URL to register with the sender, adds an empty credential variable to `.env` (here `FILLS_WEBHOOK_SECRET=`), and prints the `source({...})` entry for your config. Put the secret the sender gives you in `.env` and run `setup` again; until then, `serve` won't start. `--type stripe` and the other source types work the same way. When those options aren't enough, for example for a payload that needs summarizing, you can write your own source with [`defineSource`](https://github.com/hookdeck/mcp-events-bridge/blob/main/docs/ARCHITECTURE.md#adding-a-source). It sets how each event is recognized and summarized, and which filters subscribers can use. Its functions run inside Event Gateway, so they have to be self-contained. The README's [Sources](https://github.com/hookdeck/mcp-events-bridge#sources) section covers every option. ## Set up the MCP Events bridge You need Node 22.12 or later and a free [Hookdeck account](https://dashboard.hookdeck.com/signup) with a project for the bridge (its API key and signing secret). To run the bridge locally, install the [Hookdeck CLI](/docs/cli). You also need at least one source, such as a Resend or GitHub account, or any service that signs or authenticates its webhooks, including your own. ```sh mkdir my-bridge && cd my-bridge npm init -y && npm pkg set type=module npm install @hookdeck/mcp-events-bridge # .env and .hookdeck/ hold credentials printf 'node_modules/\n.env\n.hookdeck/\n' > .gitignore ``` 1. Choose sources in `bridge.config.ts`, as above. 2. Add `HOOKDECK_API_KEY`, `HOOKDECK_SIGNING_SECRET` and each source's credentials to `.env`. 3. Run `npx mcp-events-bridge setup`. It creates the Event Gateway sources and their transformations, and registers the Resend and GitHub webhooks for you. The first run generates an MCP secret, which you add to `.env` as `BRIDGE_MCP_SECRET`. 4. Run `npx mcp-events-bridge serve`. Locally, it also starts `hookdeck listen`, so Event Gateway's notifications about failing callbacks reach the bridge on your laptop. A coding agent can do this for you with the bridge's [Agent Skill](https://github.com/hookdeck/mcp-events-bridge/blob/main/skills/mcp-events-bridge/SKILL.md): ```sh npx skills add hookdeck/mcp-events-bridge ``` Then ask it to set up the bridge. The [README](https://github.com/hookdeck/mcp-events-bridge#readme) covers every option and deploying to Fly.io, the documented host. ## Subscribe to Resend and GitHub events from ChatGPT ChatGPT supports MCP Events with webhook delivery, in Work chats (ChatGPT's Work mode). To connect the bridge: 1. Run the bridge where ChatGPT can reach its MCP endpoint. [Deploy it to Fly.io](https://github.com/hookdeck/mcp-events-bridge#deploy-to-flyio), or expose a local bridge with a tunnel. The Hookdeck CLI can't replace the tunnel here, because ChatGPT needs the bridge's responses to its MCP requests, and Event Gateway answers each request itself rather than passing back the bridge's. Events don't need the tunnel, because Event Gateway delivers them to ChatGPT directly. 2. With **Developer mode** on (ChatGPT Plus or above), go to **Plugins**, choose **Add > Create MCP App**, paste `https://I have not seen near enough excitement about MCP Events https://t.co/tlWV1jyuxX
— Nathan Baschez (@nbaschez) October 3, 2026
Right now, the only way most people's agents can wake up and do something is either A) cron, or B) you decide to message it
Event-driven triggers are a huge deal