What is an MCP webhook?
An MCP webhook connects the Model Context Protocol to webhook events. The term covers two things: an MCP server that lets an AI agent send or receive webhooks, and native webhook delivery being added to the MCP specification itself so agents can get results of asynchronous work pushed to them.
The two meanings
When people search for "MCP webhook" they usually mean one of these:
- A webhook MCP server. An MCP server that exposes webhook functionality as tools, so an agent like Claude can post a payload to a webhook URL or read events that arrived from external services.
- Webhooks in the MCP protocol. Spec-level support for pushing asynchronous results to MCP clients over HTTP, instead of holding a connection open or polling.
The first exists today and you can build one in an afternoon. The second is on the protocol roadmap. Both matter for the same reason: agents are useful when they can react to things happening in the real world, and webhooks are how the real world announces that something happened.
Webhook MCP servers
An MCP server is a small program that exposes tools an AI agent can call. A webhook MCP server applies that to webhook traffic, in one or both directions.
Sending. The server exposes a tool like send_webhook that POSTs a JSON payload to a configured endpoint. This is how an agent notifies Slack, triggers a Zapier flow, or pings your own service when it finishes a long task. Most of the small open source webhook MCP servers do exactly this.
Receiving. The harder direction. Webhook providers need a public URL to deliver to, but an MCP server typically runs on your laptop as a subprocess of the MCP client, with no inbound HTTP. The usual answer is a webhook gateway in the middle: the provider delivers to the gateway's public URL, the gateway verifies the signature and stores the event, and the MCP server polls it over outbound HTTPS. How to build a webhook MCP server walks through a working implementation.
Webhooks in the MCP protocol
MCP became stateless in the 2026-07-28 release, which also introduced a tasks extension for asynchronous work: a client kicks off a task, gets a task ID, and checks back for the result. Being stateless is the precondition for real event-driven behavior, and the working group's next step is webhook delivery, so a client can hand over a URL and get notified when the task finishes rather than polling for it. Our blog post on MCP going stateless covers why this progression matters.
That will make webhooks part of how MCP itself communicates, which raises the familiar operational questions: retries, signing, deduplication, and observability. See MCP vs webhooks for how the protocol and the pattern relate.
Frequently asked questions
What is a webhook MCP server?
An MCP server that exposes webhook functionality as tools an AI agent can call: sending a payload to a webhook endpoint, listing events that arrived from external providers, or both. It connects agents like Claude to event-driven systems.
Can an MCP server receive webhooks?
Not directly, because MCP servers usually run locally without a public URL. The standard pattern is to point providers at a webhook gateway such as Svix Ingest, which verifies and stores events, and have the MCP server poll it over outbound HTTPS.
Does the MCP protocol support webhooks?
Not yet. The 2026-07-28 release made MCP stateless and added a tasks extension for asynchronous work; webhook delivery for task results is planned for a following release.