Skip to main content
Glama

attest

attest_decision

Attest a decision over (input_hash, output_hash, decision): sign it yourself, or omit the signature and the treasury signs for you — then dual-chain anchor. Returns the signer, on-chain proof URLs, and a free re-verify URL. $0.010 USDC.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemeNoSignature scheme when you supply a `signature`: "eip191" (EVM) or "ed25519" (Solana).
decisionYesFree-form short label, e.g. "APPROVED", "REJECTED", "CONFIDENCE=0.93".
signatureNo0x-prefixed hex (eip191) or base58 (ed25519). Omit to have the anchor-x402 treasury sign for you (hosted-signer mode, for wallet-less agents).
input_hashYes64-char hex SHA-256 of the agent's input.
output_hashYes64-char hex SHA-256 of the agent's output / decision payload.
signer_pubkeyNoRequired for ed25519 (Solana base58 pubkey). Ignored for eip191 — address is recovered.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only indicate non-readOnly and openWorld hint. The description adds valuable behavioral context: the operation costs $0.010 USDC, produces on-chain proof URLs, and includes a free re-verify URL. It also discloses the dual-chain anchoring, which implies permanent on-chain record creation.

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 two sentences that efficiently pack the core action, two signing modes, return values, and price. Every phrase carries information, with no redundancy or fluff.

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?

With 6 parameters and no output schema, the description covers the essential workflow and outcomes: what is attested, how to sign, what is returned, and the cost. It omits some edge-case details like required signer_pubkey for ed25519, but the schema covers that. Overall, sufficient for an agent to invoke correctly.

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?

The schema descriptions cover all parameters completely, so the baseline is 3. The description reinforces the three hashes and the signature omission behavior, but does not add significant meaning beyond what the schema already provides.

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 description clearly states the tool's purpose: attesting a decision over (input_hash, output_hash, decision) with optional self-signing or treasury signing, followed by dual-chain anchoring. It distinguishes itself from the sibling 'anchor_hash' by focusing on decisions and explicit signing options.

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?

The description provides clear operational guidance: sign it yourself or omit the signature for treasury signing, and explains the return values and cost. However, it does not explicitly reference alternative tools or when-not-to-use scenarios, so it stops short of a 5.

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.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a clearly distinct function — anchoring, decoding, wallet intelligence, entertainment, etc. Even similar tools like decode_calldata vs decode_tx and intel_wallet vs screen_wallet are precisely separated by descriptions.

Naming Consistency3/5

Most names follow a verb_noun pattern (anchor_hash, decode_calldata), but there are exceptions like aura_read (noun_verb), intel_wallet (noun_noun), and ledger_report (ambiguous). This mixed convention is readable but not fully consistent.

Tool Count4/5

18 tools is slightly above the ideal range but not overwhelming. Each tool serves a specific purpose, and the count feels reasonable for the broad set of utilities offered.

Completeness4/5

The core utilities (anchoring, wallet intelligence, ledger accounting) are well-covered without obvious dead ends. Some domain-specific workflows could be expanded (e.g., verifying anchors), but the existing tools provide complete standalone operations.