Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@webhook-verify Check if the Stripe webhook signature is valid for this raw body and header."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Timing-safe, replay-resistant webhook signature verification for Stripe, GitHub, Slack, Shopify and Twilio.
29 passedStandard library only. No dependencies, no network, no telemetry.
Webhook verification is the one piece of security code almost every backend writes itself, and it goes wrong in four predictable ways:
Mistake | Consequence |
| Byte-by-byte comparison leaks the position of the first wrong byte through timing. Forgeable given enough attempts. |
No timestamp check | A captured valid request stays valid forever. Replay it tomorrow and it still passes. |
Verifying the parsed body | You re-serialise, a key order or whitespace changes, and the HMAC no longer matches — so people "fix" it by skipping verification. |
Returning | A caller writes |
This library does the opposite of each: hmac.compare_digest everywhere, replay windows on every
provider that signs a timestamp, verification against the raw body, and a specific exception on
every failure so nothing can be accidentally treated as success.
Related MCP server: webhook-ai-mcp
from webhookverify import verify_stripe, SignatureMismatch, TimestampOutOfRange
try:
verify_stripe(secret, raw_body, request.headers["Stripe-Signature"])
except TimestampOutOfRange:
return 400, "replayed or clock-skewed"
except SignatureMismatch:
return 401, "not from Stripe"
# only now is it safe to parse raw_bodySupported: verify_stripe, verify_github, verify_slack, verify_shopify, verify_twilio,
and verify_hmac for anything else.
Stripe secret rotation is handled: a header carrying several v1= signatures passes if any one matches.
mcp/server.py exposes one tool, verify_webhook, over JSON-RPC 2.0 stdio (protocol 2024-11-05).
It returns valid:true, or valid:false with a precise reason (signature_mismatch,
timestamp_out_of_range, malformed_signature) and the instruction not to parse the payload.
{ "mcpServers": { "webhook-verify": { "command": "python3", "args": ["/path/to/webhook-verify/mcp/server.py"] } } }Valid signatures pass for all five providers
Tampered bodies, wrong secrets and truncated signatures raise SignatureMismatch
Replayed and future-dated timestamps raise TimestampOutOfRange (the window is symmetric)
Malformed headers raise MalformedSignature — missing prefix, bad base64, non-hex, non-numeric timestamp
Stripe multi-v1 rotation passes when any signature matches
A source-level guard asserts the module never regresses to == on digests and always length-checks
before compare_digest
python -m pytest tests -qMIT
Verify a webhook signature with a timing-safe comparison and, where the provider signs a timestamp, replay protection. Returns valid:true or the precise reason it failed (signature_mismatch, timestamp_out_of_range, malformed_signature). Never parse or act on a webhook body before this returns valid.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Required for twilio: the full request URL. | |
| body | No | The RAW request body, byte-identical to what was received. | |
| params | No | Required for twilio: the POST form parameters. | |
| secret | Yes | Signing secret or auth token. | |
| provider | Yes | ||
| signature | Yes | The provider's signature header value. | |
| timestamp | No | Required for slack (X-Slack-Request-Timestamp). | |
| tolerance_seconds | No | Replay window for providers that sign a timestamp. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It reveals timing-safe comparison, replay-window protection, exact return values, and a critical ordering constraint. It stops short of a 5 by not addressing exception behavior or provider-specific edge cases.
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?
Two sentences with no filler: the first states the action and return contract, the second states a vital operational warning. The most important guidance is front-loaded.
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 8 parameters, a provider enum, and no output schema, the description covers the core verification contract and return values. Provider-specific parameter requirements are left to the schema, which documents them well. It is slightly light on provider-specific behavioral combinations, hence not a 5.
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 88%, so the schema already documents most parameters. The description adds little new parameter-level detail beyond tying timestamp/tolerance to replay protection, which the schema already mentions. This meets the baseline but does not elevate it.
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 states a specific verb and resource: verifying a webhook signature with timing-safe comparison and replay protection. It also precisely defines the outcome (valid:true or exact failure reasons), leaving no ambiguity about what the tool does.
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 gives clear operational context: use this before parsing or acting on a webhook body, and replay protection applies when the provider signs a timestamp. It does not explicitly state when not to use it, but with no sibling tools, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0verify_webhookWith only a single tool, there is no possibility of confusing it with another. The tool's purpose is fully specified and self-contained, leaving no ambiguity about when to invoke it.
The tool name follows a clear verb_noun convention with snake_case, which is consistent and predictable. Even though there is only one tool, the pattern aligns with common standards and leaves no room for stylistic mismatch.
The server is purpose-built for webhook signature verification, and one focused tool is exactly the right scope. There is no unnecessary bloat, and the single tool fully addresses the server's intended functionality without feeling thin.
The tool covers the entire lifecycle of webhook verification: timing-safe comparison, replay protection, and detailed failure reasons. No additional tools appear needed for the stated purpose, making the surface complete for its domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Receive, inspect, replay and deliver webhooks — with signature verification and agent triggers.
Generates deterministic webhook HMAC-SHA256 fixtures and optionally verifies a supplied signature...
Keyless webhook endpoints: capture, wait, replay, forward, and generate types from real traffic.
Webhook capture bins for agents: get a URL, wait for webhooks, set replies, verify signatures.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Larslllllll/webhook-verify'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
