Server Quality Checklist

Tool Scores

• explain_scanA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses cost, fetch-only nature, success/failure return formats, and demo mode behavior with `_demo: true`. Could mention rate limits or auth but covers key aspects.

  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?

  Well-structured: purpose, cost/usage, arguments, returns, demo mode – all in a few sentences. Front-loaded with purpose. No wasted words.

  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?

  Covers all necessary aspects for a simple tool: purpose, cost, return format (including error and demo), and source of scan_id. Output schema exists so return details are sufficient.

  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?

  Only one parameter (scan_id) with 0% schema coverage. Description adds value by stating it's a UUID from a prior `scan_token` call, providing source context beyond schema.

  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?

  Clearly states 'Fetch the per-heuristic audit trail of a previous scan' – a specific verb and resource. Distinguishes from sibling tools 'pretrade_check' and 'scan_token' by its post-scan audit purpose.

  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?

  Explicitly says when to use: 'Use this when you need to know *why* a scan returned a specific verdict — e.g. for compliance, post-mortems, or building a user-visible explanation.' Also mentions cost ($0.005 USDC). Does not explicitly state when not to use, but context is clear.

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

• pretrade_checkA
  4.7/5.0
  Behavior5/5

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

  The description discloses cost ($0.01 USDC), signing/verification, disclaimer integrity, and decision logic per policy. No annotations are provided, so the description carries full burden and does so thoroughly.

  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 well-structured and front-loaded with the key output. While comprehensive, it is slightly lengthy but every sentence adds value.

  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 the tool's complexity and that an output schema exists, the description is complete, covering return values, edge cases (uncertain verdict), and disclaimer integrity. It complements the schema well.

  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 coverage is 0%, but the description fully explains each parameter: chain (base/solana), address format, intended_trade_usd constraints, and policy options with defaults. This adds significant meaning beyond the schema.

  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 function as a pre-trade firewall returning a decision (block/caution/allow) and clamped exposure. It distinguishes itself from siblings (scan_token, explain_scan) by its specific pre-trade role.

  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 explains when to use the tool (pre-trade check) and details the policy parameter's behavior. It implies usage context but does not explicitly state when not to use or compare with siblings.

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

• scan_tokenA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavior: payment of $0.01 USDC on Base via x402, per-session and 24h spending caps leading to a spend_cap_exceeded error, demo mode with canned responses, and detailed error types. This covers all critical behavioral aspects.

  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 well-organized with 'Args' and 'Returns' sections, front-loading the purpose. It is thorough but not overly verbose; every sentence adds value. A slight trim could be made, but it remains highly effective.

  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 the tool's complexity (payment, caps, demo, multiple chains) and the presence of an output schema, the description covers all necessary aspects: return structure on success and failure, error types, demo behavior, and parameter constraints. It is fully complete.

  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?

  The input schema has 0% description coverage, so the description adds essential meaning. It specifies the allowed values for chain ('base' for EVM, 'solana' for SPL mint) and the address format ('0x...' for EVM, base58 for Solana). This goes well beyond the schema's bare property titles.

  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: 'Run a pre-trade rug-pull risk scan on a token contract.' It specifies the verb (scan), the resource (token contract), and the output (structured risk report). The mention of returning a risk report distinguishes it from siblings like explain_scan and pretrade_check.

  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 context for when to use the tool (pre-trade risk scan), details about payment and spending caps, and error conditions. It does not explicitly exclude usage scenarios or name direct alternatives, but the purpose is clear enough for correct selection.

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