text digest (sha256, keccak256)

mcp_digest

Send text and get its sha256 or keccak256 hash as hex. Listed by Moonbeam: nine outside sellers stand behind it, and the best-ranked one answers.

The answer is checked before you pay, so a failed answer is not charged, and it is graded after. One call is 0.0012 USDC, paid with x402 on Base.. 0.0012 USDC a call, paid with x402 on Base: without a payment the call answers the payment terms; send the signed payment in _meta["x402/payment"] (or as payment, the PAYMENT-SIGNATURE value) and call again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input": "<input>"
    },
    "name": "mcp_digest"
  }
}

Input Schema

Name	Required	Description	Default
`input`	Yes	the mcp.digest input, e.g. {"text":"hello world","algorithm":"sha256"}
`payment`	No	optional: the x402 PAYMENT-SIGNATURE header value (base64) for the terms the first call answered

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses price (0.0012 USDC), payment rail (x402 on Base), and a verification/refund guarantee that failed answers are not charged and results are graded after. The 'nine outside sellers ... best-ranked one answers' sentence is vague marketplace framing that adds little, keeping it below a 5.

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 purpose is front-loaded, but the pricing sentence is duplicated verbatim across two sentences (including a stray 'Base..'), and the Moonbeam seller sentence is noise that does not help invocation. Roughly a third of the text could be removed without losing information.

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?

For a two-parameter, nested-input tool with no output schema, the description covers purpose, algorithms, return format (hex), pricing, and the full payment handshake. It stops short of describing the response envelope field names or failure modes, but that gap is minor here.

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 coverage is 100% and the nested input object already carries an example, so the baseline is 3. The description adds some value by explaining the payment parameter's two accepted placements, but it does not clarify the input object's fields beyond what the schema example already shows.

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 opening sentence states a specific verb and resource with its variants and output form: send text, get sha256 or keccak256 as hex. An agent knows exactly what the tool computes without opening the schema, and there are no siblings to confuse it with.

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 gives concrete call-flow guidance: an unpaid call returns payment terms, then the signed payment goes in _meta["x402/payment"] (or the `payment` parameter) and you call again. There are no alternative tools to disambiguate against, but the when/how-to-pay condition is explicit rather than implied.

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

All text digest (sha256, keccak256) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?