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 | shThen 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, 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 11 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 human's email address; only someone signed in as it can connect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does well: it discloses the human-mediated auth flow, that a link plus 6-digit code is returned, that the human must sign in or sign up with that email, and the idempotency-ish behavior of repeat calls. It does not mention code expiry or failure modes when the email doesn't match, leaving a small gap.
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 tight sentences with the purpose front-loaded, followed by the return shape and the follow-up step. The parenthetical capability list adds concrete value rather than filler; 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?
With no annotations and no output schema, the description adequately covers what is returned and what the agent must do next. It only omits edge cases such as code expiry, mismatched email, or what state the sandbox endpoints are restored to.
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?
Only one parameter, and schema description coverage is 100% with the schema already explaining the sign-in constraint. The description adds that the human may 'sign in or sign up' with the email, giving a bit of meaning beyond the schema, but the schema does the bulk of the work (baseline 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?
States a specific verb and resource ('Connect this agent to a human's webhooks.cc account') and immediately names the benefit (full tool set, keeping sandbox endpoints), which no sibling tool does. An agent can distinguish this entry-point tool from the endpoint/request siblings purely from the text.
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?
Spells out the full operating sequence: show link and code to the human, then call wait_for_connection. It also names the sibling to invoke next and discloses re-invocation behavior ('Calling again gives a new code'), leaving nothing to inference.
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 behavioral burden and delivers: quota limits (3 endpoints, 25 requests each, 100 total), lifecycle (deleted 24h after sandbox creation), latency (first call does proof of work, a few seconds), and account prerequisites. These are exactly the non-obvious traits an agent needs before calling.
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, both dense with information and no filler. Purpose is front-loaded, followed by limits, lifecycle, latency, and the account routing clause, in that priority order.
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?
Covers lifecycle, quotas, latency, and prerequisites for a complex 9-parameter nested-schema tool, which is strong. The one notable gap is that no output schema exists and the description never says what is returned (e.g. the capture URL), which an agent needs to actually use the endpoint.
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 the baseline is 3, but the description adds meaning beyond the schema by tying mock responses, notifications, and signature verification to an account requirement, which constrains mockResponse, notificationUrl, signingProvider, and signingSecret. It does not enumerate individual params, but the added constraint is real.
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 in the agent sandbox") and scopes it precisely as an account-free sandbox operation, which separates it from connect_account and the read/manage siblings. An agent can tell what this tool produces 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 clear when-to-use context (no account needed, temporary sandbox capture) and routes account-dependent features (mock responses, notifications, signature verification) explicitly to connect_account. It stops short of contrasting against the other siblings like list_endpoints or wait_for_request, but the primary alternative is named.
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.
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.
v0.1.0about_sandboxconnect_accountcreate_endpointdelete_endpointget_endpointget_requestlist_endpointslist_requestswait_for_connectionwait_for_requestScored across 10 tools
Each tool targets a distinct resource+action: endpoint CRUD, request capture reads, arrival-waiting, and the account-connection flow are all clearly separated. The two connection tools (connect_account vs wait_for_connection) and the info tool (about_sandbox) are distinguishable by their verbs and descriptions.
Names follow a consistent snake_case verb_noun pattern (create_endpoint, list_requests, get_request, delete_endpoint, connect_account). The only minor deviation is about_sandbox, which uses a noun-style prefix rather than a verb, but it remains readable and predictable.
Ten tools is well-scoped for a webhook-capture sandbox: four endpoint operations, three request operations, two account-flow steps, and one informational tool. Each tool earns its place without redundancy.
Endpoint lifecycle (create/list/get/delete) and request reading (list/get/wait) are fully covered, plus the account-upgrade path. Minor gaps exist (no endpoint update/rename and no explicit per-request deletion or clear-all), but core capture workflows are complete.
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.
