Skip to main content
Glama

MCP digest

mcp_digest
Read-only

One mcp.digest answer, bought through Moonbeam. The answer is checked before you are charged, and a failed answer is not charged. One call is 0.0012 USDC, paid with x402 on Base.

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": {
      "algorithm": "<algorithm>",
      "text": "<text>"
    },
    "name": "mcp_digest"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesthe text, as the task quotes it (UTF-8)
algorithmYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.6/5.0
Behavior4/5

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

Beyond the readOnly/openWorld annotations, the description adds concrete behavioral context: cost, x402 payment on Base, Moonbeam purchase, answer validation before charging, and no charge on failure. It does not explain wallet/auth prerequisites or the returned digest format, but it meaningfully improves transparency for a paid external call.

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?

The description is short and front-loaded with the paid-answer framing, and each sentence contributes cost or charge-policy information. The main weakness is that it uses the opening sentence for branding rather than the actual operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter digest tool with no output schema, the description omits both the core operation and the shape of the returned answer. It thoroughly covers payment and charging behavior but leaves the agent without a clear statement of what the tool computes or returns.

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

Parameters2/5

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

The description does not mention either parameter. The schema documents the text input and exposes an algorithm enum, but the description adds no meaning about how algorithm selection works or what text format is expected at call time.

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

Purpose2/5

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

The description says 'One mcp.digest answer' but never states that the tool computes a digest or hash of text. It restates the tool name in marketing terms and spends most of its text on payment, so an agent must infer the core operation from the schema enum values.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, and the sibling tools are not referenced. The payment context is clear, but usage conditions for computing a digest are absent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources