Your agent carries its own resume — outcome receipts minted at settlement, held by the agent.
Scored across 7 tools
The set splits cleanly into minting (mint_receipt, close_and_mint), proving (aggregate_proof, verify_proof), and read-only checks (check_tx, verify_receipts, export_wallet), and descriptions clarify the paid vs free split. The one soft spot is mint_receipt vs close_and_mint, which both mint and share the same free-then-x402 pricing, differing mainly in whether a settlement close accompanies the mint.
Every name is snake_case verb_noun (aggregate_proof, check_tx, close_and_mint, export_wallet, mint_receipt, verify_proof, verify_receipts) with no camelCase or style mixing. The verify_* and *_receipt/.*_proof prefixes make families predictable.
Seven tools is well within the sweet spot and each maps to a distinct step in the workflow (mint, close, check, aggregate, verify, export). Nothing appears redundant or padded.
The core lifecycle is covered: receipt creation, settlement minting, mint-status lookup, aggregation, both verification paths, and wallet export. Gaps are minor but real: there is no list/read tool to enumerate an agent's own receipts, and aggregate_proof reports a dispute rate with no way to file or inspect disputes, plus export_wallet has no corresponding import.
Registry-signed aggregate proof over an agent's history (counts/dispute rate, no receipts surrendered). x402 $0.05 per 1,000 receipts in the set.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| task_class | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real behavioral context: the proof is registry-signed, the outputs are counts/dispute rate, receipts are not disclosed, and there is an x402 payment cost of $0.05 per 1,000 receipts. It omits what happens on payment failure or how the charge is assessed, but the pricing and privacy disclosures are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the resource and result shape, followed by the cost. Slightly cryptic phrasing ('no receipts surrendered', 'the set') costs a little clarity for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and a two-param schema with zero descriptions, so the description must do more than it does. It tells the agent what is proven and what it costs, but leaves output structure and task_class semantics unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate and largely doesn't. It references 'agent's history' (agent_id) and 'the set' (presumably task_class scoping), but never explains what task_class does or whether it narrows the aggregation — an agent could easily pass it or omit it with no clear expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: an aggregate proof over an agent's history, registry-signed, yielding counts and dispute rate. It's distinct enough from verify_proof/verify_receipts, but it never names those siblings, so the differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'no receipts surrendered' implies the use case (privacy-preserving aggregate instead of per-receipt verification) but the description never states when to choose this over verify_proof or verify_receipts. Usage is inferable rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MINTED or NEVER_MINTED for a transaction id. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose two useful traits: the exact output values (MINTED/NEVER_MINTED) and that the call is free (no cost/rate impact implied). It omits whether it is read-only, which network/cluster it queries, and what happens for unknown tx ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero waste; the return values and cost are stated immediately. Nothing extraneous for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-param, no-output-schema lookup, the description covers return values and cost, which is the core. It is still thin on network scoping and behavior for non-existent or malformed tx ids, which matter for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required parameter, so the description must compensate. It identifies tx_id as a 'transaction id', which gives meaning to the single param, but adds no format, encoding, or network-scoping detail an agent might need to supply a valid value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reveals the return domain (MINTED / NEVER_MINTED) for a transaction id, which effectively conveys it is a status lookup. However the verb is only implied by the name, and apart from the cost hint ('Free') it does nothing to distinguish it from siblings like verify_proof or mint_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free' subtly suggests preferring this over a paid check, but no when-to-use condition, prerequisite, or named alternative is given. The agent must infer that this is the cheap pre-mint status check versus verify_proof.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Settlement close that mints the outcome receipt into the agent wallet as a condition of SETTLED. First mint free once per agent; then x402 $0.01 (or wallet plan).
| Name | Required | Description | Default |
|---|---|---|---|
| tx_id | Yes | ||
| outcome | Yes | ||
| agent_id | Yes | ||
| task_class | Yes | ||
| value_band | Yes | ||
| source_kind | Yes | ||
| counterparty_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose two real traits — minting is a precondition of SETTLED and there is a per-agent free-then-paid cost model — but says nothing about idempotency, whether closing is irreversible, or what happens when payment fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler, and the core action is front-loaded before the pricing caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-required-param mutation-style tool with no annotations and no output schema, the description should define parameter intent and failure behavior. It covers cost and the SETTLED coupling but leaves the invocation details almost entirely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Seven required parameters at 0% schema description coverage, and the description names none of them. Ambiguous fields like value_band, counterparty_class, source_kind, and outcome get no explanation anywhere, leaving the agent to guess at formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: a settlement close that mints an outcome receipt, tied to a SETTLED state. That is far more specific than the sibling mint_receipt, though the description never explicitly contrasts the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The pricing line (first mint free once per agent, then x402 $0.01) implies this is the paid settlement path, but the description never states when to pick this over mint_receipt or how it relates to check_tx/verify_receipts. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export your agent's wallet as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and falls short. It does not say whether this is a read-only operation, whether the export includes sensitive key material, whether it requires authorization over the given agent, or whether the export side-effects anything. For a wallet export these omissions matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the key information (verb, resource, format) is front-loaded. Its brevity is efficient rather than padded, though it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and zero parameter documentation mean the description should explain the security and authorization profile of a wallet export as well as the meaning of agent_id. It does neither, leaving an agent to guess on a potentially sensitive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and does not. It says "your agent's wallet" while requiring an agent_id, leaving unclear whether the id must be the caller's own agent or can reference another — a meaningful ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Export ... wallet") plus the output format (JSON), which is more than a restatement of the name. It does not differentiate from siblings like check_tx or verify_proof, but the resource is distinct enough that an agent can tell what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives, no prerequisites, and no statement of what state the wallet must be in. The only implied usage is the self-evident act of exporting a wallet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint an outcome receipt directly. First mint free once per agent; then x402 $0.01 (or wallet plan).
| Name | Required | Description | Default |
|---|---|---|---|
| tx_id | Yes | ||
| outcome | Yes | ||
| agent_id | Yes | ||
| task_class | Yes | ||
| value_band | Yes | ||
| source_kind | Yes | ||
| counterparty_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does add real value on the cost model — first mint free once per agent, then x402 $0.01 or a wallet plan. However it omits whether minting is idempotent, what happens if a receipt already exists for the tx_id, and what the receipt contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action front-loaded and zero filler. It is tight, though the phrase 'x402 $0.01 (or wallet plan)' is compressed to the point of being cryptic to an agent unfamiliar with the payment scheme.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with seven required, entirely undocumented parameters, no annotations, and no output schema, the description is far too thin. It explains pricing but not the inputs, the receipt's structure, or how it relates to close_and_mint and verify_receipts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Seven required parameters at 0% schema description coverage, and the description says nothing about any of them: not agent_id, tx_id, task_class, counterparty_class, outcome, value_band, or source_kind. An agent must guess the accepted values and formats for every input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Mint an outcome receipt directly.' The word 'directly' hints at a distinction from the sibling close_and_mint, but that distinction is never made explicit, and 'outcome receipt' is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'directly' and the separate sibling close_and_mint imply a usage fork, but the description never says when to mint directly versus via close_and_mint, nor what prerequisites (wallet, valid tx_id) are needed. Usage is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an aggregate proof. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Free' discloses that there is no cost, and 'verify' implies a read-only operation, but the description does not explain what verification means, what happens on failure, whether the proof is mutated, or what the result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded: 'Verify an aggregate proof. Free.' Every clause has a purpose, with cost information included efficiently. The brevity is appropriate, though the second sentence is thin.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an opaque nested parameter object, the description is incomplete for an agent to invoke the tool correctly. It does not explain the proof format, expected return, failure behavior, or relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, 'proof,' described only as a nested object with 0% schema description coverage. The description says 'aggregate proof' but provides no structure, format, or encoding guidance for the nested object. With low coverage and a complex nested parameter, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Verify an aggregate proof.' This clearly distinguishes it from sibling tools like aggregate_proof, verify_receipts, and mint_receipt. It lacks explicit sibling differentiation, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Free,' which addresses cost but not when to use this tool versus verify_receipts or aggregate_proof. There are no conditions, prerequisites, or exclusions to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Completeness check of a surrendered receipt list vs registry ground truth. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| receipts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one genuine behavioral trait — the operation is free — and 'completeness check' implies a non-mutating comparison, but it says nothing about side effects, whether the receipt list is consumed/surrendered permanently, or failure behavior on malformed input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core comparison, zero padding. The 'Free.' fragment is terse but carries real cost information, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must explain results — does it return a boolean, a list of missing receipts, a diff? It also leaves the receipts array shape undefined. For a two-parameter verification tool that is a meaningful shortfall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so 'agent_id' and 'receipts' are entirely undocumented in structured fields. The description does not clarify whether 'receipts' is an array of IDs, hashes, or full receipt objects, nor what form 'agent_id' takes — a real gap for the agent constructing the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the specific operation (completeness check) and both operands: the surrendered receipt list and registry ground truth. An agent can tell it is a verification/comparison tool rather than a minting or export tool, though it is phrased as a noun rather than a verb and never names a sibling it is distinct from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the word 'Free', which hints that this check carries no cost, but there is no statement of when to call it versus verify_proof or verify_receipts-adjacent siblings, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aggregate_proofcheck_txclose_and_mintexport_walletmint_receiptverify_proofverify_receiptsCryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
Signed, append-only receipts of an AI agent's decisions and outcomes, with public proof links.
Agent routing, safety preflight, execution receipts, best execution and verified outcomes.
Paid agent work and paid verification, settled in USDC. Verified outcomes get signed receipts.
Add one secure layer between your agents and this server.
