WebhookTest.net

Server Details

Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 47 days
Last Tested: 2026-10-03 14:10
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-29 05:05 across 8 tools

Disambiguation4/5

Most tools have clearly distinct purposes, but there is mild potential for confusion between clear_webhooks (wipes captures) and delete_webhook_bucket (removes the bucket), and between get_webhook, list_webhooks, and wait_for_webhook. Descriptions largely resolve these boundaries, so an agent can select correctly with care.

Naming Consistency4/5

All names follow a consistent snake_case verb_noun pattern (create/get/delete/get_webhook_bucket, get/list/wait_for_webhook). The only slight wart is that captures are referred to as 'webhooks' while the container is 'webhook_bucket', a minor inconsistency in entity modeling.

Tool Count5/5

Eight tools is well-scoped for a webhook capture service, covering bucket lifecycle, capture retrieval, response configuration, and cleanup without redundancy. Each tool earns its place.

Completeness4/5

Covers bucket create/delete/read, capture get/list/clear, response configuration, and a wait primitive—nearly a full lifecycle. The main gap is the inability to delete or manage a single capture individually (only clear_webhooks for all captures).

Available Tools

8 tools

clear_webhooksClear captured webhooksA

Destructive

Inspect

Permanently delete every capture in a bucket. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	must be true to perform this destructive action
`bucket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`success`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as destructive, so the description adds value by emphasizing 'Permanently delete' and requiring confirm=true, which clarifies the irreversible nature. This goes beyond the structured annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action and effect. Every word adds value; no filler or redundant information. It is highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations, the description adequately covers the core behavior (permanent deletion, confirm flag). It does not mention permissions or edge cases, but for a destructive clear operation with structured data present, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only confirm is described). The description reinforces the confirm parameter's behavior ('Requires confirm=true') but does not clarify bucket_id. It partially compensates for the missing schema description but leaves one parameter without additional context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('delete') and resource ('every capture in a bucket'), clearly distinguishing it from sibling tools like delete_webhook_bucket. It also states the requirement of confirm=true, adding precise scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for clearing all captures in a bucket but does not explicitly state when to use this tool versus alternatives like delete_webhook_bucket. There is no exclusion or alternative guidance, so it remains at implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

configure_webhook_responseConfigure webhook responseAInspect

Set the status, content type (JSON, plain text, XML, or form-encoded), body, optional Retry-After or X-Hook-Secret header, and a delay up to 10 seconds returned by the webhook endpoint. Browser visits always receive plain text.

ParametersJSON Schema

Name	Required	Description
`body`	Yes
`status`	Yes
`headers`	No	optional response headers; only Retry-After and X-Hook-Secret are supported, matched case-insensitively
`delay_ms`	No	response delay in milliseconds, from 0 to 10000
`bucket_id`	Yes
`content_type`	Yes	application/json, text/plain, application/xml, text/xml, application/soap+xml, application/problem+xml, application/x-www-form-urlencoded, or application/*+json; only a charset parameter is allowed; empty selects application/json

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`success`	No

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (non-readonly, non-destructive, non-idempotent, closed-world), and the description adds real behavioral constraints beyond them: a 10-second delay cap, only Retry-After/X-Hook-Secret headers being honored, and the override that browser visits always get plain text. It still omits permissions/scope needed and whether the configuration replaces all prior settings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and packed with relevant detail in one dense sentence plus a short qualifier about browser visits. No filler, though the first sentence is long and could be scannable if split.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, and the description covers the behavioral edge cases (header whitelist, delay limit, browser fallback) for a mutation tool. It is slightly short on operational context such as auth requirements and the scope/lifetime of the configured response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 50% schema description coverage, the description compensates by naming status, content type (with the JSON/plain text/XML/form-encoded families), body, headers, and the delay bound, matching five of the six parameters. Only bucket_id is left implicit, and the description restates the schema's 10s cap consistent with delay_ms's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (Set) plus the exact resource being configured (the response returned by a webhook endpoint), with the settable fields enumerated. It does not explicitly name or contrast any sibling tool, so an agent must infer that this configures a response rather than managing the bucket/webhook itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus alternatives such as create_webhook_bucket or wait_for_webhook, and no stated prerequisites (e.g., that a bucket must already exist). Usage is only implied by the phrase 'returned by the webhook endpoint'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_webhook_bucketCreate webhook bucketAInspect

Create an anonymous temporary webhook capture bucket. The returned bucket ID is a bearer capability and expires after 15 days of inactivity.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	optional display name for the bucket
`controlled_test`	No	set true only for maintainer QA or automated evaluations; not for a real user's first test

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	No
`name`	No
`error`	No
`dashboard_url`	No
`webhook_endpoint`	No
`inactivity_policy`	No

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that the returned bucket ID is a bearer capability and that the bucket expires after 15 days of inactivity. This adds meaningful auth and lifecycle context that annotations do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The main behavior is front-loaded, and the security/expiry caveat is stated immediately after.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple create operation with two optional parameters and an output schema, the description covers the essential semantics: anonymous creation, temporary nature, bearer capability, and expiry. Nothing needed for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already fully documented. The tool description adds no additional parameter-level meaning, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Create an anonymous temporary webhook capture bucket.' It clearly distinguishes itself from sibling get/list/delete/clear operations by focusing on creation of a new bucket.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the appropriate use case through 'anonymous temporary webhook capture bucket', but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. Sibling tools are not referenced for routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_webhook_bucketDelete webhook bucketA

Destructive

Inspect

Permanently delete a bucket and all of its captures. Requires confirm=true.

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	Yes	must be true to perform this destructive action
`bucket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`success`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, but the description adds context by stating 'Permanently delete' and 'all of its captures', which clarifies the irreversibility and scope. It also reinforces the confirm=true requirement, which is useful beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the core action and includes the key requirement (confirm=true). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the operation and the presence of an output schema and annotations, the description covers the essential behavior. It could mention potential failure modes or prerequisites, but for a straightforward delete tool it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (confirm has a description, bucket_id does not). The description adds meaning for confirm by stating 'Requires confirm=true', but it does not explain bucket_id. This partially compensates for the missing schema description but leaves one parameter underexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete), the resource (bucket), and the scope (all captures), which distinguishes it from sibling tools like create_webhook_bucket or list_webhooks. The verb 'delete' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly mention when to use this tool versus alternatives like clear_webhooks. However, the purpose is clear enough that an agent can infer this is for permanent deletion, but no exclusions or alternative guidance are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_webhookGet captured webhookA

Read-only

Inspect

Read one webhook capture scoped to its bucket. Sensitive headers and query values are redacted by default.

ParametersJSON Schema

Name	Required	Description
`bucket_id`	Yes
`webhook_id`	Yes
`max_body_bytes`	No	maximum body bytes to return; defaults to 65536 and cannot exceed 262144
`include_sensitive`	No	return sensitive header and query values; defaults to false

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`webhook`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that sensitive headers and query values are redacted by default, which adds behavioral context beyond the readOnlyHint annotation. It does not mention that include_sensitive can override this, but the schema covers that. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loading the main action and adding a critical redaction detail. Every word earns its place; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only single-get tool with an output schema, the description covers the essential purpose and a notable behavior (redaction). It omits details like the max_body_bytes limit or how to request sensitive values, but those are in the schema, so the description is sufficiently complete for an agent to select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides descriptions for max_body_bytes and include_sensitive (50% coverage). The description adds context that the webhook is 'scoped to its bucket,' helping clarify bucket_id, but webhook_id remains undocumented in both description and schema. It does not compensate fully for the missing required parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Read' with a clear object: 'one webhook capture scoped to its bucket.' It distinguishes from sibling tools like list_webhooks by indicating single-item retrieval and mentions the redaction behavior, making the purpose explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for reading a specific webhook capture within a bucket, but it does not explicitly contrast it with alternatives like list_webhooks or wait_for_webhook, nor does it state when to use one over the other. The usage context is somewhat obvious from the verb, but no explicit guidance or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_webhook_bucketGet webhook bucketA

Read-only

Inspect

Read a bucket name and its configured HTTP response settings.

ParametersJSON Schema

Name	Required	Description	Default
`bucket_id`	Yes	bucket capability ID

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	No
`name`	No
`error`	No
`dashboard_url`	No
`response_body`	No
`response_status`	No
`response_headers`	No
`webhook_endpoint`	No
`response_delay_ms`	No
`response_content_type`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, so the agent knows this is a safe read. The description adds a small detail (returns bucket name and HTTP response settings) but doesn't describe the response format, whether it returns all settings or a subset, or whether the bucket must exist. With readOnlyHint present, the bar is lower, and the description adds modest context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with zero wasted words. It clearly communicates the action and what is read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, annotations declaring read-only safety, and 100% schema parameter coverage, the tool is well-covered. The description supplements by naming what is read (bucket name + HTTP response settings). For a simple single-parameter read tool, this is reasonably complete, though it could clarify what the 'HTTP response settings' encompass.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% ('bucket capability ID' documents bucket_id fully). With 100% coverage and only 1 simple parameter, the baseline 3 applies. The description adds essentially no param-specific detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Read a bucket name and its configured HTTP response settings' with a specific verb (Read) and resource (bucket), clearly distinguishing it from siblings like create/delete/configure_webhook_response. It doesn't fully differentiate from get_webhook (which may be a related but distinct resource), but the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it's a read operation for a single bucket identified by bucket_id, which gives a sense of when to use it. However, it doesn't explicitly mention alternatives (e.g., list_webhooks for enumeration or clear_webhooks for a different action), nor any prerequisites or context about when this tool is preferred over get_webhook.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_webhooksList captured webhooksA

Read-only

Inspect

List webhook capture summaries in newest-first order using cursor pagination.

ParametersJSON Schema

Name	Required	Description
`limit`	No	number of summaries to return, from 1 to 50
`cursor`	No	opaque cursor returned by a previous call
`bucket_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`has_more`	No
`webhooks`	No
`next_cursor`	No
`dashboard_url`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true, and the description adds value by specifying newest-first ordering and cursor pagination behavior. It also calls out 'summaries', implying the payload differs from full webhook details, which is useful context beyond metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the key action and adds relevant details about ordering and pagination without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations, the description adequately covers the tool's purpose, ordering, and pagination. It could mention use cases relative to siblings but is sufficiently complete for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% (limit and cursor have descriptions, bucket_id does not). The tool description does not further explain bucket_id or add semantics beyond the schema's existing descriptions, so it does not significantly compensate for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'webhook capture summaries', with ordering (newest-first) and pagination method. This distinguishes it from siblings like get_webhook (single webhook) and clear_webhooks (clearing captures).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates this is for listing summaries, but it does not explicitly mention alternatives or exclusion cases. Sibling tools like get_webhook could be used for individual details, but the description does not point to this, leaving some ambiguity about when to use which.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wait_for_webhookWait for a webhookA

Read-only

Inspect

Return the latest capture, wait for a newer capture, or report received=false after the timeout.

ParametersJSON Schema

Name	Required	Description
`bucket_id`	Yes
`wait_seconds`	No	seconds to wait; defaults to 20 and cannot exceed 25
`max_body_bytes`	No
`after_webhook_id`	No	wait for a capture newer than this webhook ID
`include_sensitive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No
`webhook`	No
`received`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation readOnlyHint=true already establishes safety, and the description adds valuable behavioral context about blocking until a newer capture arrives and reporting received=false after timeout. This extra detail about the polling behavior goes beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that front-loads the core behavior and contains no filler or redundant information. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description sufficiently covers the main execution flow (return latest, wait for newer, or false after timeout) and is complemented by an output schema. It does not elaborate on all parameter interactions, but the core behavior is clear enough for a waiting tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40%, and the tool description provides no additional parameter explanations. Fields like max_body_bytes and include_sensitive are left undescribed, while wait_seconds and after_webhook_id rely solely on their schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's behavior: returning the latest capture, waiting for a newer capture, or reporting received=false after timeout. This distinctively separates it from sibling tools focused on managing buckets or retrieving individual webhooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for waiting on webhook captures, but it does not explicitly state when to use this tool versus alternatives like get_webhook or list_webhooks. No when-not-to-use conditions or prerequisites are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 29, 2026

Changedconfigure_webhook_response2 fields changed

addedInput schema / properties / content_type / description

Added value: +"application/json, text/plain, application/xml, text/xml, application/soap+xml, application/problem+xml, application/x-www-form-urlencoded, or application/*+json; only a charset parameter is allowed; empty selects application/json"

changedInput schema / properties / headers / description

Previous value: -"optional response headers; server-managed and hop-by-hop headers are rejected"New value: +"optional response headers; only Retry-After and X-Hook-Secret are supported, matched case-insensitively"

1 tool updateSep 20, 2026

Changedcreate_webhook_bucket1 field changed

addedInput schema / properties / controlled_test

Added value: +{
+  "description": "set true only for maintainer QA or automated evaluations; not for a real user's first test",
+  "type": "boolean"
+}

2 tool updatesAug 3, 2026

Changedconfigure_webhook_response2 fields changed

addedInput schema / properties / delay_ms

Added value: +{
+  "description": "response delay in milliseconds, from 0 to 10000",
+  "type": "integer"
+}

addedInput schema / properties / headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "optional response headers; server-managed and hop-by-hop headers are rejected",
+  "type": "object"
+}

Changedget_webhook_bucket2 fields changed

addedOutput schema / properties / response_delay_ms
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / response_headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

8 tool updatesAug 3, 2026
- First observedclear_webhooks
- First observedconfigure_webhook_response
- First observedcreate_webhook_bucket
- First observeddelete_webhook_bucket
- First observedget_webhook
- First observedget_webhook_bucket
- First observedlist_webhooks
- First observedwait_for_webhook

Related MCP Connectors

Hooklistener AOAuth
com.hooklistener
Webhook, email, WebSocket and tunnel testing for AI agents: capture, wait, verify, replay.
Testing & QA Tools API Testing Email
461
catchr A
dev.workers.perch-app.catchr
Instant no-signup webhook & HTTP-request inspector for testing webhooks and agent tool-callbacks.
API Testing Developer Tools
1
Webhook Toolkit A
io.github.THE-KIPDEV
Webhook URLs for AI agents: receive, wait for, replay, sign and verify webhooks (Stripe, GitHub…).
API Testing App Automation Developer Tools
101
pipehero A
io.github.pipehero
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
Developer Tools API Testing
222

Related MCP Servers

Webhook Capture MCP
API Testing Developer Tools
void-pulse
A
license
A
quality
C
maintenance
Captures incoming webhook/HTTP requests and lets AI assistants inspect, wait for, and replay them to debug webhook integrations.
Updated 2 months ago (2026-08-12 22:55 UTC)
6
MIT
hookray-mcp
Developer Tools API Testing Testing & QA Tools
ShotaTanikawa
A
license
A
quality
D
maintenance
Enables AI agents to create disposable webhook URLs, capture incoming HTTP requests, inspect headers and bodies, and replay them against local or remote endpoints, streamlining the webhook handler development loop.
Updated 5 months ago (2026-05-15 08:15 UTC)
5
9 npm
MIT
webhook-toolkit
API Testing Testing & QA Tools Developer Tools
THE-KIPDEV
A
license
Not graded
quality
C
maintenance
Enables AI agents to create webhook URLs, wait for incoming deliveries, inspect payloads, and replay or send signed webhook events to a local handler.
Updated 15 days ago (2026-09-18 14:29 UTC)
56 npm
MIT
FlurryPORT
Developer Tools Testing & QA Tools
flurryport
A
license
Not graded
quality
A
maintenance
Webhook capture and replay, delivery pipes, and signed multi-agent rooms. No signup to start.
Updated 25 days ago (2026-09-08 22:51 UTC)
196 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?