Server Quality Checklist

Tool Scores

• helloA
  4.3/5.0
  Behavior3/5

  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 describes the tool as a simple connectivity check with no side effects, which is adequate but lacks additional behavioral context such as idempotency or latency expectations.

  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 a single sentence that is concise, direct, and front-loaded with the core purpose. Every word is meaningful with zero redundancy.

  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 simplicity (zero parameters, output schema present), the description provides complete context for an agent to understand its purpose and use. No additional details are necessary.

  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 no parameters, so the description adds no information beyond the schema. Per the guideline, zero parameters sets a baseline of 4. The schema coverage is 100%, and the description is consistent.

  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 it is a connectivity check to confirm server reachability, with a specific verb 'check' and resource 'connectivity'. It is distinct from sibling tools about swaps and gas prices.

  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 implies the tool should be used to verify server reachability. Although no explicit exclusions or alternatives are provided, the context of sibling tools makes the usage obvious.

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

• get_gas_price_percentilesA
  4.4/5.0
  Behavior4/5

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

  Discloses that it uses standard eth_feeHistory and does not require mempool access, adding value beyond parameter names. No annotations are provided, so the description carries the burden well. Could mention that it returns a distribution but not the exact structure.

  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?

  Two concise sentences plus a clean Args list. Front-loaded purpose, no wasted words, efficient structure.

  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?

  Covers main purpose, parameter details, and implementation context. Lacks explicit return value description but the purpose implies what to expect. Good given simplicity and lack of output schema.

  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 0% schema coverage, the description adds meaning for both parameters: lists specific chain values (polygon, arbritrum) and describes block_count with default and max. Slightly inconsistent with 'any supported chain', but still helpful.

  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 it returns gas price distribution percentiles over the last N blocks, using a specific verb and resource. It distinguishes from sibling tools like swap checks and hello, which are unrelated.

  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?

  It mentions working on any supported chain and not requiring mempool access, providing context for when to use. However, it lacks explicit when-not or alternative tool comparisons.

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

• check_pending_swaps_on_poolA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: watches mempool, duration cap of 60 seconds, only single-hop swaps decoded, and platform restriction. This provides complete transparency for an AI agent.

  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?

  Well-structured with clear sections: purpose, platform restriction, limitations, and parameter list. Front-loaded with core action. The Args list is slightly verbose but necessary due to missing schema descriptions.

  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 5 parameters, no output schema, and no annotations, the description is comprehensive. It covers all parameters, constraints, limitations, and platform specifics, providing sufficient context for effective tool usage.

  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?

  Despite 0% schema coverage, the description includes an Args section explaining each parameter's purpose: pool_address, token0, token1, chain (only polygon), duration_seconds (capped at 60). Adds meaning beyond schema names.

  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 it watches the mempool for pending transactions touching a specific Uniswap v3 pool, including direct calls and single-hop router swaps. It distinguishes from the sibling 'check_confirmed_swaps_on_pool' by focusing on pending vs confirmed.

  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?

  Explicitly states it is only for Polygon and not available on Arbitrum due to centralized sequencer. Also notes limitation to single-hop swaps and directs to README for details, giving clear when-to-use and when-not-to-use guidance.

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

• check_confirmed_swaps_on_poolA
  5/5.0
  Behavior5/5

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

  Discloses it reads finalized on-chain state via eth_getLogs, is not a mempool tool, and only works on Polygon. Despite no annotations, the description fully conveys the behavioral traits (read-only, confirmed blocks, chain constraint).

  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?

  Concise yet complete: two short paragraphs, front-loaded with purpose, then behavior, then usage guidance, then parameter details. Every sentence adds value without redundancy.

  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 tool purpose, input parameters, output (total count + breakdown), chain constraint, and relationship to sibling tool. No output schema, but description sufficiently explains return value. Complete for its complexity.

  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?

  Despite 0% schema description coverage, the description explains each parameter: pool_address as the Uniswap v3 pool address, chain as only polygon, lookback_blocks as number of recent confirmed blocks with default 600 (~20 min on Polygon). Adds context and default meaning 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?

  Description clearly states it queries confirmed blocks for Uniswap v3 Swap events on a given pool, returns total swap count and breakdown by 'to' address. It explicitly distinguishes from sibling tool check_pending_swaps_on_pool (confirmed vs pending) and specifies Polygon only.

  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?

  Provides explicit guidance: use to establish ground-truth swap volume and compare with check_pending_swaps_on_pool to diagnose mempool coverage issues. Also clearly states what it is NOT (mempool tool), aiding correct invocation.

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