This MCP server lets you create and inspect temporary webhook capture endpoints in an agent sandbox, then connect a webhooks.cc account for full features.
Create up to 3 sandbox endpoints (25 captured requests each, 100 total; deleted 24h after sandbox creation) and list/get/delete them.
First create_endpoint call registers the sandbox, which takes a few seconds of proof of work.
List and inspect recent captured requests for an endpoint, including full request details.
Wait/poll for incoming requests and generate TypeScript, Zod, Pydantic, or JSON Schema payload types.
Endpoint creation schema exposes options for names, expiry, mock responses, response rules, signing, and notification URLs; mock responses, notifications, and signature verification require an account.
Connect to a human's webhooks.cc account via email plus a 6-digit code, then wait for the connection.
Explain sandbox capabilities and limits without making a network call.
Supports debugging GitHub CI/CD webhooks: capture and inspect exactly what GitHub sends on pushes, pull requests, and deployments, verify the webhook signature with GitHub as the signing provider, and replay captured payloads against a local handler.
Supports testing and debugging Stripe payment webhooks: point Stripe's test webhooks at a capture endpoint, inspect the exact payloads and headers, wait for requests matching a stripe-signature header, verify signatures using Stripe as the signing provider, send test events such as checkout.session.completed, and replay captured requests to a local server.
Inspect and debug webhooks without deploying to production.
Get a unique URL, point your webhook there, and see every request in real-time. No signup required.
Visit webhooks.cc
Copy your unique webhook URL
Send a test request: curl -X POST https://go.webhooks.cc/w/<slug> -d '{"test": true}'
Watch it appear in the dashboard
Related MCP server: webhook-ai-mcp
Capture requests — Store incoming webhooks with headers, body, query params, and metadata
Inspect in real-time — See requests the moment they arrive via WebSocket
Configure responses — Return custom status codes, headers, and body for testing error paths
Forward to localhost — Tunnel webhooks to your local server during development
CLI with interactive TUI — Manage endpoints, tunnel, and stream requests from your terminal
TypeScript SDK — Access webhook data programmatically for automation and testing
MCP server — Connect AI coding agents (Claude Code, Cursor, VS Code, Codex) to your webhooks
Testing payment integrations — Point Stripe's test webhooks at your endpoint. Inspect the payload structure before writing handlers.
Debugging CI/CD hooks — See exactly what GitHub sends when a push, PR, or deployment occurs.
Developing locally — Forward production-like webhooks to localhost without exposing your machine to the internet.
Mocking failure scenarios — Configure your endpoint to return 500 errors and test your retry logic.
Free — 50 requests/day, 7-day data retention. Enough for development and testing.
Pro ($8/month) — 100,000 requests/month, 30-day retention. For production monitoring and high-volume testing.
See webhooks.cc for details.
curl -fsSL https://webhooks.cc/install.sh | sh
# or
brew install kroqdotdev/tap/whk
# without root: any directory you can write to (created when missing)
curl -fsSL https://webhooks.cc/install.sh | WHK_INSTALL_DIR="$HOME/.local/bin" shWith WHK_INSTALL_DIR, put that directory on your PATH (the installer prints the line to add) before running whk.
Then launch interactive terminal:
whknpm install @webhooks-cc/sdk# Claude Code
claude mcp add -s user webhooks-cc -e WHK_API_KEY=whcc_... -- npx -y @webhooks-cc/mcp
# Cursor, VS Code, Devin Desktop (formerly Windsurf), Claude Desktop
npx @webhooks-cc/mcp setup cursor --api-key whcc_...See webhooks.cc/installation for all install methods, one-click buttons, and setup guides.
Run whk to launch the interactive TUI:
$ whk
webhooks.cc
● Logged in as you@example.com
▸ Tunnel Forward webhooks to localhost
Listen Stream incoming requests
Create Create a new endpoint
Endpoints Manage your endpoints
Auth Login / logout
Update Check for updatesAll commands also work directly from the command line:
whk tunnel 8080 # Forward webhooks to localhost:8080
whk listen <slug> # Stream incoming requests
whk create my-endpoint # Create a new endpoint
whk list # List your endpoints
whk replay <request-id> --to :3000 # Replay a captured requestPass --nogui or set WHK_NOGUI=1 to skip the TUI and print help.
import { WebhooksCC, matchMethod, matchHeader, matchAll } from "@webhooks-cc/sdk";
const client = new WebhooksCC({ apiKey: "whcc_..." });
const endpoint = await client.endpoints.create({ name: "my-webhook" });
console.log(endpoint.url);
// Wait for a matching request with human-readable timeout
const req = await client.requests.waitFor(endpoint.slug, {
timeout: "30s",
match: matchAll(matchMethod("POST"), matchHeader("stripe-signature")),
});
// Replay captured requests to your local server
await client.requests.replay(req.id, "http://localhost:3000/webhooks");The @webhooks-cc/mcp package exposes 46 tools that let AI agents manage endpoints, inspect webhooks, send test payloads, and replay requests through natural language.
You: "Create a webhook endpoint for testing Stripe"
Agent: Created endpoint "stripe-test" at https://go.webhooks.cc/w/abc123
You: "Send a test checkout.session.completed event"
Agent: Sent POST to stripe-test
You: "Replay that to my local server"
Agent: Replayed to http://localhost:3000/webhooks — 200 OKSee packages/mcp/README.md for full setup and tool reference.
The source is available for transparency and community contributions, not as a deployment guide. To contribute, see CONTRIBUTING.md.
For compliance or air-gapped environments, the code is here. For most use cases, the hosted service at webhooks.cc is the easier path.
This project uses a split license:
AGPL-3.0: the web app, receiver, email-capture SMTP host, and Supabase backend (apps/web/, apps/receiver-rs/, apps/mx-rs/, supabase/). See LICENSE.
MIT: the CLI, SDK, and MCP server (apps/cli-rs/, packages/sdk/, packages/mcp/). See their respective LICENSE files.
If you use the CLI, SDK, or MCP server in your own projects, MIT applies. If you fork and host the service, AGPL-3.0 applies.
Explain what this agent can do without a webhooks.cc account, the sandbox limits, and how to connect an account. No network call.
| 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, and it does disclose one meaningful trait: 'No network call', telling the agent there are no side effects and no latency/cost. It does not say whether output is static text or account-dependent, which matters given 'how to connect an account' may or may not reflect account state.
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, front-loaded with the verb and the three topics it covers, ending with the no-network constraint. Nothing is wasted and nothing is missing from the sentence.
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 zero-parameter, no-output-schema informational tool, the description adequately frames what the agent gets back: sandbox capability summary, limits, and a connection path. Minor gap is not clarifying whether the account-connection portion depends on current account state.
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 tool takes zero parameters, so the baseline is 4; there is no parameter semantics to document or compensate for.
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?
States a concrete verb (Explain) and enumerates exactly what is explained: sandbox capabilities without an account, sandbox limits, and account connection. This clearly separates it from the endpoint/request management siblings, though it does not name them.
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?
Usage is implied rather than stated: 'No network call' signals this is a free, offline informational call, and 'without a webhooks.cc account' hints at the pre-authentication scenario. It never explicitly says when to call this versus connect_account or the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect this agent to a human's webhooks.cc account, for the full tool set (mock responses, signatures, email, teams) and to keep the sandbox endpoints. Returns a link and a 6-digit code: show both to the human, who signs in or signs up with that email and enters the code. Then call wait_for_connection. Calling again gives a new code.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email the human signs in to webhooks.cc with (their GitHub or Google primary email if they sign in that way); only someone signed in as it can connect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return payload (a link and a 6-digit code), that the human must act in a browser, and that repeat calls mint a fresh code. It stops short of stating what happens on failure, whether the code expires, or whether the call blocks, but the core behavior is well covered.
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?
Four sentences, front-loaded with purpose, then behavior, then next step. Every sentence contributes an actionable fact and none restates the tool name.
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?
There is no output schema, so the description must describe return values, and it does so precisely (link plus 6-digit code). For a one-parameter OAuth-style handshake tool, nothing an agent needs to invoke and follow up correctly is missing.
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% and the single email parameter is already fully documented, including the sign-in identity constraint. The description reinforces this by saying the human 'signs in or signs up with that email,' but adds no format or syntax detail beyond the schema, so it lands slightly above baseline rather than excelling.
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?
States a specific verb and resource ('Connect this agent to a human's webhooks.cc account') and immediately scopes what the connection unlocks (full tool set, keeping sandbox endpoints). It also names the follow-up sibling wait_for_connection, so an agent can place this tool in the workflow without opening any schema.
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?
Explicit sequencing is given: call this, show the link and code to the human, then call wait_for_connection. It also pre-empts the re-invocation question by stating 'Calling again gives a new code,' which is exactly the ambiguity an agent would face.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a temporary webhook capture endpoint in the agent sandbox (no account needed): up to 3 endpoints at a time, 25 captured requests each and 100 in all, deleted 24 hours after the sandbox was created. The first call registers the sandbox, which takes a few seconds of proof of work. Mock responses, notifications and signature verification need an account: see connect_account.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for the endpoint | |
| ephemeral | No | Create a temporary endpoint that auto-expires | |
| expiresIn | No | Auto-expire after this duration, for example "12h" | |
| mockResponse | No | Optional mock response to return when the endpoint receives a request | |
| responseRules | No | Conditional response rules. Each rule has conditions and a response. First matching rule wins. | |
| signingHeader | No | Custom signature header name. Only used with generic-hmac provider. | |
| signingSecret | No | Signing secret (encrypted server-side, never returned). Required when signingProvider is set. | |
| notificationUrl | No | URL to POST a JSON summary to after each captured request (e.g. Slack/Discord webhook) | |
| signingProvider | No | Signing provider for automatic signature verification (e.g. stripe, github, shopify) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses quotas (3 endpoints, 25 requests each, 100 total), the 24-hour expiry clock measured from sandbox creation, the one-time proof-of-work latency on first call, and which behaviors require an account. These are exactly the side effects and constraints an agent must know before calling a mutating 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?
Three short sentences: purpose first, then limits and cost, then the account boundary with a named sibling. Every clause (quota, expiry, latency, auth) carries actionable information and nothing repeats the schema.
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 9-parameter tool with nested objects and no output schema, the description covers limits, auth, and latency but never says the call returns a capture URL/id that the agent needs in order to use the endpoint or pass to wait_for_request. That return-value gap is the one missing piece for correct downstream use.
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, but the description adds real semantic gating for parameters the schema does not gate: mockResponse, notificationUrl, signingProvider and signingSecret are only usable with an account. That is meaningful parameter-level information beyond the field descriptions.
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?
States a specific verb and resource ("Create a temporary webhook capture endpoint") plus its scope ("in the agent sandbox"), which cleanly separates it from get_endpoint, list_endpoints and delete_endpoint. An agent can identify the create action without opening the schema.
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?
Gives a concrete use condition ("no account needed" / sandbox) and explicitly routes the account-requiring cases (mock responses, notifications, signature verification) to connect_account. It stops short of saying when not to create a new endpoint versus reusing one from list_endpoints, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of this agent's sandbox endpoints and its captured requests. Frees a slot; the sandbox's request budget is not refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The endpoint slug to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the cascade (captured requests are also removed) and two non-obvious side effects (a slot is freed; the request budget is not refunded). It stops short of stating irreversibility or permission/auth requirements explicitly, so not a 5.
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 short sentences, front-loaded with the core action and consequences. No filler, no repetition of the title or name.
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 one-required-param destructive tool with no output schema, the description covers the essential consequences (endpoint plus requests removed, slot freed, budget not refunded). Only irreversibility/permissions are left implicit, a minor gap at this complexity level.
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% and the single slug parameter is documented in the schema, so the baseline is 3. The description adds no format or identifier-hygiene guidance for slug beyond what the schema already says.
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?
States a specific verb (delete) and resource (this agent's sandbox endpoint) and adds scope detail — the captured requests go too. Easily distinguished from create_endpoint, list_endpoints, and get_endpoint siblings by the operation named.
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?
Usage is implied rather than stated: 'Frees a slot' gives a reason to delete, but there is no explicit when-to-use, no prerequisites, and no pointer to alternatives (e.g. a tool that only clears requests without deleting the endpoint).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate TypeScript interfaces, Zod schemas, Pydantic models, or JSON Schema from the bodies of requests captured by a sandbox endpoint. Several requests of one event teach which fields are optional or nullable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Root type name (default: from the detected event, else WebhookPayload) | |
| path | No | Only requests with this path | |
| event | No | Only requests whose detected provider event matches, e.g. "invoice.paid" or "push". One event per schema gives the tightest types. | |
| limit | No | How many of the latest requests to read before filtering | |
| format | No | Output: "typescript" interfaces, "zod" schemas, "pydantic" models, or "json-schema" | typescript |
| method | No | Only requests with this HTTP method | |
| requestIds | No | Use exactly these requests instead of the latest ones | |
| endpointSlug | Yes | The endpoint slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses that multiple requests of one event teach optionality/nullability, but it does not state whether the operation is read-only, whether anything is stored, or how it behaves when no matching requests exist.
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 core action and supported by one useful inference note. There is no wasted framing.
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 the rich input schema and the absence of an output schema, the description is mostly complete: it names the output formats and explains the inference source. It could say more about the returned shape or behavior when matching requests are unavailable, but the core invocation context is covered.
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%, so parameter meanings are already fully documented in the input schema. The description reinforces the format choices and event-grouping idea, but adds little beyond the schema for parameters such as path, method, limit, and requestIds.
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 states a specific verb and resource: generate TypeScript interfaces, Zod schemas, Pydantic models, or JSON Schema from captured request bodies. It also scopes the source as requests captured by a sandbox endpoint, making the tool clearly distinct from sibling request/endpoint management tools.
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?
It gives clear usage context: the schema is inferred from captured requests, and using several requests for one event improves optional/nullable detection. It does not explicitly name when not to use the tool or compare it to alternatives, but the siblings are not close substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one of this agent's sandbox endpoints by slug, with its sandbox limits and usage.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The endpoint slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses ownership scoping ('this agent's') and the return payload (sandbox limits and usage), but omits that this is a read-only/no-side-effect call and says nothing about error behavior for an unknown slug.
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 front-loaded sentence with no filler; the identifier constraint and the returned content both land immediately.
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 low-complexity, single-parameter read tool with no output schema, briefly naming the returned data (limits and usage) is nearly sufficient. Only the absence of any error/precondition note keeps it short of full completeness.
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% and there is a single parameter already documented as 'The endpoint slug'; the description's 'by slug' merely restates that. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb (Get) and resource (sandbox endpoint), plus the retrieval key (by slug) and the payload (limits and usage). The singular, slug-keyed framing separates it from list_endpoints and the create/delete siblings without naming them explicitly.
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?
There is no statement of when to use this versus list_endpoints (discovery) or the mutation siblings, and no preconditions given. Usage is only implied: you already know a slug and want its details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a request captured by a sandbox endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | The request ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does little beyond saying 'full details'. It doesn't disclose what fields are returned, whether requests can expire or be unavailable, or what happens with an invalid requestId.
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?
A single efficient sentence with the purpose front-loaded and no wasted words. It is terse to the point of under-specification, but structurally sound.
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 one-parameter read tool with full schema coverage, the description is minimally adequate. Without annotations or an output schema, it should say more about what 'full details' includes, but the core contract is clear enough to invoke.
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?
With one parameter at 100% schema coverage, the schema already documents requestId fully. The description adds no format, sourcing, or lookup semantics beyond what the schema states, so the baseline of 3 applies.
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?
States a clear verb+resource ('Get full details for a request') and scopes it to requests captured by a sandbox endpoint, which distinguishes it from the endpoint-level get_endpoint. It doesn't explicitly contrast with list_requests, but the 'details for a request' framing implies a single-record lookup.
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?
Usage is only implied: fetch one request's full details by ID, versus list_requests for enumeration. No explicit when-to-use, prerequisites, or named alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List this agent's sandbox endpoints. Empty until create_endpoint starts the sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Team id or name (case-insensitive). Keeps endpoints shared with you from that team and endpoints you own that are shared with it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does reveal one meaningful behavioral trait: the tool returns an empty list until create_endpoint starts the sandbox, which prevents misinterpreting an empty response. It says nothing about permissions, pagination, or filtering behavior for the optional team parameter.
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 short sentences with zero waste: the purpose statement comes first, and the lifecycle caveat follows immediately. Nothing is redundant or padded.
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 read-only list tool with one fully documented optional parameter and no output schema, the description covers purpose and the key state-dependency nuance. Only minor gaps remain (pagination, ordering), which are low-impact here.
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% and there is only one optional parameter, so the schema fully documents the team filter's scoping semantics. The description adds no additional parameter meaning, making the baseline 3 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?
States a specific verb (list) and resource (sandbox endpoints) with the scope narrowed to 'this agent's'. It does not explicitly distinguish itself from siblings like get_endpoint (single endpoint) besides the implied list/single distinction, so it is clear but not maximally differentiating.
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 lifecycle note 'Empty until create_endpoint starts the sandbox' gives useful operational context — the agent knows an empty result is expected pre-startup rather than an error. However, it does not state when to prefer this over get_endpoint or list_requests for enumerating resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent requests captured by a sandbox endpoint, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only HTTP requests ("http") or only captured emails ("email") | |
| limit | No | Max requests to return | |
| since | No | Only return requests after this timestamp in ms | |
| endpointSlug | Yes | The endpoint slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses sort order (newest first) and that results are scoped to a sandbox endpoint, but says nothing about read-only nature, truncation/limit behavior, pagination, or retention of captured requests.
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, front-loaded with the verb and resource, with the sort order appended efficiently. Nothing is wasted.
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?
There is no output schema, so the description should hint at the shape of a returned request (or at least confirm the list/ordering semantics and any caps), but it does not. Identification of the tool is complete enough to invoke it, but return expectations remain unset.
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%, so the schema already explains endpointSlug, kind, limit, and since. The description adds no parameter-level detail (e.g., how 'recent' relates to limit or whether since and limit combine), so the baseline 3 applies.
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?
States a specific verb (List) plus resource (requests captured by a sandbox endpoint) and adds ordering (newest first), which is more than the name conveys. It is inferably distinct from the singular get_request and wait_for_request, though no sibling is named explicitly.
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 gives no when-to-use framing at all — nothing about when to browse the list versus fetching a single request with get_request or blocking with wait_for_request, and no preconditions (endpoint must exist and have captured traffic) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the human to enter the code from connect_account. On success the full webhooks.cc tools for their account replace these sandbox tools. Returns after timeoutSeconds (default 45) if they have not finished yet; call it again to keep waiting.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutSeconds | No | How long to wait, in seconds (default 45) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses that the call blocks on a human action, that it returns rather than fails after timeoutSeconds, that re-invoking is the intended polling pattern, and that success causes these sandbox tools to be replaced by the account's full toolset.
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 dense sentences, front-loaded with purpose, and every clause carries information (dependency, side effect, timeout semantics, retry guidance). No filler.
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 one-parameter blocking tool with no annotations or output schema, this covers the essential behavior. The only minor gap is what the tool returns on success (a confirmation payload vs. silence) and behavior when connect_account was never invoked.
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% and the parameter is documented (default 45, range 1-600), so the baseline is 3. The description adds real meaning beyond the schema by explaining what the timeout actually causes — a return, not a failure — which changes how an agent should interpret the result.
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?
States a specific verb+resource ('wait for the human to enter the code from connect_account') and names the sibling it pairs with. An agent can distinguish it from wait_for_request or connect_account without opening any schema.
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?
Clear usage context: call it after connect_account once the human has the code, and re-call it on timeout to keep waiting. It does not explicitly disambiguate from the near-identically named sibling wait_for_request, nor state what to do if connect_account was never called, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a request to arrive at a sandbox endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | How long to wait, for example "30s" | 30s |
| endpointSlug | Yes | The endpoint slug to monitor | |
| pollInterval | No | Interval between polls, for example "500ms" or "1s" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses little: it does not say whether the call blocks until a request arrives, what happens when no request arrives before the timeout (error vs. empty result), or whether a maximum wait applies. For a blocking/polling tool these are exactly the traits an agent needs.
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?
A single tight sentence with the action and target front-loaded and zero filler. It is efficient, though the brevity tips into under-specification rather than optimal packing of information.
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 and no annotations exist, so the description must explain return behavior and timeout semantics, and it does neither. An agent cannot tell what a successful wait yields (the request object? a count?) or how failure is signalled.
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% and the schema already gives examples for timeout ('30s') and pollInterval ('500ms' or '1s'), plus a default of 30s. The description adds no syntax, range, or format detail beyond what the schema provides, so a baseline 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?
The description names a specific verb and resource ('wait for a request') and scopes it to a sandbox endpoint, which is clearly distinct from immediate-read siblings like list_requests and get_request. It stops short of naming an alternative or clarifying how it differs from wait_for_connection.
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?
There is no when-to-use guidance, no statement of prerequisites (e.g. an existing endpoint), and no mention of the alternative of polling list_requests. The usage context is left entirely to inference from the verb 'wait'.
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.
v1.6.0connect_account1 field changedInput schema / properties / email / descriptionPrevious value: -"The human's email address; only someone signed in as it can connect"New value: +"The email the human signs in to webhooks.cc with (their GitHub or Google primary email if they sign in that way); only someone signed in as it can connect"v1.5.0create_endpoint11 fields changedInput schema / properties / mockResponse / properties / body / descriptionPrevious value: -"Response body string (default: empty)"New value: +"Response body (default: empty). {{ placeholders }} are filled in from the request: {{ json.id }} (a JSON or form body field), {{ body }}, {{ headers.user-agent }}, {{ query.page }}, {{ method }}, {{ path }}, {{ id }}, {{ uuid }}, {{ now }}; filters: | default: \"x\", | json, | lower, | upper, | truncate: 80"Input schema / properties / mockResponse / properties / headers / descriptionPrevious value: -"Response headers (default: none)"New value: +"Response headers (default: none); values may use {{ placeholders }} too"Input schema / properties / responseRules / items / properties / conditions / items / properties / field / descriptionPrevious value: -"Request field to match against"New value: +"What to read: method, path, header (name), query (name), body (text), body_path (path into a JSON or form body), content_type, size"Input schema / properties / responseRules / items / properties / conditions / items / properties / field / enumPrevious value: -[
- "method",
- "path",
- "header",
- "body_contains",
- "body_path",
- "query"
-]New value: +[
+ "method",
+ "path",
+ "header",
+ "query",
+ "body",
+ "body_contains",
+ "body_path",
+ "content_type",
+ "size"
+]Input schema / properties / responseRules / items / properties / conditions / items / properties / name / descriptionPrevious value: -"Header name or query param name (required for header/query, max 256 chars)"New value: +"Header or query parameter name; the email part; spf, dkim or dmarc"Input schema / properties / responseRules / items / properties / conditions / items / properties / op / descriptionPrevious value: -"Comparison operator"New value: +"eq, neq, contains, not_contains, starts_with, ends_with, matches (glob: * one path segment, ** any, ? one character), regex (RE2, searched anywhere; (?i) ignores case), exists, not_exists, gt, gte, lt, lte (numbers)"Input schema / properties / responseRules / items / properties / conditions / items / properties / op / enumPrevious value: -[
- "eq",
- "contains",
- "starts_with",
- "matches",
- "exists"
-]New value: +[
+ "eq",
+ "neq",
+ "contains",
+ "not_contains",
+ "starts_with",
+ "ends_with",
+ "matches",
+ "regex",
+ "exists",
+ "not_exists",
+ "gt",
+ "gte",
+ "lt",
+ "lte"
+]Input schema / properties / responseRules / items / properties / conditions / items / properties / path / descriptionPrevious value: -"JSON dot-notation path (required for body_path, max 256 chars)"New value: +"Dot path for body_path, e.g. data.object.status or items.0.sku or a[\"odd.key\"]"Input schema / properties / responseRules / items / properties / conditions / items / properties / value / descriptionPrevious value: -"Value to compare against (required unless op is \"exists\", max 4096 chars)"New value: +"What to compare with (not for exists and not_exists)"Input schema / properties / responseRules / items / properties / response / properties / body / descriptionPrevious value: -"Response body string (default: empty)"New value: +"Response body (default: empty). {{ placeholders }} are filled in from the request: {{ json.id }} (a JSON or form body field), {{ body }}, {{ headers.user-agent }}, {{ query.page }}, {{ method }}, {{ path }}, {{ id }}, {{ uuid }}, {{ now }}; filters: | default: \"x\", | json, | lower, | upper, | truncate: 80"Input schema / properties / responseRules / items / properties / response / properties / headers / descriptionPrevious value: -"Response headers (default: none)"New value: +"Response headers (default: none); values may use {{ placeholders }} too"generate_payload_schemav0.1.0about_sandboxconnect_accountcreate_endpointdelete_endpointget_endpointget_requestlist_endpointslist_requestswait_for_connectionwait_for_requestScored across 11 tools
Each tool maps to a distinct resource and action: endpoint CRUD, request retrieval, and account connection are cleanly separated. The two wait tools (wait_for_connection vs wait_for_request) and the account/sandbox split could momentarily confuse, but descriptions make the boundaries explicit.
Nearly all tools follow a clear verb_noun pattern (create_endpoint, list_requests, get_request, delete_endpoint, generate_payload_schema). The lone exception is about_sandbox, which is a noun-style informational tool rather than verb_noun.
Eleven tools is well-scoped for a webhook capture service: sandbox lifecycle, request inspection, schema generation, and account onboarding each have dedicated tools. about_sandbox is arguably redundant with descriptions but is harmless and explicitly offline.
Endpoint lifecycle (create/list/get/delete) and request inspection (list/get/wait) are fully covered, plus schema generation and an account upgrade path. Minor gaps: no per-request deletion or endpoint update/config tools within the sandbox surface, though those appear to require an account.
Webhook capture bins for agents: get a URL, wait for webhooks, set replies, verify signatures.
Webhook URLs for AI agents: receive, wait for, replay, sign and verify webhooks (Stripe, GitHub…).
Webhook, email, WebSocket and tunnel testing for AI agents: capture, wait, verify, replay.
Webhooks for AI agents: send events, manage endpoints, inspect and retry deliveries.
