Skip to main content
Glama

Genesis402 (x402 pay-per-call)

A signed Ed25519 receipt binding your SHA-256 digest (or tex

genesis402_prove

Paid ($0.25 USDC). A signed Ed25519 receipt binding your SHA-256 digest (or text) and optional claim to a settled payment. The receipt signature checks offline; the receipt chain is not externally anchored.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNo
claimNo
sha256No
payment_signatureNoOptional. An x402 v2 payment you signed for this call's quote (the PAYMENT-SIGNATURE header value). Omit to get the price quote first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/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 adds key behaviors: the call costs $0.25 USDC, the receipt signature verifies offline, and the receipt chain is not externally anchored. It does not detail other side effects like auth requirements, but for a paid receipt tool the monetary and anchoring disclosures are substantial.

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

Conciseness5/5

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

The description is compact and front-loaded: the cost warning appears first, followed by the core function and one important limitation, with no filler words. Every sentence conveys necessary selection or invocation information.

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

Completeness3/5

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

The high-level behavior is clear, but with no output schema the description doesn't specify the receipt's shape or how the payment/quote flow works (aside from the input schema's payment_signature note). It is sufficient as a starting point, but an agent would still need the schema details and perhaps a call example to know exactly what to pass and what to expect back.

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?

With only 25% schema description coverage, the description compensates by explaining that either a SHA-256 digest or text is bound and that claim is optional and tied to the settled payment. It adds meaning beyond the schema for text, sha256, and claim, while payment_signature already has a useful schema description.

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 clearly states the tool produces a signed Ed25519 receipt binding the caller's SHA-256 digest or text plus an optional claim to a settled payment, and it mentions the $0.25 USDC cost. It does not explicitly distinguish itself from sibling tools such as genesis402_receipt, so it stops short of full sibling differentiation.

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 description implies the tool should be used when a low-cost, offline-verifiable receipt for a digest/text with a claim is needed; the caveat that the receipt chain is not externally anchored hints at a limitation. It does not state when to prefer sibling tools or provide explicit when-not-to-use conditions, leaving usage mostly implicit.

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.