Server Quality Checklist

Tool Scores

• get_top_rankingA
  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 adds the supported exchanges and the time window, but it does not explain the ordering of results, what fields are returned, how `limit` affects the response, or any rate-limit or error behavior. This is thin for an unannotated 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?

  The description is a single front-loaded sentence that names the resource, the required parameter, and the valid choices. Every word earns its place, and the supported exchanges list is immediately useful.

  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 only two parameters, but with no output schema and no annotations, the description does not fully clarify what the returned ranking looks like or whether it is sorted descending by volume. It is adequate for basic invocation but not entirely self-sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both `exchange` and `limit` clearly. The description mostly repeats the exchange options rather than adding new meaning, which matches the baseline score of 3 for full 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 states a specific verb ('Fetch'), a concrete resource ('24-hour volume ranking'), and the target context ('for a specified exchange'). It is clearly distinguishable from sibling tools like get_price and compare_prices, which serve different purposes.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool: whenever the 24-hour volume ranking for one of the supported exchanges is needed. However, it never explicitly contrasts it with get_price, compare_prices, or get_pairs, nor does it mention any exclusions or alternative conditions.

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

• get_pairsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It accurately conveys a read-only fetch operation scoped to an exchange, which is useful. But it does not disclose return shape, pagination, or exchange-specific caveats, though those are relatively minor for this simple 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?

  The description is one front-loaded sentence that immediately states the operation and scope, followed by a compact list of supported exchanges. There is no filler, vague phrasing, or unnecessary 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?

  For a one-parameter read-only tool, the description covers purpose, scope, and valid exchange values. The only notable gap is the lack of an output schema or explicit statement of return format, but the phrase 'tradable pairs' makes the expected result type reasonably inferable.

  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, 'exchange', including the same list of supported values. The description adds no semantic information beyond what the schema already provides, so 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 states a specific verb ('Fetch'), a clear resource ('all tradable pairs'), and the scope ('specified exchange'). It naturally distinguishes this tool from siblings like get_price, compare_prices, and get_top_ranking, which address different data needs.

  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 makes the intended use clear: fetch all pairs for a supported exchange, and the supported-exchange list adds context. However, it does not explicitly say when to prefer this over sibling tools or when it should not be used, so some routing is left to inference.

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

• get_priceA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses that the tool fetches prices 'from each exchange' and enumerates supported exchanges, which is useful. It does not mention output format, failure behavior, rate limits, or how results are structured when multiple exchanges are queried.

  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 built from one action-first sentence plus compact, useful lists of examples and supported exchanges. There is no filler or redundant elaboration, making it easy to scan.

  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 low-complexity tool, the description and schema together provide enough to call it correctly: the symbol is required, exchanges are optional, and supported options are listed. The lack of an output schema means return-value details are not fully specified, but the phrase 'current price... from each exchange' gives a sufficient mental model.

  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 baseline is 3. The description adds examples like 'BTC, ETH, SOL' and repeats the exchange options, but these largely mirror the schema descriptions. It does not add new meaning around symbol normalization, quote currency, or exchange-specific quirks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

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

  The description uses a specific verb and resource: 'Fetch the current price of a specified cryptocurrency from each exchange.' It clearly distinguishes get_price from siblings like get_top_ranking, compare_prices, and get_pairs by focusing on single-asset price lookup across exchanges.

  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 the usage context: when you need a current price for a symbol like BTC or ETH, and it lists supported exchanges. However, it does not explicitly state when to prefer this over compare_prices or get_pairs, nor does it provide when-not-to-use guidance.

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

• compare_pricesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose the core behavior (showing lowest and highest prices), but it does not add context about output structure, data freshness, or possible failure modes. It is not misleading, but it leaves some behavioral gaps unaddressed.

  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 focused sentence followed by examples. It is front-loaded with the action and scope, and every part earns its place with no redundant wording.

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

  Completeness4/5

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

  For a single-parameter comparison tool with no output schema, the description adequately conveys what is returned (lowest and highest prices). Minor gaps like handling of invalid symbols are not critical for a tool this simple, so it is nearly 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%, so the symbol parameter is already documented. The description reinforces that the symbol refers to a tradeable asset and repeats the examples, but adds no new semantic detail beyond what the schema already provides. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

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

  The description uses a specific verb ('Compare') and resource ('price of a specified asset across all exchanges'), clearly distinguishing it from sibling tools like get_price which presumably returns a single price. It also gives concrete examples (BTC, ETH, SOL) that ground the asset concept.

  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 when to use this tool: when you need to compare prices across exchanges and see the lowest/highest values. However, it does not explicitly name alternatives like get_price or state 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.