Server Quality Checklist

Tool Scores

• get_chains_tvlA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the sorting order ('ranked highest first') and scope ('across all blockchains'), which adds value beyond the name. However, it lacks details on return structure, pagination, or whether data is real-time, leaving some behavioral aspects opaque.

  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 sentences, front-loads the core concept with the acronym expansion, and includes no wasted words. Every sentence contributes to clarity, making it highly concise 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?

  For a simple tool with one parameter and no output schema, the description adequately conveys what the tool returns (a ranked list of chains by TVL). It covers the essential context without requiring additional elaboration, though it could mention the output format (e.g., chain names with TVL amounts) for full completeness.

  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 fully documents the only parameter 'limit' with a description of its default and maximum. The description adds no additional parameter-level semantics, so the schema already provides the necessary meaning. 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 a specific verb+resource: it returns Total Value Locked (TVL) across all blockchains, ranked by value. It distinguishes from sibling tools by focusing on chains rather than protocols, prices, or yields, making the tool's purpose unambiguous.

  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 retrieving a global ranking of chain TVL, but it does not explicitly mention when to choose this tool over siblings like get_protocol or get_yield_pools. There is no exclusionary guidance, so the context is clear but not fully elaborated.

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

• get_stablecoinsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It describes the output (largest stablecoins with peg type) but does not explicitly state that the operation is read-only, whether authentication is required, or if there are any side effects. For a simple listing operation, this is acceptable but not comprehensive.

  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, compact sentence that efficiently conveys the tool's purpose. It front-loads the key resource ('Largest stablecoins') and appends the distinguishing attribute ('with peg type'), with no wasted words 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?

  For a tool with one optional parameter and no output schema, the description is largely complete. It explains what data is returned (stablecoins ranked by supply, plus peg type categories) but does not detail the exact fields or response structure. The parameter's default and maximum are handled by the schema, which is acceptable, though a bit more detail would make it fully self-contained.

  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 includes one parameter, 'limit,' with a complete description ('How many to return (default 15)'), providing full semantics. The tool description adds no additional detail about the parameter, but since schema coverage is 100%, 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 tool returns 'Largest stablecoins by circulating supply,' which is a specific verb+resource pairing. It also enumerates the peg type categories, making it distinct from sibling tools like get_chains_tvl or get_token_prices. This is not a tautology and fully conveys the tool's function.

  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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or pre-conditions. The intended use case is only implied by the name and content—that it handles stablecoin data—so the usage context is indirectly communicated but lacks explicit direction.

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

• search_protocolsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It mentions ranking by TVL and the empty-query behavior, which is useful. However, it does not describe response format, pagination, or whether search is fuzzy or exact—leaving some ambiguity for the agent.

  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?

  A single, well-structured sentence conveys the core functionality, examples, sorting criterion, and special empty-query case. No wasted words, front-loaded with the action ('Search DeFi protocols').

  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 with only two optional parameters and no output schema. The description covers the key behavioral cues (search criteria, ranking, empty-query default). A minor gap is the lack of mention of returned fields or result limits, but the schema's limit parameter mitigates this.

  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%, with both 'limit' and 'query' fully described in the schema. The description reiterates the query parameter's meaning (name, symbol, category) but adds no new detail beyond the schema. Baseline 3 is appropriate since the schema already handles parameter semantics.

  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: searching DeFi protocols by name, symbol, or category, with results ranked by TVL. It also provides concrete examples ('lending', 'dexes', 'aave') and distinguishes itself from siblings like get_protocol (specific protocol) and get_chains_tvl (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 gives explicit usage context: how to search (by name, symbol, category) and the empty-query fallback for top protocols. It implies when to use this tool versus others (e.g., for broad searches rather than specific details), though it doesn't explicitly name alternatives.

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

• get_yield_poolsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior, and it does state the tool sorts by APY and offers filters. However, it does not mention return fields, pagination, default limit, or data availability, leaving the response format ambiguous. The added context about avoiding risky pools is useful but not sufficient to fully cover the behavior.

  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 sentences, front-loaded with the core purpose, and provides filtering options in a compact, readable format. Every sentence contributes meaning without redundancy.

  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?

  The tool is simple with all parameters optional and fully described in the schema, but there is no output schema. The description does not explain the return value structure beyond 'pools by APY,' and does not mention the limit parameter or default behavior. This leaves some gaps for an agent trying to fully understand the tool's capabilities.

  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 coverage is 100%, so the baseline is 3. The description enhances meaning by providing explicit examples for chain and project (e.g., 'Ethereum', 'aave') and explaining the purpose of minTvlUsd ('to avoid tiny risky pools'), which adds value beyond the schema. The limit parameter is not discussed, but the schema already covers its default and constraints.

  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 returns 'Top DeFi yield / farming pools by APY,' specifying the resource (yield/farming pools) and the sorting criterion (APY). This distinguishes it from sibling tools like get_token_prices, get_stablecoins, and get_protocol, which address different data types.

  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 when to use it (for yield/farming opportunities) and provides concrete filtering guidance with examples ('Ethereum', 'aave') and the rationale for the minimum TVL filter ('to avoid tiny risky pools'). It does not explicitly name alternatives, but the sibling tools are clearly distinct, and the context is clear.

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

• get_token_pricesA
  4.2/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 burden. It discloses the input format and that it returns USD prices, but doesn't mention output structure, error behavior, rate limits, or read-only status. This is acceptable for a simple lookup but not comprehensive.

  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 sentences, no fluff. The first states purpose, the second provides formatting directives. Every word adds value.

  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 single-parameter tool with no output schema, the description covers the essential input mechanics well. It lacks an explicit return-structure description, but the phrase 'Current USD price' implies the output. A small gap given no 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?

  The schema only says 'Comma-separated DefiLlama coin ids'. The description adds meaningful examples ('coingecko:bitcoin' and 'ethereum:0x...'), showing both accepted forms and clarifying the chain:contract pattern, which goes 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 opens with 'Current USD price for one or more tokens', providing a specific verb+resource and clear scope. It distinguishes itself from sibling tools (get_chains_tvl, get_protocol, get_yield_pools, etc.) by focusing on token pricing.

  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 explicitly teaches the caller how to format the input, including examples of both supported formats. It does not explicitly state when not to use the tool or name alternatives, but the purpose is unambiguous and the usage context is clear.

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

• get_protocolA
  4.5/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 explicitly lists the returned data (TVL, 1d/7d change, chains, category), giving a concrete picture of the tool's output. While it doesn't mention error handling or edge cases, for a simple read-only getter this is adequate and goes beyond a bare schema.

  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 one concise sentence that front-loads the primary action and includes essential examples, without any filler or repetition of the schema. Every word adds value, making it highly scannable for an agent.

  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 a single-parameter tool with no output schema, the description fully covers what the tool does and what it returns. It names all relevant data fields and distinguishes the tool from siblings. There is no additional context needed for an agent to 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 input schema already covers the single 'name' parameter with a description. The tool description adds semantic richness by clarifying that the name should be a specific protocol (e.g., 'Aave', 'Uniswap', 'Lido') and implies exact naming, which helps the agent supply a valid value. This exceeds the schema's minimal explanation.

  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: 'Get current TVL, 1d/7d change, chains, and category for a single DeFi protocol by name.' It uses a specific verb ('Get'), identifies the resource ('single DeFi protocol'), and provides concrete examples ('Aave', 'Uniswap', 'Lido'), which distinguishes it from sibling tools like search_protocols or get_chains_tvl.

  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 phrase 'for a single DeFi protocol by name' gives clear context that this tool is appropriate when you already know the exact protocol name, implying a lookup use case. However, it does not explicitly mention alternatives or when not to use it, 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.