Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.3/5.
Tools are mostly distinct with clear resource types: bucket operations vs. webhook capture operations. Slight overlap between get_webhook and wait_for_webhook (both retrieve captures) and between clear_webhooks and delete_webhook_bucket (both delete), but descriptions clarify the differences.
All tool names follow a consistent verb_noun pattern with lowercase snake_case. The resource prefix 'webhook' is used uniformly, making the API predictable and easy to navigate.
8 tools is well within the ideal 3-15 range and perfectly scoped for a webhook testing service. Each tool serves a necessary function in the bucket/capture lifecycle.
Core workflow is covered: create/delete bucket, configure response, list/get/wait/clear captures. Minor gaps like per-capture deletion or bucket update/rename, but these are non-essential for the domain.
clear_webhooksClear captured webhooksAPermanently delete every capture in a bucket. Requires confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | must be true to perform this destructive action | |
| bucket_id | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| success | No |
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.
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.
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.
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.
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.
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 responseBInspectSet the status, content type, and body returned by the webhook endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| status | Yes | ||
| bucket_id | Yes | ||
| content_type | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| success | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no meaningful safety or behavioral hints. The description discloses only that it sets response fields, but omits side effects, such as whether this overwrites an existing configuration, requires an existing bucket, or affects live endpoints. No additional behavioral context like error handling or persistence is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that begins with the actionable verb 'Set' and lists the affected fields. It contains no redundant information and 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?
For a tool with four required parameters and no parameter descriptions, the description is minimal. It explains what the tool does but does not convey prerequisites (e.g., existing bucket), the effect of calling it multiple times, or the significance of bucket_id. The presence of an output schema reduces the need to describe return values, but the overall context is still sparse for an AI agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description clarifies the meaning of three parameters (status, content_type, body) by tying them to the webhook response. However, bucket_id is not explained in the description or schema, leaving its role implicit, and no values or constraints are given for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Set' with the resource 'status, content type, and body returned by the webhook endpoint,' clearly identifying it as a configuration/mutation tool. This distinguishes it from sibling tools like create_webhook_bucket, get_webhook, delete_webhook_bucket, which serve different lifecycle operations.
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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring an existing bucket, or when to choose this over create/delete/get. The use case is only implied by the tool name and the phrase 'the webhook endpoint,' but no explicit context 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.
create_webhook_bucketCreate webhook bucketAInspectCreate an anonymous temporary webhook capture bucket. The returned bucket ID is a bearer capability and expires after 15 days of inactivity.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | optional display name for the bucket |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| error | No | |
| dashboard_url | No | |
| webhook_endpoint | No | |
| inactivity_policy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations (all false), the description discloses key behavioral traits: anonymity, temporariness, a bearer capability ID, and expiry after 15 days of inactivity. This adds important security 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes essential behavioral notes (bearer capability, expiry) without unnecessary elaboration. 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?
For a simple creation tool with one optional parameter and an output schema, the description fully covers purpose, identity of the returned ID, and lifecycle. The output schema handles return value details, so no critical information 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?
The only parameter, 'name', is fully documented in the schema with 'optional display name for the bucket'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies due to high schema coverage.
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 starts with 'Create an anonymous temporary webhook capture bucket,' which is a specific verb and resource. It clearly distinguishes from sibling tools like delete_webhook_bucket, list_webhooks, etc., by indicating creation of a temporary capture bucket.
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 makes it clear the tool is for creating a bucket to capture webhooks, providing context for when it would be used. It does not explicitly mention exclusions or alternatives, but the unambiguous create action and detailed resource type give sufficient guidance.
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 bucketAPermanently delete a bucket and all of its captures. Requires confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | must be true to perform this destructive action | |
| bucket_id | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| success | No |
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.
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.
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.
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.
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.
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 webhookARead one webhook capture scoped to its bucket. Sensitive headers and query values are redacted by default.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| error | No | |
| webhook | No |
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.
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.
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.
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.
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.
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 bucketARead a bucket name and its configured HTTP response settings.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket_id | Yes | bucket capability ID |
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| error | No | |
| dashboard_url | No | |
| response_body | No | |
| response_status | No | |
| webhook_endpoint | No | |
| response_content_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=false, and the description aligns by stating 'Read'. It adds minimal context by specifying the returned fields (name and HTTP settings), but does not disclose additional behavioral traits like error conditions or permissions. Since annotations cover the read-only nature, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that starts with the action verb 'Read' and clearly states the resource and data returned. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter), existing output schema, and annotations, the description sufficiently covers the tool's purpose. It could optionally mention prerequisites or errors, but the current level is adequate for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents bucket_id as a required string with description 'bucket capability ID'. The description adds no additional parameter semantics, so it relies on the schema's 100% coverage.
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 uses the verb 'Read' to specify a get operation on a bucket resource, clarifying it retrieves the bucket name and HTTP response settings. This distinguishes it from sibling tools like create/delete/configure related to buckets or webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading bucket configuration but does not explicitly state when to prefer this over get_webhook or list_webhooks. No alternatives are mentioned, so it only provides implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_webhooksList captured webhooksAList webhook capture summaries in newest-first order using cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | number of summaries to return, from 1 to 50 | |
| cursor | No | opaque cursor returned by a previous call | |
| bucket_id | Yes |
| Name | Required | Description |
|---|---|---|
| error | No | |
| has_more | No | |
| webhooks | No | |
| next_cursor | No | |
| dashboard_url | No |
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.
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.
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.
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.
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.
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 webhookAReturn the latest capture, wait for a newer capture, or report received=false after the timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| error | No | |
| webhook | No | |
| received | Yes |
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.
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.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
