Server Quality Checklist

Tool Scores

• getPoolTransactionsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions required parameters but doesn't disclose key behavioral traits: it doesn't specify if this is a read-only operation (implied by 'Get' but not explicit), what the output format looks like (critical with no output schema), rate limits, authentication needs, or error conditions. The description adds minimal context beyond basic functionality.

  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 core purpose and followed by prerequisites. Every word earns its place: 'Get recent transactions for a specific pool' establishes the action, 'Shows swaps, adds, removes' clarifies scope, and 'Requires network and pool address' states needs. No wasted verbiage.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete for a tool with 5 parameters and complex behavior (transaction listing with pagination). It lacks details on return values, error handling, rate limits, and how transactions are filtered or sorted. For a read operation with pagination and no structured output, more context is needed to guide the agent effectively.

  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 documents all 5 parameters thoroughly. The description adds marginal value by noting that network and pool address are required, but doesn't provide additional meaning beyond what's in the schema (e.g., explaining transaction types further or pagination behavior). Baseline 3 is appropriate when schema does heavy lifting.

  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 clearly states the verb ('Get') and resource ('recent transactions for a specific pool'), specifying the types of transactions included (swaps, adds, removes). It distinguishes from siblings like getPoolDetails or getPoolOHLCV by focusing on transaction history rather than pool metadata or price data. However, it doesn't explicitly contrast with all siblings (e.g., search might also return transactions).

  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 stating 'Requires network and pool address,' indicating prerequisites. It doesn't provide explicit when-to-use vs. when-not-to-use guidance or name specific alternatives among siblings. The agent must infer that this is for transaction history of a known pool, while getDexPools or getNetworkPools might be for discovery.

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

• getStatsB
  3.2/5.0
  Behavior2/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 of behavioral disclosure. It states what data is retrieved but doesn't describe behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, data freshness, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.

  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 core purpose ('Get high-level statistics') and specifies the resource and data points. Every word earns its place with no redundancy or waste, 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.

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what data is retrieved but lacks context on behavioral aspects (e.g., read-only nature, performance). Without annotations or output schema, the description should ideally provide more completeness for safe agent use, but it meets minimum viability.

  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 schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond the schema, but it appropriately doesn't mention any parameters. Baseline 4 is applied as per rules for 0 parameters.

  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 clearly states the tool's purpose with a specific verb ('Get') and resource ('high-level statistics about the DexPaprika ecosystem'), including what statistics are retrieved (total networks, DEXes, pools, and tokens). It distinguishes from siblings by focusing on aggregated ecosystem statistics rather than specific entities like individual networks, pools, or tokens. However, it doesn't explicitly differentiate from all siblings (e.g., 'getNetworks' might overlap conceptually).

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools like 'getNetworks' (which might list networks without statistics) or 'search' (which might filter data). Usage is implied by the purpose but not explicitly stated.

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

• getTokenPoolsB
  3.4/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 but only states the basic purpose. It doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior beyond parameters, or what the response format looks like. Significant gaps exist for an 8-parameter tool.

  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 that are front-loaded with the core purpose. The second sentence adds practical context without redundancy. Every sentence earns its place with zero waste or unnecessary elaboration.

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

  Completeness2/5

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

  For a complex tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It states the basic purpose but lacks behavioral context, response format details, error handling information, or usage boundaries that would help an agent invoke it 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%, providing detailed documentation for all 8 parameters. The description adds no parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 when schema does the heavy lifting but doesn't compensate with additional semantic context.

  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 verb 'Get' and resource 'liquidity pools containing a specific token on a network', with the specific purpose 'finding where a token is traded'. It distinguishes from siblings like getDexPools (general pools), getNetworkPools (network-level pools), and getTokenDetails (token metadata).

  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 ('Great for finding where a token is traded') but doesn't explicitly state when to use this tool versus alternatives like getDexPools or getNetworkPools. No explicit exclusions or prerequisites are mentioned, leaving usage guidance at an implied level.

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

• getPoolDetailsA
  3.5/5.0
  Behavior2/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 of behavioral disclosure. It mentions a requirement ('Requires network ID from getNetworks'), which adds some context, but fails to describe other key traits such as whether this is a read-only operation, potential rate limits, error conditions, or the format of the returned details. For a tool with no annotations, this leaves significant gaps in understanding its 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 concise and front-loaded with the core purpose in the first sentence, followed by a prerequisite in the second. Every sentence earns its place by providing essential information without redundancy or unnecessary details.

  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 complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and prerequisites but lacks details on behavior, output format, and error handling. With no output schema, the description should ideally hint at what 'detailed information' includes, but it doesn't, leaving room for improvement in contextual coverage.

  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 description mentions the parameters 'network ID from getNetworks' and 'pool address', aligning with the input schema. Since schema description coverage is 100%, the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, such as hinting at the source for the network ID, but doesn't provide additional semantics like examples or constraints not in the schema.

  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 clearly states the verb 'Get' and the resource 'detailed information about a specific pool', which is specific and actionable. However, it doesn't explicitly differentiate this tool from similar siblings like getPoolOHLCV or getTokenPools, which might also retrieve pool-related data but with different scopes or details.

  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 by stating 'Requires network ID from getNetworks', which guides users on prerequisite data and hints at a workflow. It doesn't explicitly mention when not to use this tool or name alternatives among siblings, but the context is sufficient for basic usage.

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

• getDexPoolsA
  3.7/5.0
  Behavior2/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. While it mentions the prerequisite tools, it doesn't describe what 'Get pools' actually returns (e.g., list of pool objects, metadata), whether it's a read-only operation, pagination behavior beyond the schema, rate limits, or authentication requirements. For a tool with 6 parameters and no annotation coverage, this is a significant gap.

  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 serve a clear purpose: the first states the tool's function, the second provides essential usage guidance. There's no wasted language or 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?

  For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. While it provides good usage guidance, it lacks critical behavioral context about what the tool returns, error conditions, or operational constraints. The high schema coverage helps, but the description should do more given the tool's complexity and lack of structured metadata.

  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 description coverage is 100%, so all parameters are well-documented in the schema itself. The description adds minimal value beyond the schema by implying that network and dex parameters should come from specific sibling tools, but doesn't provide additional semantic context about the parameters' meaning or usage.

  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 clearly states the action ('Get pools') and resource ('from a specific DEX on a network'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like getNetworkPools or getTokenPools, which appear to serve similar pool-related functions.

  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?

  The description provides explicit guidance on when and how to use this tool: 'First use getNetworks, then getNetworkDexes to find valid DEX IDs.' This gives clear prerequisites and workflow context, helping the agent understand the proper sequence of operations.

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

• getNetworkDexesA
  3.7/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 discloses that the tool requires a network ID from getNetworks, which is useful context. However, it doesn't describe behavioral traits like whether it's read-only, potential rate limits, error handling, or the format of returned DEX data. The description adds some value but lacks comprehensive behavioral 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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second provides essential usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to understand.

  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 moderate complexity (3 parameters, 1 required), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers purpose and prerequisites but lacks details on return values, error cases, or behavioral constraints. It's adequate as a minimum viable description but could be more comprehensive for a tool with pagination and network dependencies.

  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 documents all parameters (network, page, limit) with descriptions and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as examples of DEX types or pagination behavior. Baseline 3 is appropriate as the schema handles the heavy lifting.

  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 clearly states the tool's purpose: 'Get available DEXes on a specific network.' It specifies the verb ('Get') and resource ('DEXes'), and distinguishes it from siblings like getNetworks (which provides network IDs) and getDexPools (which focuses on pools within DEXes). However, it doesn't explicitly contrast with all siblings, such as getNetworkPools, which might overlap in network focus.

  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: 'First call getNetworks to see valid network IDs.' This gives a prerequisite and distinguishes it from getNetworks. It implies when to use this tool (after obtaining network IDs) but doesn't explicitly state when not to use it or mention alternatives like getNetworkPools for pools instead of DEXes.

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

• getTokenDetailsA
  3.7/5.0
  Behavior2/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 states the tool retrieves 'detailed information' but doesn't specify what details are included (e.g., token name, symbol, decimals, supply), whether it's a read-only operation, potential rate limits, or error conditions. For a tool with no annotation coverage, this leaves significant behavioral 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 with zero waste. The first sentence states the purpose, and the second provides crucial usage guidance. Every word earns its place, and information is front-loaded effectively.

  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 no annotations and no output schema, the description is incomplete. It covers purpose and usage prerequisites well, but lacks details on what 'detailed information' includes, behavioral traits, or response format. For a tool with 2 parameters and no structured output documentation, this leaves the agent guessing about the return values and operational constraints.

  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 clearly documented in the schema (network ID and token address). The description adds minimal value beyond the schema by mentioning 'network IDs from getNetworks' and 'token address or identifier', but doesn't provide additional context like format examples beyond what's in the schema. 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and resource 'detailed information about a specific token on a network', making the purpose unambiguous. It distinguishes from siblings like getNetworks (which lists networks) and getTokenPools (which focuses on pools). However, it doesn't explicitly differentiate from getPoolDetails or getTokenPools in terms of scope.

  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?

  The description provides explicit guidance: 'First use getNetworks to get valid network IDs.' This tells the agent when to use this tool (after obtaining network IDs) and references a specific sibling tool (getNetworks) as a prerequisite. It establishes a clear sequence of operations.

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

• getPoolOHLCVA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Requires network and pool address' which indicates prerequisites, but doesn't mention rate limits, authentication needs, error conditions, or what happens with invalid parameters. The description doesn't contradict annotations (none exist), but provides only basic operational 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?

  Two sentences with zero waste. First sentence states purpose and use cases, second sentence highlights key requirements. Every word serves a clear purpose, and the most critical information (what it does and what it needs) is front-loaded.

  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?

  For a 7-parameter tool with no annotations and no output schema, the description provides basic operational context but lacks details about return format, error handling, or performance characteristics. The schema covers parameters well, but the description doesn't compensate for the absence of output schema or behavioral annotations, leaving gaps in complete understanding.

  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 description coverage is 100%, so all parameters are well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'Requires network and pool address' (which aligns with required parameters) and framing the tool's purpose. Since schema does the heavy lifting, baseline would be 3, but the description's concise reinforcement of key requirements earns a slightly higher score.

  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 historical price data'), the resource ('for a pool'), and the data format ('OHLCV'). It distinguishes this tool from siblings like getPoolDetails or getPoolTransactions by focusing on price history rather than general pool information or transaction data.

  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 mentions 'essential for price analysis, backtesting, and visualization' which implies usage contexts, but doesn't explicitly state when to use this tool versus alternatives like getPoolDetails for non-price information or getStats for aggregated statistics. No explicit exclusions or comparisons to siblings are provided.

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

• getNetworkPoolsA
  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 full burden. It mentions this is for 'top liquidity pools' and implies pagination via context, but doesn't disclose key behavioral traits like rate limits, authentication needs, error handling, or what 'top' means (e.g., by volume, activity). The description adds some context about network specificity but lacks details on mutation safety 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 front-loaded with the primary function in the first sentence, followed by usage guidance. It uses two concise sentences with zero waste—every phrase earns its place by clarifying purpose and distinguishing from alternatives, making it highly 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 moderate complexity (5 parameters, no output schema, no annotations), the description is fairly complete: it covers the core purpose and usage guidelines. However, it lacks details on behavioral aspects like what data is returned or error conditions, which would be helpful since there's no output schema. It's adequate but has minor gaps in full context.

  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 documents all parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'network' beyond being required or clarify 'page'/'limit' usage). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract.

  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 verb ('Get') and resource ('top liquidity pools on a specific network'), making the purpose specific. It explicitly distinguishes this tool from potential alternatives like 'getTopPools' or 'getAllPools' by stating this is the 'MAIN way to get pool data' and there is 'NO global pools function', which effectively differentiates it from sibling tools.

  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?

  The description provides explicit guidance on when to use this tool versus alternatives: it states 'Use this instead of any "getTopPools" or "getAllPools" concepts' and emphasizes it's the 'MAIN way to get pool data'. This gives clear direction on tool selection, though it doesn't mention specific sibling tools like getDexPools or getTokenPools, the general exclusion is well-defined.

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

• searchA
  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 full burden of behavioral disclosure. It mentions the tool searches 'across ALL networks' and is a 'good starting point,' which adds useful context about scope and intent. However, it lacks details on rate limits, authentication needs, or response format, leaving gaps in behavioral understanding for an 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?

  The description is front-loaded and concise, consisting of two sentences that efficiently convey purpose and usage guidelines without unnecessary details. Every sentence earns its place by providing critical information for tool selection and invocation.

  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 low complexity (1 parameter, 100% schema coverage) and lack of annotations/output schema, the description is reasonably complete. It covers purpose, scope, and usage context well, though it could improve by addressing behavioral aspects like response format or limitations to fully compensate for missing structured 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?

  Schema description coverage is 100%, so the schema already documents the single 'query' parameter with a clear description. The description adds minimal value beyond the schema by implying the query can target 'name, symbol, or address,' but this is redundant with the schema's example. Baseline 3 is appropriate as 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 tool's purpose with specific verbs ('search across ALL networks') and resources ('tokens, pools, and DEXes'), distinguishing it from sibling tools that focus on specific networks or details. It explicitly mentions the scope ('ALL networks') and searchable attributes ('by name, symbol, or address'), making the 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 Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('Good starting point when you don't know the specific network'), which differentiates it from sibling tools like getNetworkDexes or getTokenDetails that require network knowledge. It effectively tells the agent to use this for broad searches and implies alternatives for network-specific queries.

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

• getNetworksA
  4.6/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 effectively describes the tool's behavior as a read-only operation that returns network IDs, though it lacks details on response format, pagination, or error handling. The 'REQUIRED FIRST STEP' emphasis adds useful context about its role in the workflow.

  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 highly concise and well-structured, using only two sentences that front-load critical information ('REQUIRED FIRST STEP') and avoid any wasted words. Every sentence adds value by explaining the tool's purpose and its strategic use in the workflow.

  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 simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It clearly explains what the tool does and when to use it, though it could enhance completeness by specifying the exact return format (e.g., list structure) or error scenarios, which are minor gaps.

  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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without redundant parameter details, earning a baseline score above 3 for clarity in a parameterless context.

  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 all supported blockchain networks') and resource ('blockchain networks'), distinguishing it from siblings like getNetworkDexes or getNetworkPools that focus on specific network data. It explicitly identifies what it returns ('network IDs like "ethereum", "solana", etc.'), making the 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 Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('Always call this first to see available networks before using any network-specific functions') and why ('to see available networks'), effectively distinguishing it from siblings that require network IDs. It implicitly excludes usage for other purposes by framing it as a prerequisite step.

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