Your Agent Can Read Webhooks. It Can Also Send Them.
Wiring an assistant to webhooks usually means the events someone else emits. Hook0 works the other way round: an MCP server that lets Claude, Cursor or Windsurf operate the webhooks your own product sends. Register event types, create subscriptions, ingest events, replay what failed.
100 events/day free. No credit card. The MCP server runs on your machine.
In short
Hook0's MCP server is a local process that exposes your Hook0 account to an MCP-compatible assistant as 17 tools. Nine read your applications, event types, subscriptions, events and delivery attempts. Eight write: create an event type, wire a subscription, emit an event, replay a failed delivery.
The short version
- Install
cargo install hook0-mcp- Tools
- 17 (9 read, 8 write)
- Clients
- Claude Desktop, Cursor, Windsurf, Cline, and any MCP client
- Transport
- stdio by default, SSE if you run it as a service
- Runs against
- Hook0 Cloud, or your own instance via
HOOK0_API_URL - Restricting it
HOOK0_READ_ONLY=trueplus an attenuated service token- License
- Open-source (SSPL-1.0), no open-core holdback
Webhooks and agents point two different ways
The two are often discussed as one subject. They are not the same problem and they are not solved by the same tool.
An agent that receives webhooks
Something happens in Stripe, GitHub or a CRM, and an agent needs to react to it. The hard parts are inbound: a public endpoint or a tunnel, signature verification, deduplication, and not firing the same agent run twice. Tooling for this direction is well covered.
An agent that operates what you send
You are the one emitting events. Your customers subscribe to order.completed and expect it to arrive. The work is outbound: registering event types, wiring subscriptions, reading why an attempt failed, replaying it once the receiver is fixed. That is the side Hook0's MCP server exposes to your assistant.
If you ship a product other systems subscribe to, the second direction is the one that costs you support tickets.
Two protocols, two layers
They get compared because both carry events around. They sit at different layers, and a setup that works usually has both.
- A webhook
- An HTTP request your product sends to a URL a customer registered, when something happens on your side. One-way, machine-to-machine, signed so the receiver can trust it, retried when the receiver is down. It is the data plane: it moves the event.
- MCP
- The Model Context Protocol, how an assistant discovers and calls tools. Request/response, driven by a person in a conversation, running locally. It is a control plane: it operates the thing that moves the event.
- Together
- Your product keeps emitting events through the REST API or an SDK, unchanged. MCP is what you reach for when you need to register a new event type, point a subscription somewhere else, or work out why yesterday's delivery failed, without opening the dashboard.
What the assistant can actually do
Seventeen tools, split between reading and writing. This is the shipped list, not a roadmap. Each one is documented, with its example prompt, in the MCP reference.
| Tool | What it does | What you type |
|---|---|---|
| Read (9 tools) | ||
list_organizations |
List the organizations you can reach | “Show my organizations” |
list_applications |
List the applications in an organization | “What apps do I have?” |
get_application |
Read one application's details | “Show details for app X” |
list_event_types |
List the event types registered on an application | “What event types are registered?” |
list_subscriptions |
List webhook subscriptions and their configuration | “Show all my webhooks” |
get_subscription |
Read one subscription's configuration | “Show webhook configuration for…” |
list_events |
List events emitted by an application | “Show recent events” |
get_event |
Read one event, payload included | “Show event abc123” |
list_request_attempts |
List delivery attempts for an event | “Show delivery history for event X” |
| Write (8 tools) | ||
create_application |
Create an application | “Create an app called Order Service” |
delete_application |
Delete an application | “Delete the test application” |
create_event_type |
Register a new event type | “Add event type order.completed” |
create_subscription |
Create a webhook subscription against a URL | “Create a webhook to https://…” |
update_subscription |
Change or disable an existing subscription | “Disable the webhook for…” |
delete_subscription |
Delete a subscription | “Remove the staging webhook” |
ingest_event |
Emit an event, the sending side, from the assistant | “Send a test user.created event” |
retry_delivery |
Replay a delivery that failed | “Retry the failed delivery for event X” |
Plus eight resource URIs under hook0:// for direct lookups, and three guided prompts for the flows people repeat: create a subscription, debug a delivery, set up an application.
Full tool reference, with the setup for Claude Desktop, Cursor, Windsurf and Cline
Three steps to your first prompt
The server is a Rust binary you install once. Nothing runs on Hook0's side that was not already running.
-
1. Install the server
It ships on crates.io and builds to a single binary.
cargo install hook0-mcp -
2. Create a service token
In the Hook0 dashboard, under your organization's service tokens. Attenuate it to the applications the assistant should reach before you paste it anywhere.
-
3. Declare it in your assistant
Claude Desktop reads
claude_desktop_config.json. Cursor, Windsurf and Cline take the same block in their own config file.{ "mcpServers": { "hook0": { "command": "hook0-mcp", "env": { "HOOK0_API_TOKEN": "your-service-token-here" } } } }
Restart the assistant and ask it something you would otherwise click through: “why did my last webhook delivery fail?”
Config file paths per assistant, environment variables and SSE mode
Handing an agent your delivery infrastructure
Write access to production webhooks is not something to grant casually. Three controls ship with the server, and they compose.
Read-only mode
Set HOOK0_READ_ONLY=true and the server advertises only the nine read tools. The assistant can investigate a failed delivery and cannot change anything while doing it.
Attenuated tokens
Read-only mode narrows the tool list; the token itself still carries whatever it was granted. Attenuation restricts a token to specific applications and can carry an expiry, enforced at the API rather than in the client. Use both. They cover different failure modes.
It runs where you run it
The MCP server is a local process talking to the Hook0 API. The assistant sees what the tools it calls return, and nothing else is forwarded anywhere. Point HOOK0_API_URL at your own instance and the same tools drive a self-hosted deployment.
The agent is an interface, not the guarantee
Natural language changes how you operate webhook delivery. It does not deliver anything by itself. This is what does.
Signed, retried, logged
Every attempt carries an HMAC-SHA256 signature. Retries are two-phase and configurable, so a subscriber that is down for an hour does not cost you that hour of events. Every attempt is logged, which is what makes “why did this fail” answerable by a lookup instead of a guess.
An EU data plane, on every plan
Payloads, database and backups run on Clever Cloud SAS infrastructure in France, inside the EEA, including on the free tier. The CDN in front is Cloudflare, Inc. (USA), disclosed in the public sub-processor list with its transfer mechanism. Details on EU webhook infrastructure.
A codebase you can take
Hook0 is open-source (SSPL-1.0), with no open-core holdback: the hosted service runs the code you can run. The MCP server, the API and the subscriber portal behave the same way against a self-hosted instance.
Before you point an assistant at production
How do I use webhooks with MCP tools?
Install hook0-mcp, create a Hook0 service token, and declare the server in your assistant's configuration file. From then on the assistant has seventeen tools against your account: it can list what exists, register an event type, create a subscription against a URL, emit a test event, and replay a delivery that failed. Your application keeps emitting its real events through the REST API or an SDK, and that path is unchanged.
What is the difference between MCP and a webhook?
A webhook is an HTTP request your product sends to a URL a customer registered, one-way and machine-to-machine, signed so the receiver can trust it. MCP is how an assistant discovers and calls tools, request/response, driven by a person in a conversation. The webhook moves the event; MCP operates the system that moves it. Most setups that use both keep the webhook path untouched and use MCP for the operating work.
Does the assistant see my event payloads?
It sees what the tools it calls return, and reading an event returns that event's payload. Nothing is forwarded to a third party by Hook0: the MCP server is a local process that talks to the Hook0 API directly. If payloads should stay out of the conversation entirely, attenuate the token to the applications that carry no sensitive data.
Which assistants work with it?
Claude Desktop, Cursor, Windsurf and Cline are documented with their configuration file, and any MCP-compatible client works the same way. ChatGPT does not support MCP natively today.
What stops an agent from deleting a production subscription?
Two things, and they are worth combining. Read-only mode removes the write tools from the list the assistant can see. Token attenuation restricts what the token itself may touch, enforced at the API, so a mistake in the client cannot exceed it. Deleted resources are not automatically restorable, which is the reason to set both before pointing an assistant at production.
What happens to events when a subscriber endpoint is down for a while?
Hook0 retries the delivery on a two-phase, configurable schedule rather than dropping it on the first failure, and it records every attempt with its response. Once the receiver is fixed you replay what failed, from the dashboard, from the API, or by asking the assistant to retry that delivery. The event itself is not lost while the endpoint is unreachable.
How does the receiving side verify a payload Hook0 sent?
Every attempt carries an HMAC-SHA256 signature computed from the payload and the subscription's secret. The receiver recomputes it and compares before acting on the event, which is what stops a forged request from triggering a workflow. The signature scheme and a verification snippet are in the Hook0 documentation.
Does this work with self-hosted Hook0?
Yes. Set HOOK0_API_URL to your instance and the seventeen tools behave identically. The whole product is open-source (SSPL-1.0) with no open-core holdback, so the self-hosted deployment is the same software as the cloud one.
Is this an Agent Skill or a plugin?
No. It is an MCP server, installed with cargo install hook0-mcp and declared in your assistant's configuration. It runs over stdio by default, or over SSE if you would rather run it as a service.
Do I need the MCP server to send webhooks?
No. The REST API and the SDKs are the normal path for your application to emit events, and they are unaffected by any of this. The MCP server is for the human operating the setup: registering an event type, wiring a subscription, working out why one delivery failed at four in the afternoon.
You have better things to build
Stop building webhook infrastructure. Start shipping features. Get started in minutes.