Server Quality Checklist

Tool Scores

• get_pricesA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that reads are from pool state, mentions the gross spread caveat, and notes API key requirements. However, it states data is read 'at a stated block number' but the schema has no block parameter, creating a confusing discrepancy. This undermines transparency despite other useful 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 long but every sentence earns its place: it front-loads the core purpose, lists returns, gives usage guidance, includes a vital caveat about gross spreads, and provides auth details. It is well-structured with no filler or repetition.

  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 and lack of output schema, the description covers return values, usage context, spread caveats, and authentication. The only notable gap is the misleading reference to a 'stated block number' that doesn't correspond to any parameter, slightly reducing completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds minimal parameter value, only reinforcing pair order via 'quote token per 1 base token'. Critically, it introduces a non-existent 'stated block number' that is not in the schema, confusing parameter semantics. This negative contribution lowers the score below the baseline.

  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: 'Live price of one trading pair at EVERY DEX venue on a chain that holds a pool for it'. It uses a specific verb and resource scope, and explicitly distinguishes from get_spreads by advising 'For ranking opportunities across a whole chain, use get_spreads instead.' This makes the purpose unambiguous and differentiates it from siblings.

  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 when-to-use guidance: 'Use this when you need the actual number a swap would price against on a specific venue, or to compare one pair across venues.' It also names an alternative: 'For ranking opportunities across a whole chain, use get_spreads instead.' This clearly scopes usage and directs to the correct alternative.

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

• get_chainsA
  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 behavioral disclosure burden. It transparently explains the authentication-dependent behavior: with a RapidAPI key the full token/venue lists are returned, while without one a public snapshot is used that omits token universes. It also mentions the paid route and free tier availability, adding valuable context beyond the tool's basic operation.

  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 main action and scope, followed by operational details. Every sentence adds meaningful information—output contents, usage ordering, authentication behavior, and key source—with no redundancy. It is appropriately sized for the tool's complexity.

  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 there is no output schema, the description thoroughly explains what the response will include: chains, chain IDs, native assets, pairs, tokens, and DEX venue types. It also covers auth variants, prerequisites, and usage context, making the tool fully understandable without structured output documentation.

  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 schema fully covers the input side. The description compensates by explaining what data the response will contain, which is more than enough for a parameterless tool. No additional parameter semantics are needed.

  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 identifies the tool's purpose: listing all supported blockchains with chain IDs, native assets, default trading pairs, token tickers, and DEX venues. It uses a specific verb ('List every blockchain') and enumerates the exact scope, distinguishing it well from sibling tools like get_pairs or get_prices.

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

  Usage Guidelines4/5

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

  The description explicitly instructs 'Call this first to discover valid chain values for the other tools,' providing clear usage context and positioning it as a prerequisite. However, it does not explicitly state when not to use it or compare it to alternatives, 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.

• get_pairsA
  4.5/5.0
  Behavior5/5

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

  No annotations are present, and the description carries the full burden, excelling at it. It discloses that the tool returns a token universe rather than a fixed list, returns 404 when no pool exists, and falls back to a free snapshot without a RapidAPI key, labeled as such. It also notes the paid RapidAPI key requirement, giving complete behavioral 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 five sentences, each adding a distinct piece of information: main purpose, pair format, universe semantics, fallback behavior, and paid access. It is front-loaded with the core purpose and contains no redundant filler.

  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?

  There is no output schema, so the description must explain what the tool returns, and it does so thoroughly: token tickers, DEX venues, default pair, and the difference between the live universe and the fallback snapshot. It also covers error behavior (404) and authentication requirements, making it complete for a one-parameter tool.

  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 single 'chain' parameter with an enum, descriptions, and a note about numeric IDs not being accepted (100% schema coverage). The description adds contextual value by tying the parameter to chain-specific behavior, but it does not need to repeat the schema. The baseline 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 opens with 'Show what is queryable on a single chain' and explicitly enumerates the returned items: token tickers, DEX venues, and the chain default pair. It distinguishes from sibling get_prices by explaining how pair strings are constructed, making the tool's role unambiguous.

  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 clearly implies usage: it tells users that pairs for get_prices are built from these tickers, so this tool is the prerequisite for constructing price queries. It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide selection.

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

• get_spreadsA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the transparency burden and excels: it discloses ranking by gross USD rather than bps, exclusion of low-liquidity venues, gross vs net numbers, the non-profit/non-advice nature, live vs snapshot timing, response stating data source, and key requirements. This is exemplary behavioral disclosure.

  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?

  Although long, every sentence adds meaningful value: main action, ranking rule, an illustrative example, exclusion rationale, gross/net clarification, live vs snapshot behavior, and access instructions. It is well-structured and front-loaded with the core purpose.

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

  Completeness5/5

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

  Given the absence of an output schema and the presence of four parameters, the description is remarkably complete. It covers input behaviors, output field names, ranking logic, limitations, authentication needs, and response characteristics, leaving no major gaps for an AI agent to operate 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?

  The input schema already provides 100% coverage with detailed descriptions for all parameters, including the live parameter's behavior and the chain enum. The description adds some context about live requiring a key and snapshot timing, but it largely reiterates schema information. Baseline 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's function: 'Sweep a whole chain and rank its cross-venue price dislocations' and enumerates the output fields (buy venue, sell venue, spread in bps, optimal size, gross USD). It distinguishes itself from sibling tools like get_prices by focusing on spread opportunities across venues.

  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?

  Provides explicit guidance on when to use live=true (with RapidAPI key) versus the free hourly snapshot, and explains the ranking metric (gross USD at optimal size). However, it does not explicitly mention alternatives among sibling tools, so it misses the 'when not to use this' aspect.

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