Server Quality Checklist

Tool Scores

• wallet_statusA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden, and it succeeds: 'Costs nothing and spends nothing' explicitly discloses that invocation has no monetary or spend effect. The word 'Report' also signals a read-only operation, and the note about where funding problems show up adds useful behavioral context.

  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 short paragraphs with no filler. The first sentence front-loads the tool's output contents, and the second adds essential usage guidance. Every sentence earns its place.

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

  Completeness5/5

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

  For a parameterless read-only status tool with an output schema available, the description is complete: it states what is returned, when to read it first, and that it has no cost or side effects. Nothing essential is missing for an agent to select and invoke it correctly.

  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?

  The tool has zero parameters, so there is nothing for the description to add beyond the schema. This matches the baseline of 4 for a parameterless tool; no parameter explanation is needed.

  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 uses a specific verb ('Report') and clearly identifies the resource as the wallet's state, enumerating the exact contents: network, vault address, balances, active session, spending, and caps. It is clear and informative, though it does not explicitly distinguish itself from the sibling wallet_funding_info, which may overlap on balances and vault details.

  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 gives explicit context for when to use the tool: 'Read this before assuming a payment can be made.' It explains why that matters by noting unfunded or non-opted-in vaults cannot pay. It does not explicitly mention alternatives or exclusion conditions, 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.

• x402_fetchA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden. It candidly states that real money can be spent on mainnet, that losses are capped at the session balance, that the receipt does not prove resource quality, and that refusals occur without spending. It also discloses file path confinement and the payment-before-verification risk with content_type.

  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 long but tightly structured with bolded section headers and front-loaded risk warnings. Every section addresses a practical operational concern, and the length is justified by the payment risk and param complexity. There is no filler or repetition.

  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 high-stakes tool with no annotations, the description is nearly complete: it covers spending limits, refusal conditions, return fields, file handling, JSON serialization, and content_type pitfalls. The only notable omission is guidance for the `method` parameter, which prevents a perfect completeness score.

  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?

  Schema description coverage is 0%, so the description must compensate. It does an excellent job explaining body, body_file, output_file, content_type, max_price_usdc, and url behavior. However, the `method` parameter is never mentioned, leaving a gap for agents unsure whether to send GET, POST, or other methods.

  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 opens with a specific verb and resource: 'Fetch a URL, paying automatically if it answers with an x402 payment challenge.' It clearly distinguishes this from the sibling wallet_status and wallet_funding_info tools by making it a network-fetch/payment tool rather than a wallet inspection tool.

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

  Usage Guidelines5/5

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

  The description gives explicit usage guidance: when payment happens, when it refuses without spending, that unpaid URLs are safe, and when to choose body_file vs body vs output_file. It also warns about content_type and binary payloads. These are concrete, decision-relevant conditions.

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

• wallet_funding_infoA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so thoroughly. It discloses that the tool is for a human and cannot be automated, that USDC sent before opt-in is rejected rather than held, that the QR encodes address and asset id but not amount, that image blocks may not render in terminals, and that qr_dir writes files to disk.

  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 long but every sentence carries substantive guidance: setup order, failure semantics, QR contents, parameter effects, browser behavior, and file output. It is front-loaded with the core purpose and then organized by parameter and usage scenario, so an agent can quickly extract the decision-relevant parts.

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

  Completeness5/5

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

  Given three optional parameters, no annotations, and no output schema, the description is complete enough for an agent to select the tool and invoke it correctly. It explains what the tool returns, how to choose parameters, the human-only nature, and how it fits alongside wallet_status.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must explain all parameters itself. It covers `asset` values ('ALGO', 'USDC', asset id, or omitted), `open_in_browser` behavior including rendering limitations and the self-contained page, and `qr_dir` including PNG output and the same file root as body_file/output_file.

  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 opens with a specific verb and resource: it explains how to fund the wallet and reports which of the three setup steps the vault is on. It also clarifies that it returns human-facing address and instructions, and it distinguishes itself from wallet_status by naming the usual flow where wallet_status answers balances and wallet_funding_info answers top-up questions.

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

  Usage Guidelines5/5

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

  The description gives explicit usage guidance: pass `asset` to narrow to one asset and omit it for the full picture, set `open_in_browser` when a human wants to scan the code, and provides the sibling relationship by saying wallet_status is for 'how much do I have' while wallet_funding_info is for 'I want to top up USDC'.

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