Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hooksense-mcp Create a callback endpoint, wait for the result, and verify signature"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server for HookSense — the webhook & callback layer for AI agents. Lets Claude Desktop, Cursor, Claude Code, Continue, and any MCP client create a callback URL, wait for the result instead of polling, and verify its signature — all from the agent session.
Agents that kick off async work — a deploy, a render, a human-in-the-loop approval, a long tool call, another agent — need the result back without burning context on polling loops. With this server the agent creates a callback endpoint, hands the URL to the job, then calls wait_for_callback and is woken the instant the webhook lands — signature-verified and decrypted. Stop polling for async results; await them.
Related MCP server: RequestBin MCP Server
Get an API token at https://hooksense.com/account/tokens
Configure your MCP client (examples below)
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"hooksense": {
"command": "npx",
"args": ["-y", "@hooksense/mcp"],
"env": {
"HOOKSENSE_TOKEN": "hsk_your_token_here"
}
}
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"hooksense": {
"command": "npx",
"args": ["-y", "@hooksense/mcp"],
"env": {
"HOOKSENSE_TOKEN": "hsk_your_token_here"
}
}
}
}Once configured, ask your agent:
Create — "Create a callback endpoint." → the agent calls create_callback_endpoint and gets back a callbackUrl like https://hooksense.com/w/ab12cd.
Fire — point any job at that URL (or just curl -X POST <callbackUrl> -d '{"status":"done"}' from another terminal).
Await — "Wait for the callback." → the agent calls wait_for_callback and blocks until the webhook lands, then receives { status: "received", request: { body, headers, … } }.
Verify (optional) — set a webhook secret on the endpoint, then "Verify the signature." → verify_signature confirms the payload is authentic before the agent acts on it.
No polling, no dashboards, no copy-paste.
Tool | Description |
| Create a callback endpoint; returns the |
| Block until the next callback lands, then return it ( |
| List callbacks received by an endpoint (summary view) |
| Fetch one callback with full headers + decrypted body |
| Timing-safe HMAC check against the endpoint's configured secret |
| POST a received callback to any target URL |
| List your endpoints |
| Get one endpoint's full settings |
Variable | Default | Notes |
| (required) | API token from /account/tokens |
|
| Override for self-hosted/staging |
"Create a callback endpoint, use it as the webhook for my Replicate prediction, and wait for the result — then summarize the output."
"Open a callback URL, give it to the approval step, and block until a human approves before continuing."
"Wait for the next Stripe callback on
payments-prod, verify its signature, and tell me the amount."
MIT
Create a callback endpoint and return its URL. Hand this URL to a long-running/async job (or another agent) as its webhook/callback target, then await the result with wait_for_callback. Also works as a plain webhook capture URL for any provider (Stripe, GitHub, …).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional human-readable slug (3-32 chars, letters/numbers/hyphens). Requires Hook plan or above. Auto-generated if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears full burden. It discloses creation and return of URL, optional slug, and plan requirement. Lacks details on permissions, rate limits, or persistence, but adequate for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. Front-loads key action and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return (URL). Mentions awaiting via sibling. Sibling list provides context. Adequate for a simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value by explaining slug is optional, auto-generated, and requires Hook plan, which is beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a callback endpoint and return its URL', specifying the action and resource. It distinguishes from siblings like wait_for_callback by explaining its role as a webhook target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: hand URL to async job/agent and await with wait_for_callback. Also mentions works with any provider. No exclusions, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single received callback with full headers, decrypted body, and metadata. Use this to read the result of an async job after wait_for_callback or list_callbacks gives you a callback id.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | Callback UUID, from wait_for_callback or list_callbacks |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return content (headers, decrypted body, metadata) but does not mention side effects, auth requirements, or rate limits. For a simple fetch operation, this is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states the action and what is returned, second sentence provides usage guidance. No extraneous words, front-loaded with key information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter. The description explains what the tool returns (headers, decrypted body, metadata) and provides workflow context (after wait_for_callback or list_callbacks). No output schema, but description covers the return well. Complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes requestId with detailed context ('Callback UUID, from wait_for_callback or list_callbacks'). Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema, so score remains 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'a single received callback with full headers, decrypted body, and metadata', which precisely defines the tool's purpose. It also distinguishes it from siblings by mentioning the use case after wait_for_callback or list_callbacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool after obtaining a callback ID from wait_for_callback or list_callbacks, providing clear usage context. It doesn't explicitly state when not to use it, but the workflow implication is sufficient. Sibling tools have different purposes, aiding differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific endpoint — its full URL, signature provider config, and custom response settings.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Endpoint slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It states it 'gets details' implying read-only, but does not disclose authentication needs, error behavior, or side effects. Some transparency from listing returned info, but significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no waste, directly states purpose and what is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one required param and no output schema. Description adequately indicates what details are returned. Could be improved by mentioning error handling (e.g., if slug not found), but overall sufficient for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'slug' (described as 'Endpoint slug'). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get details' and clearly identifies resource 'specific endpoint', listing the types of details (URL, signature provider config, custom response settings). This distinguishes it from sibling tools like list_endpoints or create_callback_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied: when you need details for one endpoint, but no 'when-not' or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List callbacks received by an endpoint, newest first. Returns a summary (method, status, provider, received_at). Use get_callback_payload for the full body. Tip: read the newest received_at and pass it as after to wait_for_callback to wait only for what comes next.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Endpoint slug (e.g. 'stripe-prod') | |
| limit | No | Max callbacks to return (1-100, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns a summary with specific fields and that results are newest-first. No side effects are mentioned, but the tool appears read-only. The description could mention pagination or lack of mutations, but it's fairly transparent for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose+ordering, return format+alternative tool, and a usage tip. No unnecessary words, well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return format (method, status, provider, received_at). It references relevant sibling tools. It does not cover error cases or edge conditions, but for a straightforward list tool, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond the schema. It mentions ordering and return summary, but these are not tied to parameters. No extra context for slug or limit beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List callbacks'), the resource ('received by an endpoint'), and ordering ('newest first'). It differentiates from siblings by referencing get_callback_payload for full body and wait_for_callback for sequential waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (list summaries) and when to use alternatives (get_callback_payload for full body). It also provides a practical tip linking to wait_for_callback, showing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhook endpoints owned by the authenticated user. Returns slug, created_at, and request counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication scope and return fields but lacks details on pagination, rate limits, or read-only nature. The basic behavior is clear, but deeper context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 14 words, front-loading the verb and resource. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the basic behavior and return fields. It is complete enough for a simple list tool with no parameters, but could mention pagination or filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (vacuously). The description does not need to add parameter meaning. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'all webhook endpoints', and the scope 'owned by the authenticated user'. It also mentions the return fields (slug, created_at, request counts), which distinguishes it from sibling tools that deal with specific endpoints or callbacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all webhook endpoints, which is clear from the context and sibling names. However, it does not explicitly provide when-not-to-use or alternative tools, though the sibling differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay a received callback to a target URL. The original headers and body are re-sent unchanged — useful to re-drive your handler against a known payload without re-triggering the upstream event.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | Callback UUID to replay | |
| targetUrl | Yes | Where to POST the replayed payload (e.g. http://localhost:3000/webhooks/stripe) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states headers and body are re-sent unchanged, which is a key behavioral trait, but does not cover error handling, idempotency, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required params and no output schema, the description covers purpose, usage, and key behavior, though it could mention potential pitfalls like duplicate replays.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description does not add meaning beyond what the schema provides for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replays a received callback to a target URL, which is a specific verb+resource. It distinguishes from sibling tools like create_callback_endpoint or get_callback_payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('re-drive your handler against a known payload without re-triggering the upstream event') but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the HMAC signature of a received callback against the endpoint's configured secret (Stripe, GitHub, Shopify, or custom), using a timing-safe comparison. Returns whether the callback is authentic and untampered — call this before your agent acts on a payload. Requires the endpoint to have a webhook secret configured and a paid plan.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Endpoint slug the callback belongs to | |
| requestId | Yes | Callback UUID to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses timing-safe comparison, requirement for webhook secret and paid plan, and that it returns authenticity status. Without annotations, the description provides adequate transparency about behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers what, how (timing-safe), when (before acting), and prerequisites. Return format is implied, which is acceptable for a boolean-like check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for slug and requestId. The description reinforces their purpose but does not add significant new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool verifies HMAC signatures of callbacks, specifying supported integrations (Stripe, GitHub, Shopify) and the timing-safe comparison. It distinguishes from siblings like get_callback_payload or replay_callback by focusing on authentication verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this before acting on a payload, and outlines prerequisites (webhook secret, paid plan). While it doesn't explicitly exclude scenarios or compare alternatives, the context is clear about when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block until the next webhook (callback) arrives at an endpoint, then return it — instead of polling. Use this for async/long-running work: kick off the job with the endpoint URL as its callback, then call wait_for_callback to receive the result the moment it lands (signature-verified, decrypted). Returns { status: 'received', request } on delivery, or { status: 'pending' } if timeoutMs elapses first (just call again to keep waiting). Pass after (the receivedAt of the last callback you saw) so a callback that arrived between calls is returned immediately rather than missed.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Endpoint slug to wait on (from create_callback_endpoint) | |
| timeoutMs | No | How long to block before returning 'pending' (1000–60000, default 30000). | |
| after | No | Optional ISO timestamp cursor. Any callback received after this is returned immediately without blocking — pass the previous callback's receivedAt to avoid missing one between calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys behavioral traits: blocking until callback or timeout, signature verification, decryption, and the two return states. It also explains the 'after' cursor to avoid missing callbacks between calls. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states core function, second gives usage context, third describes return types, fourth explains the 'after' parameter. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers blocking, timeout, return structures, and parameter usage. It mentions signature verification but doesn't detail the 'request' object structure. However, without an output schema, the provided JSON example suffices. Slightly incomplete for a complex async tool, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions, so baseline is 3. The description adds extra context: 'from create_callback_endpoint' for slug, 'how long to block' for timeoutMs, and an example for 'after' explaining its purpose. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool blocks until a webhook callback arrives and returns it, distinguishing it from polling. It uses specific verbs ('block', 'return') and references the resource ('webhook callback'), differentiating it from sibling tools like create_callback_endpoint or list_callbacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'for async/long-running work: kick off the job... then call wait_for_callback'. It contrasts with polling and explains the retry behavior if timeoutMs elapses. It provides clear context for usage without mentioning alternatives by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0create_callback_endpointget_callback_payloadget_endpointlist_callbackslist_endpointsreplay_callbackverify_signaturewait_for_callbackScored across 8 tools
Every tool has a clearly distinct purpose: creating, listing, getting endpoints; waiting for, listing, replaying, and verifying callbacks. No functional overlap.
All tool names follow the consistent verb_noun pattern (e.g., create_callback_endpoint, get_callback_payload, list_callbacks), making them predictable.
8 tools is well-scoped for a webhook management server, covering endpoint creation, callback handling, and security verification without excess.
The tool set covers the full lifecycle: create/list/get endpoints, receive callbacks (wait_for_callback), inspect (list/get), replay, and verify signatures. No obvious gaps.
Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.
Webhook capture bins for agents: get a URL, wait for webhooks, set replies, verify signatures.
A webhook inbox for agents: one call returns a live URL. Mock, verify, inspect and replay.
Receive, inspect, replay and deliver webhooks — with signature verification and agent triggers.
