Skip to main content
Glama

verify_webhook

Read-onlyIdempotent

Verify a webhook's HMAC-SHA256 signature locally and return a valid/invalid verdict to confirm the payload is authentic before trusting payment events.

Instructions

Check a webhook's HMAC-SHA256 signature and return only a valid/invalid answer.

Prefer `parse_webhook` for an incoming delivery — it verifies the signature *and*
extracts the payment status, event ID and a paid/not-paid verdict in one call.
Reach for this tool only when the boolean alone is what you need.

Runs locally; makes no network call. Treat a `valid: false` result as an attack
or a misconfiguration and ignore the payload — an unverified "payment complete"
event is exactly how someone gets a book without paying.

Pass the body exactly as received; the digest covers the raw request bytes, so
re-serialising the JSON breaks it. Secrets are per link, not per account. This
errors instead of answering when no signature or secret is available, or when the
secret falls outside Wayl's 10-255 characters — one that short cannot have signed
a real delivery.

`valid: true` does not mean the event is new. There is no timestamp or nonce, so a
captured delivery verifies forever. Deduplicate on the payload's `id`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
secretNoThe webhookSecret for this link. Defaults to WAYL_WEBHOOK_SECRET.
headersNoThe webhook's request headers. The signature header is found automatically, so you can pass the whole map instead of extracting it.
raw_bodyYesThe webhook request body exactly as received, byte for byte. Do not reformat or re-serialise it — that changes the signature.
signatureNoSignature from the webhook's signature header. Omit if you pass `headers` instead.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Beyond the readOnly/idempotent hints, the description discloses key behaviors: errors on missing signature/secret or out-of-range secret, no timestamp/nonce (so valid:true does not imply freshness), and instructs to treat invalid as an attack. It adds security-critical context without contradicting 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 organized into tight paragraphs, front-loading the core purpose and then layering context. Every sentence adds value, covering usage, failure modes, and security caveats without redundant fluff.

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?

The tool is security-sensitive and the description covers all essential context: what it verifies, when to use it, what invalid means, how to pass the body, error conditions, and idempotency/deduplication guidance. The output schema exists, so return values need no extra explanation.

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 100% and parameter descriptions already explain each field. The tool description complements by reinforcing raw_body must be byte-for-byte, headers can be passed whole because signature is auto-found, and secrets are per link. This adds practical nuance beyond the schema.

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 opens with 'Check a webhook's HMAC-SHA256 signature and return only a valid/invalid answer', using a specific verb and resource, and explicitly names the sibling 'parse_webhook' as an alternative that does more. This fully distinguishes the tool from its siblings.

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

Usage Guidelines5/5

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

The description gives explicit guidance: 'Prefer parse_webhook for an incoming delivery' and 'Reach for this tool only when the boolean alone is what you need.' It also notes the tool runs locally with no network call, providing clear contextual usage direction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/muthanii/waylMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server