Skip to main content
Glama

RevClamp MCP Server

by io.github.revclamp
OverviewDiscussionsAdmin

Verify Stripe, Shopify & RevClamp Webhook HMAC-SHA256 Signatures

revclamp_verify_webhook_signature
Read-onlyIdempotent

Generate and verify canonical Stripe-Signature (t=,v1=<hex_sha256>), X-Shopify-Hmac-Sha256 (<base64_sha256>), and X-RevClamp-Signature (t=,v1=<hex_sha256>) headers over exact UTF-8 webhook payload bytes using crypto.timingSafeEqual and a 300-second replay window guard. Enforces a Zero-Trust guard that blocks known live/production credential patterns (sk_live_, rk_live_, non-test whsec_..., shpss_..., shpat_..., rg_live_, rc_live_, AKIA..., and PEM private keys) with -32602 LIVE_SECRET_FORBIDDEN_IN_SANDBOX. Returns structuredContent containing ok, mode, statelessEphemeralAudit, tenantId, and verification (provider, verificationMode, headerName, generatedHeader, expectedSignature, signatureValid, verificationReason, timingSafeCompared, replayWindowApplicable, timestampSec, timestampSkewSeconds, toleranceSeconds, withinReplayWindow, payloadByteLength, payloadSha256, commonIntegrationTrap). Use this tool to debug webhook signature mismatches and replay skew.

Input Schema

NameRequiredDescriptionDefault
secretNoSynthetic or test webhook signing secret (default: 'whsec_test_revclamp_sandbox_secret_2026', max 256 chars). Live production secrets (sk_live_, rk_live_, non-test whsec_..., shpss_..., shpat_..., rg_live_, rc_live_, AKIA..., and PEM private keys) are rejected.
providerNoWebhook signature provider scheme to evaluate: 'stripe' (Stripe-Signature t=<sec>,v1=<hex>, default), 'shopify' (X-Shopify-Hmac-Sha256 Base64 raw UTF-8 HMAC), or 'revclamp' (X-RevClamp-Signature t=<sec>,v1=<hex>).
rawPayloadNoExact unparsed UTF-8 webhook request body string (up to 16,384 chars) used to compute the canonical SHA-256 HMAC digest. Defaults to a provider-specific sample JSON event if omitted.
timestampSecNoOptional Unix epoch timestamp in integer seconds (valid range: 1 to 9999999999; defaults to current server Unix timestamp) used when generating or verifying timestamped Stripe/RevClamp headers.
signatureHeaderNoOptional supplied HTTP signature header value to verify via crypto.timingSafeEqual (e.g. 't=1760000000,v1=...' or Base64 digest, max 512 chars). Omit to run in GENERATE_AND_SELF_VERIFY mode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations (which only declare readOnly/idempotent/non-destructive/closed-world), the description discloses the 300-second replay window guard, timingSafeEqual comparison, the Zero-Trust live-credential blocklist with the exact JSON-RPC error code -32602 LIVE_SECRET_FORBIDDEN_IN_SANDBOX, and the full set of structuredContent fields returned. That is substantial behavioral context an agent could not get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the opening sentence is a ~60-word run-on and the return-value enumeration is an undifferentiated comma-separated wall of 18 field names. Every element is arguably relevant, but the density makes it hard to scan for the one or two facts an agent needs at call time.

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?

With no output schema, the description correctly compensates by enumerating the structuredContent return fields, and it covers modes, defaults, limits, error semantics, and replay tolerance. Only the boundary against the sibling replay-simulation tool is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema — including the live-secret rejection list and the generate-vs-verify mode for signatureHeader. The description mostly restates this (secret guard, header formats, 16,384-char payload cap) rather than adding new meaning, so it sits at the baseline for a fully-covered schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (generate/verify HMAC-SHA256 webhook signature headers) across three named provider schemes, with the exact canonical header formats given. It is unambiguous what the tool does, but it never names or distinguishes itself from the adjacent sibling revclamp_simulate_webhook_replay, which an agent could easily confuse with this one.

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?

"Use this tool to debug webhook signature mismatches and replay skew" gives a clear triggering context, and "Omit [signatureHeader] to run in GENERATE_AND_SELF_VERIFY mode" explains the two operating modes. However there are no exclusions and no routing to alternatives, notably the replay-simulation sibling, so the agent must infer boundaries.

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

All RevClamp MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources