Skip to main content
Glama
ShieldLabs-ai

@shieldlabs-ai/mcp

Official

Verify webhook signature

shieldlabs_verify_webhook_signature
Read-onlyIdempotent

Validate a received webhook by matching its X-Shield-Signature against the raw body and signing secret, and identify common body changes causing mismatches.

Instructions

Check a received ShieldLabs webhook delivery: does its X-Shield-Signature header match the raw body for the endpoint signing secret? For debugging a webhook endpoint. SHIELDLABS_WEBHOOK_SECRET is not set on this server, so pass secret.

The signature is "sha256=" plus the lowercase hex HMAC-SHA256 of the raw body, keyed with the full signing secret including its whsec_ prefix. While a secret is rotated, give several secrets separated by commas (in secret or in SHIELDLABS_WEBHOOK_SECRET): the delivery is valid when any of them matches, and matched_secret tells which. When the signature does not match a body of up to 64 KB, the tool tests common body changes (re-serialized JSON, unescaped characters, added newline) and says which one explains the mismatch. It never returns a secret or an expected signature.

Args:

  • payload (string): raw body exactly as received

  • signature_header (string): value of X-Shield-Signature

  • secret (string, optional): whsec_... signing secret of the endpoint, or several separated by commas

  • payload_encoding ('utf8' | 'base64'): default 'utf8'

  • response_format ('markdown' | 'json'): default 'markdown'

Returns (json): { "valid": boolean, "secret_source": "argument" | "environment", "secrets_checked": number, "matched_secret": number | null, "checks": [{ check, ok, detail }], "event": { event_type, schema_version, created_at, request_id, risk_score, risk_band } | null, "hint": string | null }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
secretNoEndpoint signing secret including its whsec_ prefix, or several separated by commas while you rotate. Defaults to SHIELDLABS_WEBHOOK_SECRET from the server environment.
payloadYesThe raw request body exactly as received: the bytes that were signed. Do not pretty-print, re-serialize or trim it.
response_formatNoOutput format: 'markdown' (default) for readable text, 'json' for structured datamarkdown
payload_encodingNo'utf8' (default) when payload is the body text; 'base64' when payload is the body bytes encoded as base64 (use it when exact bytes such as a trailing newline matter)utf8
signature_headerYesValue of the X-Shield-Signature header, for example "sha256=ea26857...fdd8"

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintYes
eventYes
validYes
checksYes
secret_sourceYes
matched_secretYesPosition, from 1, of the secret that matches, in the order given; null when none
secrets_checkedYesHow many signing secrets were checked (several while a secret is rotated)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only/idempotent/non-destructive annotations, the description discloses a security guarantee ('never returns a secret or an expected signature'), the 64 KB size boundary and the fallback diagnostic of testing common body mutations when a signature mismatches. It also surfaces the deployment-specific fact that SHIELDLABS_WEBHOOK_SECRET is unset on this server, forcing the caller to pass secret.

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?

Purpose and scoping come first, then the signature/rotation semantics, then args and return shape — well front-loaded and dense. It is on the long side and the Args/Returns blocks partly restate the schema and output schema, which is mild redundancy but also serves as a quick reference.

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 five-parameter verification tool with an output schema present, the description covers the environment prerequisite, signing algorithm, rotation handling, mismatch diagnostics, and privacy guarantees. Nothing an agent needs in order to call it correctly is missing.

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%, so the baseline is 3, but the description adds real semantic content: the signature format is 'sha256=' plus lowercase hex HMAC-SHA256 keyed with the full secret including the whsec_ prefix, and multiple secrets are comma-separated with matched_secret reporting which one hit. These are interaction details the per-parameter schema text does not fully convey.

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 states a specific verb and resource — check whether a received ShieldLabs webhook delivery's X-Shield-Signature header matches the raw body for the endpoint's signing secret. No sibling tool (identification, search history, summarize entity, explain risk score, current time) overlaps with signature verification, so no sibling disambiguation is required.

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 states the context explicitly — 'For debugging a webhook endpoint' — and then covers the rotation scenario where multiple comma-separated secrets should be supplied. There is no explicit when-not guidance, but the tool's scope is narrow enough that no plausible alternative exists among the siblings.

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