Server Quality Checklist

Tool Scores

• get_all_defi_positionsA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden of behavioral disclosure. While it mentions the scope ('across ALL supported blockchain networks and protocols') and types of positions included, it doesn't disclose important behavioral traits like rate limits, authentication requirements, response format, pagination, or error conditions. The description provides some context but leaves significant gaps for a tool that presumably makes complex external API calls.

  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 appropriately sized and front-loaded with the core purpose in the first sentence. The second sentence adds valuable context about scope and coverage. Both sentences earn their place by providing distinct information, though some phrasing could be slightly more concise.

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

  Completeness3/5

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

  Given the tool's complexity (querying multiple chains/protocols), lack of annotations, and no output schema, the description is moderately complete but has significant gaps. It explains the comprehensive scope well but doesn't address behavioral aspects, return format, or limitations. For a complex DeFi query tool with no structured safety/behavior annotations, the description should do more to guide the agent.

  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 description coverage is 100%, so the schema already fully documents the single 'wallet' parameter with format examples and validation patterns. The description adds no additional parameter semantics beyond what's in the schema - it doesn't clarify edge cases, multiple wallet formats, or how different address types affect results. Baseline 3 is appropriate when schema does all the parameter documentation.

  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 with specific verbs ('Get comprehensive DeFi positions') and resources ('for a wallet across ALL supported blockchain networks and protocols'). It distinguishes from siblings by emphasizing comprehensiveness across all chains/protocols, unlike tools like 'get_defi_by_chain' or 'get_defi_by_protocol' which are more limited in scope.

  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 clear context about when to use this tool ('complete portfolio overview across 10+ chains and 15+ protocols'), but doesn't explicitly state when NOT to use it or name specific alternatives. It implies usage for comprehensive overviews vs. more targeted sibling tools, but lacks explicit exclusions or named comparisons.

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

• get_defi_balances_by_chainA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context about the output structure ('aggregated balance information grouped by protocol') and purpose ('for diversification analysis and risk assessment'), which helps the agent understand what kind of data to expect beyond the safety profile already covered by annotations.

  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 with zero waste. The first sentence states the core functionality, and the second explains the output format and use case. Every word contributes meaningful 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?

  Given the tool's moderate complexity (2 parameters, no output schema), rich annotations covering safety and behavior, and 100% schema coverage, the description provides good contextual completeness. It explains the output structure and purpose, though it could benefit from mentioning limitations like supported protocols or data freshness.

  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 description coverage is 100%, with both parameters fully documented in the schema. The description doesn't add any parameter-specific details beyond what's already in the schema (e.g., wallet format specifics or chain enum values), so it meets the baseline of 3 when schema does the heavy lifting.

  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 specific action ('Get DeFi protocol balances'), target resource ('for a wallet on a specific blockchain network'), and scope ('aggregated balance information grouped by protocol'). It distinguishes from siblings by focusing on per-chain protocol grouping rather than multi-chain, overall balances, or protocol-specific queries.

  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 ('for diversification analysis and risk assessment') but doesn't explicitly state when to use this tool versus alternatives like 'get_defi_multi_chains' or 'get_overall_balance_by_chain'. No explicit exclusions or prerequisites are provided.

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

• get_defi_by_chainA
  4/5.0
  Behavior3/5

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

  Annotations already provide excellent behavioral coverage (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds useful context about what information is returned ('detailed information about lending, liquidity pools, yield farming, and other DeFi activities'), but doesn't disclose additional behavioral traits like rate limits, authentication needs, or response format details.

  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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second sentence elaborates on what information is provided. There's zero wasted language or redundancy.

  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?

  Given the rich annotations (covering safety, idempotency, and open-world nature) and complete parameter documentation in the schema, the description provides adequate context. However, without an output schema, the description could benefit from more detail about the return format or structure of the DeFi position data.

  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?

  With 100% schema description coverage, the input schema already fully documents both parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema descriptions, so it meets the baseline of 3. It doesn't explain parameter interactions or provide usage examples.

  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 with specific verb ('Get') and resource ('DeFi positions for a wallet on a specific blockchain network'). It distinguishes from siblings by specifying it's for a single chain (vs. multi-chain tools like get_defi_multi_chains) and focuses on positions rather than just balances (vs. get_defi_balances_by_chain).

  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 clear context for when to use this tool ('for a wallet on a specific blockchain network'), which implicitly distinguishes it from multi-chain alternatives. However, it doesn't explicitly state when NOT to use it or name specific alternative tools, keeping it from a perfect score.

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

• get_defi_multi_chainsA
  4/5.0
  Behavior3/5

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

  Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true). The description adds useful context about the tool's purpose for 'comparison and portfolio analysis' but doesn't disclose additional behavioral traits like rate limits, authentication needs, or what specific data is returned. With comprehensive annotations, the bar is lower, and the description adds some value without contradicting annotations.

  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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second sentence explains the value proposition and use case. No wasted words, and information is front-loaded appropriately.

  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?

  Given the comprehensive annotations (covering safety, idempotence, and open-world nature) and 100% schema coverage, the description provides adequate context for a read-only query tool. The main gap is the lack of output schema, but the description hints at what will be returned ('DeFi positions' for 'comparison and portfolio analysis'). For a tool with good structured metadata, this description is reasonably complete.

  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 description coverage is 100%, with both parameters well-documented in the schema. The description adds minimal semantic context beyond the schema - it mentions 'selecting specific chains of interest' which aligns with the 'chains' parameter, but doesn't provide additional meaning about parameter usage or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 specific action ('Get DeFi positions'), target resource ('for a wallet'), and scope ('across multiple specified blockchain networks'). It distinguishes from sibling tools by emphasizing multi-chain analysis rather than single-chain or protocol-specific queries, which helps differentiate from tools like 'get_defi_by_chain' or 'get_defi_by_protocol'.

  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 clear context about when to use this tool: for 'targeted multi-chain analysis by selecting specific chains of interest for comparison and portfolio analysis.' It implies this is for focused multi-chain queries rather than comprehensive scans, but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

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

• get_overall_balance_by_chainA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies the output includes 'multiple currencies (USD, EUR, AUD, GBP, JPY, CAD, CHF)' and that it provides 'aggregated portfolio valuation', which clarifies the return format and scope. No contradictions with annotations exist.

  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 efficiently structured in two sentences: the first states the core functionality and output currencies, the second clarifies the aggregated valuation scope. Every phrase adds value (e.g., listing currencies, specifying 'across all assets'), with no redundant or vague language. It's front-loaded with key 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?

  Given the tool's moderate complexity (2 parameters, no output schema), the description is largely complete: it covers purpose, behavioral traits (currency outputs, aggregation), and usage context. Annotations provide safety and idempotency info. The main gap is lack of explicit guidance on when to use versus siblings, but overall it's sufficient for an agent to understand and invoke the tool correctly.

  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 description coverage is 100%, with detailed descriptions for both parameters (wallet address formats and chain enum values). The description doesn't add parameter-specific semantics beyond what's in the schema, but it reinforces the purpose of querying 'a wallet on a specific blockchain network', aligning with the parameters. Baseline 3 is appropriate given the schema fully documents parameters.

  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 specific action ('Get comprehensive overall balance'), target resource ('for a wallet on a specific blockchain network'), and scope ('aggregated portfolio valuation across all assets held on the specified chain'). It distinguishes from siblings like 'get_wallet_balances_by_chain' by emphasizing overall/aggregated valuation rather than individual asset balances.

  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 specifying 'on a specific blockchain network' and 'across all assets held on the specified chain', suggesting this tool is for chain-specific aggregated valuation. However, it doesn't explicitly state when to use this versus alternatives like 'get_overall_balance_all_c' (which might cover multiple chains) or 'get_wallet_balances_by_chain' (which might provide per-asset details). No explicit exclusions or prerequisites are mentioned.

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

• get_wallet_balances_by_chainA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations by specifying what information is returned ('detailed information about all token holdings including amounts, USD values, and token metadata') and the purpose ('for portfolio analysis'), though it doesn't mention rate limits or authentication requirements.

  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 efficiently structured in two sentences: the first states the core functionality, and the second elaborates on the returned data and purpose. Every sentence adds value without redundancy, and key information is front-loaded appropriately.

  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?

  Given the tool's moderate complexity (2 parameters, read-only operation), rich annotations, and 100% schema coverage, the description provides good contextual completeness. It explains what data is returned and the use case, though without an output schema, it could benefit from more detail on response format or pagination. The annotations cover safety and idempotency well.

  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 description coverage is 100%, with both parameters well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (e.g., it doesn't clarify parameter interactions or provide examples). With complete schema coverage, the baseline 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 clearly states the specific action ('Get token balances'), target resource ('for a wallet on a specific blockchain network'), and scope ('all token holdings including amounts, USD values, and token metadata'). It distinguishes itself from sibling tools like 'get_all_defi_positions' or 'get_defi_balances_by_chain' by focusing specifically on token balances rather than broader DeFi positions.

  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 ('for portfolio analysis') but doesn't explicitly state when to use this tool versus alternatives like 'get_defi_balances_by_chain' or 'get_overall_balance_by_chain'. It mentions the specific blockchain requirement but doesn't provide guidance on tool selection among siblings.

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

• get_defi_by_protocolA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds valuable context beyond annotations by specifying that it provides 'detailed analysis of exposure' and works 'across all chains', which helps the agent understand the tool's scope and output nature. No contradictions with annotations are present.

  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 front-loaded with the core functionality in the first sentence and uses a second sentence to explain the purpose without redundancy. Every sentence adds value (filtering details and use cases), and there is no wasted text, making it efficient and well-structured.

  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?

  Given the tool's complexity (multi-chain DeFi analysis), annotations cover safety and behavior well, and the schema fully describes parameters. However, the lack of an output schema means the description could benefit from more details on return values (e.g., types of positions, metrics provided). It adequately covers the tool's purpose and usage but leaves output specifics ambiguous.

  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 description coverage is 100%, with clear descriptions for both parameters (wallet and protocol). The description adds some semantic context by mentioning 'filtered by a specific protocol' and 'for a wallet', but does not provide additional details beyond what the schema already covers, such as specific protocol examples or wallet format nuances. Baseline 3 is appropriate given high 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's purpose with specific verbs ('Get DeFi positions', 'filtered by a specific protocol across all chains') and distinguishes it from siblings by emphasizing protocol-specific filtering rather than chain-based or comprehensive position retrieval. It explicitly mentions the resource (DeFi positions) and scope (wallet, protocol, all chains).

  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 clear context for usage ('for risk assessment and yield optimization') and implies when to use this tool (when focusing on a specific protocol across chains). However, it does not explicitly state when not to use it or name alternatives among the sibling tools, such as 'get_all_defi_positions' for unfiltered results or 'get_defi_by_chain' for chain-specific filtering.

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

• get_overall_balance_all_cA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover key behavioral traits (read-only, open-world, idempotent, non-destructive), so the bar is lower. The description adds valuable context by specifying the scope ('across ALL supported blockchain networks') and output details ('multiple currencies...for comprehensive wealth tracking'), which enhances understanding beyond annotations. No contradiction with annotations.

  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 front-loaded with the core purpose in the first sentence, followed by additional details in a second sentence. Both sentences earn their place by clarifying scope and output without redundancy. It is appropriately sized and efficiently structured.

  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?

  Given the tool's complexity (multi-network balance retrieval), annotations provide good behavioral coverage, and the schema fully documents the single parameter. However, there is no output schema, and the description does not detail return values (e.g., structure of balance data). It is mostly complete but could benefit from more output information.

  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 description coverage is 100%, providing full details on the 'wallet' parameter (Ethereum or Solana address formats). The description adds minimal semantics by mentioning 'wallet' in context but does not provide additional meaning beyond the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

  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 with specific verbs ('Get overall balance') and resources ('wallet across ALL supported blockchain networks'), and distinguishes it from sibling tools by emphasizing 'ALL' networks versus the sibling 'get_overall_balance_by_chain' which is chain-specific. It specifies the output includes multiple currencies for portfolio valuation.

  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 suggests usage for comprehensive wealth tracking across all networks, but does not explicitly state when to use this tool versus alternatives like the sibling 'get_overall_balance_by_chain' or other DeFi-focused tools. It provides clear context but lacks explicit exclusions or named alternatives.

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