Skip to main content
Glama

Webhook Studio

by com.webhook-studio

configure_verification

Turn on HMAC signature verification for a bucket using the provider's own signing secret (e.g. Stripe's whsec_). This is how you finish a "verified webhook" integration end to end. Set secret to the provider secret and hmac_enabled:true in the same call; the signature scheme is auto-detected from the header shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
secretNoThe provider's signing secret (≥16 chars).
bucket_idYesThe endpoint id.
on_failureNoWhat to do with a failed signature.
header_nameNoSignature header to read (auto-detected if omitted).
hmac_enabledNoEnable verification.
tolerance_secondsNoMax timestamp skew allowed, in seconds.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are present, so the description must disclose behaviors itself. It explains the need to set secret and hmac_enabled:true in the same call and that signature scheme auto-detects from header shape, adding meaningful behavior beyond the schema. It doesn't detail permissions or effects on existing settings, but the core mutation behavior is sufficiently described.

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 front-load the primary action and provide essential integration context without repetition. 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?

For a configuration tool with no annotations and no output schema, the description covers the main purpose, the critical coupling of secret with hmac_enabled, and auto-detection behavior. It omits details about on_failure/tolerance_seconds, but those are already explained in the schema, so the description is suitably complete for its complexity.

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?

The schema already documents all 6 parameters with descriptions (100% coverage), so the baseline is 3. The description enriches the meaning of hmac_enabled and header_name by revealing they work together and auto-detection behavior, pushing it to a 4.

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 tool's function with a specific verb ('Turn on') and resource ('HMAC signature verification for a bucket'), and the phrase 'finish a verified webhook integration' distinguishes it from sibling bucket management tools like create_bucket or delete_bucket.

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

Usage Guidelines4/5

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

It provides context that this is the final step in a verified webhook integration, which implies it should be used after bucket creation and webhook setup. However, it does not explicitly list alternative tools or exclusions, so it earns a 4 rather than 5.

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

All Webhook Studio toolsInspect
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

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: buckets, events, schemas, deliveries, forwarding, verification, replay, and waiting. Even similar pairs like latest_event vs list_events are clearly differentiated by purpose, with no overlapping responsibilities.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern with underscores, such as create_bucket, list_events, and delete_bucket. The only slight deviation is 'latest_event', which uses an adjective instead of a verb, but it remains intuitive and does not disrupt the overall predictability.

Tool Count4/5

At 17 tools, the set is slightly above the typical well-scoped range of 3-15, but the domain covers buckets, events, schemas, deliveries, configuration, and more, so each tool serves a distinct and justified purpose. The count feels appropriate for the platform's breadth rather than excessive.

Completeness3/5

The set covers the primary lifecycle for buckets, events, and schemas, including create, read, list, and delete operations. However, there is no way to update or delete a forwarding rule after creation, and no explicit update operation for bucket metadata, leaving notable gaps in managing configurations.

Resources