WebhookTest.net

Configure webhook response

configure_webhook_response

Set the status, content type, body, safe response headers, and a delay up to 10 seconds returned by the webhook endpoint.

Input Schema

TableJSON Schema

Name	Required	Description
`body`	Yes
`status`	Yes
`headers`	No	optional response headers; server-managed and hop-by-hop headers are rejected
`delay_ms`	No	response delay in milliseconds, from 0 to 10000
`bucket_id`	Yes
`content_type`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`success`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedAug 3, 2026

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"
+}

First observedAug 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations include idempotentHint=false, which the description aligns with (configuration implies state change). The description adds useful constraints not in annotations: the delay cap of 10 seconds and that only 'safe' response headers are allowed. It correctly omits 'up to 10 seconds' being misleading since the schema already encodes the 0-10000ms range.

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?

A single well-structured sentence that front-loads the purpose and enumerates all configurable attributes in one breath. Zero wasted words; every element conveys meaning about what the tool does.

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 this tool has an output schema to explain return values, and annotations clarify it is non-read-only and non-idempotent, the description covers the primary behavioral contract well. The main gap is that the description does not mention required bucket_id context or note the scheduling/immediate-return nature, but the output schema and annotations fill most of the remaining space.

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?

Schema coverage is only 33%, so the description partially compensates by enumerating the key fields (status, content type, body, headers, delay) that map to the parameters. However, it does not clarify the body format (string is self-evident) or how delay_ms relates to the 10-second cap. The description adds field-level context that the schema lacks for some parameters, though headers and delay_ms already have 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 uses a specific verb ('Set') with a clear resource ('the webhook endpoint') and enumerates exactly what aspects can be configured: status, content type, body, safe response headers, and delay. This clearly differentiates it from sibling tools which handle creation, deletion, listing, and waiting operations.

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 is for configuring the response returned by an existing webhook endpoint, which provides some usage context. However, it does not explicitly state when to use this vs alternatives, nor does it mention any prerequisites (e.g., that a bucket/webhook must exist first) or exclusions.

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

All WebhookTest.net tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Tools are mostly distinct: bucket lifecycle (create/delete/get/list/clear), response configuration, and webhook capture reading (get/list/wait) each target clear operations. There is minor potential confusion between get_webhook_bucket (bucket settings) and get_webhook (a capture), and clear_webhooks vs delete_webhook_bucket both involve deletion, but descriptions differentiate them adequately.

Naming Consistency4/5

Tools follow a consistent verb_noun pattern (create/delete/get/list/clear/configure/wait_for + webhook bucket or webhook). The pattern is mostly uniform snake_case with predictable verbs, though wait_for_webhook and configure_webhook_response deviate slightly from the simple get/list/create/delete set, and the 'webhooks' vs 'webhook_bucket' noun variation is somewhat mixed.

Tool Count5/5

Eight tools is well within the ideal 3-15 range and every tool serves a distinct, meaningful purpose for a webhook testing service. The surface covers capture, bucket lifecycle, response configuration, and polling without redundancy or bloat.

Completeness4/5

The surface covers the full lifecycle: create/get/delete buckets, clear captures, configure responses, read/list/wait for captures. The main gap is an absent update capture or redaction toggle operation, but the core workflows for testing webhooks—configure, capture, inspect—are fully covered.

Resources

Need Help?