Skip to main content
Glama

RevClamp MCP Server

by com.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
demoNoOptional sandbox flag; uses synthetic defaults when provider, secret, or rawPayload are omitted.
secretNoSynthetic or test webhook signing secret (default: 'whsec_test_revclamp_sandbox_secret_2026', max 256 chars, or comma-separated rotation secrets). Live production secrets (sk_live_, rk_live_, non-test whsec_..., shpss_..., shpat_..., rg_live_, rc_live_, AKIA..., and PEM private keys) are rejected.
secretsNoOptional array of 1 to 5 synthetic/test webhook signing secrets (each <= 256 chars) to evaluate during rolling webhook secret rotation.
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.
toleranceSecNoOptional replay window tolerance in integer seconds (valid range: 1 to 3600, default: 300).
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

A3.9/5.0
Behavior5/5

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

Well beyond the readOnly/non-destructive annotations, the description discloses the timing-safe comparison, the 300-second replay window guard, the Zero-Trust live-credential blocklist with the exact -32602 LIVE_SECRET_FORBIDDEN_IN_SANDBOX error, default payload/secret fallbacks, and the full structuredContent shape. This is unusually rich behavioral context for a sandbox tool.

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 it is delivered as two very long run-on sentences stuffed with parenthetical header formats and a long enumerated blocklist. Listing every structuredContent field inline aids completeness but bloats the prose, and some enumeration belongs in structured data rather than the description.

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 an 8-parameter tool with no output schema, the description compensates well: it names the returned fields, explains the guard/failure code, the replay window, defaults for omitted inputs, and both operating modes. An agent has what it needs to call this correctly and interpret the result.

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 8 parameters are already documented, and most of the description's parameter talk (rotation secrets, default secret, non-test whsec_ rejection) restates the schema. The only added semantic is that omitting signatureHeader switches to GENERATE_AND_SELF_VERIFY mode, which is marginal added value against 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?

The description states a specific verb and resource: generate and verify canonical HMAC-SHA256 signature headers for Stripe, Shopify, and RevClamp webhooks, plus a debug use case. It is clearly distinguishable from most siblings, though the very close sibling revclamp_simulate_webhook_replay is never named or contrasted.

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

Usage Guidelines3/5

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

The closing sentence gives a usage context ('debug webhook signature mismatches and replay skew'), and the signatureHeader param note explains the generate-vs-verify mode. However there are no exclusions and no comparison to the near-identical sibling simulate_webhook_replay, leaving the agent to infer which to pick.

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