Developer Utilities & Validators (Tanod)

utilpeek: sign or verify an HMAC (webhook signatures)

hmac_sign_verify

Read-onlyIdempotent

utilpeek: Returns the HMAC of a message under a shared key (sign), or whether a signature matches it in constant time (verify); handles GitHub (sha256= prefix accepted), Stripe v1 (of {t}.{raw body}) and Slack v0 (of v0:{timestamp}:{raw body}) webhook signatures. For plain digests use hash_text; for JWTs use verify_jwt. Input: mode, message, key, optional key_encoding, algorithm, output and, for verify, signature. Malformed hex or base64, a sha*= prefix naming another algorithm, or verify without a signature is a 422 (not charged). Other prefixes (v0=, v1=) are not stripped. sha1 is for legacy webhooks only. The key and message are never echoed. Typically under 0.1 s. Price: USD 0.001. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/verify-webhook-signature-hmac-api.html

Input Schema

Name	Required	Description	Default
`key`	Yes	The shared secret (at most 1 KiB), read as `key_encoding`. Never echoed or logged.
`mode`	Yes	sign (compute the HMAC) or verify (check `signature`).
`output`	No	Signature encoding: hex (default) or base64.	hex
`message`	Yes	The signed payload exactly as received (e.g. the raw webhook body), as text; at most 64 KiB as UTF-8.
`algorithm`	No	sha256 (default), sha512, or sha1 (legacy webhooks only).	sha256
`signature`	No	verify only: the signature to check, in `output` encoding. A `sha256=` style prefix (GitHub's X-Hub-Signature-256) is stripped when it names `algorithm`.
`key_encoding`	No	utf8 (default), hex or base64 (standard alphabet).	utf8

Output Schema

Name	Required	Description
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`valid`	No
`output`	No
`algorithm`	No
`signature`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "algorithm": {
+      "enum": [
+        "sha256",
+        "sha512",
+        "sha1",
+        null
+      ],
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object."
+    },
+    "output": {
+      "enum": [
+        "hex",
+        "base64",
+        null
+      ],
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "signature": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "valid": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedOct 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover readOnly/idempotent/destructive, and the description adds substantial context beyond them: constant-time comparison, the 422 error cases that are not charged, that prefixes like v0=/v1= are not stripped, that key and message are never echoed or logged, latency (~0.1s), and pricing.

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?

Front-loads the purpose and alternatives, then inputs and error behavior. It is dense but nearly every clause carries operational detail; the price/free/docs tail adds slight marketing bulk but remains relevant to cost-sensitive callers.

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?

With an output schema present and rich annotations, the description needn't cover return values. Combined with explicit error cases, format handling, and encodings, an agent has everything needed to call it correctly across the three webhook providers.

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 schema already documents each parameter. The description still adds meaning: the accepted sha256= prefix behavior, how Stripe v1 signs {t}.{raw body} and Slack v0 signs v0:{timestamp}:{raw body}, and the key_encoding/algorithm interplay. Good value beyond the schema, though some format specifics live in the params.

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?

States specific verbs and resource: returns HMAC of a message under a shared key (sign) or verifies a signature in constant time (verify), and names the concrete webhook formats (GitHub, Stripe v1, Slack v0) it handles. It distinguishes itself from siblings hash_text and verify_jwt by name.

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?

Explicitly routes alternatives: 'For plain digests use hash_text; for JWTs use verify_jwt,' and confines sha1 to legacy webhooks. The sign-vs-verify mode distinction and the verify-requires-signature condition are stated outright.

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

All Developer Utilities & Validators (Tanod) tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?