Server Quality Checklist

Tool Scores

• x402_healthB
  3.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 behavioral transparency burden. It discloses the 'free' nature and implies a read-only operation via 'Check', but it does not describe whether authentication is required, what the response contains, or whether it checks underlying services. Adds some value beyond the empty schema, but lacks richer 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 a single sentence with the core purpose front-loaded. The additional note about being a 'free endpoint' is a useful differentiator and earns its place without padding.

  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?

  This is a simple 0-parameter health check tool. The description conveys its function and cost, which is adequate for basic selection. It could elaborate on what 'health status' entails or the response format, but given the simplicity, the current description is reasonably complete.

  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 0 parameters, and the schema already fully covers this (empty properties). The description does not need to add parameter semantics. Per rubric, a 0-parameter tool gets a baseline score of 4.

  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 the specific verb 'Check' with the resource 'API health status', clearly identifying the tool's purpose. It is distinct from sibling tools (wallet_score, token_metrics, etc.), which focus on metrics rather than health. However, it does not specify what 'health status' means (e.g., up/down, latency, dependencies) or the expected response format.

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

  Usage Guidelines1/5

  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 tool versus alternatives. The description mentions it is a 'free endpoint', implying a cost advantage but does not state when this should be preferred over sibling tools or any exclusions. No sibling tools are referenced in the description.

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

• x402_token_metricsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the $0.05 cost and the x402 payment protocol, which is a significant behavioral trait, and the verb 'Get' implies a read-only operation. However, it doesn't mention error scenarios, authentication, or response format.

  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, efficient sentence that front-loads the action ('Get token data') and packs in the output fields and cost without any redundant wording.

  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 simple one-parameter tool, the description adequately covers the output scope and cost. It could be slightly more complete by noting the return structure or behavior on invalid addresses, but given the tool's simplicity, it is nearly sufficient.

  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 already fully describes the single parameter 'address' as 'Token contract address (0x...)', and the description adds no further detail about formatting or defaults. This meets the baseline given 100% schema coverage.

  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 retrieves token data with a specific list of metrics (price, market cap, 24h volume, liquidity, FDV). This makes it distinct from sibling tools like wallet_score or protocol_tvl.

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

  Usage Guidelines3/5

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

  No explicit guidance is given about when to use this tool versus alternatives, but the purpose is clear enough that usage can be inferred when token-specific data is needed. It lacks any mention of exclusions or sibling comparisons.

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

• x402_protocol_tvlA
  4/5.0
  Behavior4/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 discloses the cost ($0.05 per call) and payment protocol (x402), a key operational detail, and specifies output components. However, it omits rate limits, authorization requirements, and error behavior, leaving some gaps.

  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 concise sentences: the first states purpose and data content, the second discloses cost. No redundant text, and key information is front-loaded.

  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 simple one-parameter read tool with no output schema, the description covers the returned data categories and the cost model. It lacks explicit return structure or usage examples, but is otherwise adequate for invocation.

  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?

  Schema coverage is 100% and the single 'slug' parameter is fully described in the schema with examples. The description adds no additional parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.

  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 uses a specific verb 'Get' with a clear resource 'DeFi protocol TVL data' and enumerates included fields (total value locked, 24h change, chain breakdown). This distinguishes it from sibling tools focused on wallet scores, token metrics, gas prices, and health.

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

  Usage Guidelines3/5

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

  The description implies usage for querying protocol TVL but does not explicitly state when to prefer this tool over siblings or provide exclusions. No direct comparison to alternatives is made, though sibling names hint at distinct purposes.

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

• x402_wallet_scoreA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It uniquely discloses a cost of $0.10 per call via the x402 payment protocol, which is critical behavioral information. It also lists the specific data fields returned, giving a clear sense of the tool's read behavior. It does not mention failure modes or authentication details, but the cost disclosure is a strong plus.

  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, tightly packed sentence that leads with the core action, enumerates the data items, and ends with cost. Every word earns its place; there is no filler or redundant information.

  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?

  The tool is simple (one parameter, no output schema), and the description covers what data is returned, the cost, and the payment protocol. It does not explain the return format or error behavior, but for a read-only wallet profile tool with transparent pricing, this is largely complete. A score of 4 recognizes the missing but non-critical details.

  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 input schema has 100% coverage for the single 'address' parameter with a description 'Ethereum wallet address (0x...)'. The tool description adds no further meaning about the parameter, such as format validation, network specifics, or examples. According to the baseline rule for high schema coverage, a score of 3 is appropriate.

  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 starts with 'Get comprehensive wallet profile' which is a specific verb and resource, followed by a concrete list of included data (ETH balance, transaction count, timestamps, top 5 tokens). This clearly distinguishes it from sibling tools like x402_token_metrics or x402_gas_prices, which serve different purposes.

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

  Usage Guidelines3/5

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

  The description implies usage context by detailing the wallet-specific data, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no 'use this when...' or reference to sibling tools, leaving the agent to infer applicability.

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

• x402_gas_pricesA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about the paid nature of the call ("Cost: $0.02 per call via x402 payment protocol") and the specific estimates returned. It does not disclose potential side effects or rate limits, but the cost and payment requirement are meaningful disclosures.

  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 concise sentences. The first sentence states the core purpose and outputs, the second discloses the cost. Every word earns its place 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?

  For a zero-parameter tool with no output schema, the description is reasonably complete: it states what data is returned and the cost. It could mention update frequency or API key requirements, but these are not critical for basic understanding. Overall, it provides sufficient context for an agent to select and invoke the tool 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 the baseline for parameter semantics is 4. The description adds useful information about the output types (slow/standard/fast gwei and USD cost estimates), which helps clarify what the tool returns even though there is no output 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 "Get current Ethereum gas prices" with specific output details (slow/standard/fast gwei estimates and USD cost estimates). This distinguishes it from sibling tools focused on wallet scores, token metrics, TVL, and health, all of which have different purposes.

  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 implicitly conveys when to use the tool (when you need current Ethereum gas prices with cost estimates), and the sibling tools are topically distinct, making the use case obvious. However, it does not explicitly mention when not to use it or list alternatives, so it falls 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.