Server Quality Checklist

Tool Scores

• get_index_batchA
  4.4/5.0
  Behavior5/5

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

  Adds substantial behavioral detail beyond the annotations: individually signed successful rows, per-symbol errors for unavailable rows, unsigned surrounding metadata, and no automatic retries. Describes the partial-success model and verification requirement with no contradiction to readOnlyHint=true.

  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?

  Five sentences, each carrying distinct information: purpose, return shape, tier limits, verification step, retry policy. No fluff or redundancy, and the core action is front-loaded in the first sentence.

  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?

  Even without an output schema, the description sketches the return envelope (observations, individually signed rows, per-symbol errors) and the follow-up verification step. A more concrete response-field description would improve completeness, but for a simple one-parameter read tool it is largely 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?

  With schema description coverage at 0%, the description partially compensates by adding the tier-dependent limit caveat ('Your API tier may allow fewer symbols') that the schema's maxItems=100 does not capture. However, it does not clarify symbol format or normalization expectations beyond what the schema pattern already enforces.

  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?

  Description states a specific verb ('Read'), a concrete resource ('crypto symbols'), and scope ('up to 100 in one /api/index/v1/batch request'). The batch nature plus per-symbol error handling clearly distinguishes this from siblings like get_index_price and get_settlement_print.

  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?

  Clear context for when to call it (multi-symbol reads up to 100) with a post-call workflow ('Verify each successful row with verify_print') and a tier-limits caveat. However, it never explicitly names get_index_price as the single-symbol alternative or states when-not to use the batch tool.

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

• list_index_assetsA
  4.4/5.0
  Behavior5/5

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

  Annotations already mark the tool as read-only and non-destructive, and the description adds significant behavioral context beyond that: catalog rows are unsigned, total is not a count of fresh prices, availability changes, and pagination is bounded and manual. This goes well beyond what the structured annotations alone communicate, with no contradiction.

  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 four tight sentences with no filler. The action and endpoint are front-loaded, and every subsequent sentence adds a distinct, decision-relevant fact: unsigned data, alternatives, total semantics, and pagination behavior.

  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 read-only paginated list tool with no output schema, the description covers endpoint, purpose, unsigned data caveat, total semantics, pagination behavior, and sibling alternatives. It falls slightly short by not explicitly describing the response structure or stating that limit/offset are the paging controls, though these are implied.

  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 0%, so the burden falls on the description. It provides indirect semantic clues: 'bounded page' implies limit/offset, 'coverage status' maps to status, and 'measured cadence' maps to band. However, it never explicitly defines each parameter or explains how to use the enum values, leaving some ambiguity.

  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 a specific verb and resource: 'Read one bounded page from /api/index/v1/verity/catalog.' It clearly states what the tool does—discover crypto symbols, coverage status, and cadence—and differentiates it from siblings by explicitly pointing to get_index_price and get_index_batch for signed receipts.

  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 concrete guidance on when to prefer alternatives: 'use get_index_price or get_index_batch for signed receipts.' It also warns that there is no automatic pagination, implying the caller must handle paging. It does not explicitly contrast with get_settlement_print or verify_print, but the primary use case is clear.

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

• get_index_priceA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and destructiveHint annotations, the description explains important behavior: the response is signed, includes a kid and sig, some fields are not covered by the v1 signature, priceText must be preserved exactly, and a stale response should never be interpreted as zero. This significantly helps the agent interpret results correctly.

  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 information-dense yet well-structured: purpose and endpoint first, then return fields, then critical caveats about signature coverage and error semantics. Every sentence adds value and nothing is redundant or 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?

  With no output schema, the description supplies a full list of return fields and explains the signature boundary. It also covers asset discovery, exact-preservation requirements for verify_print, and stale-response behavior. For a one-parameter read-only tool, nothing essential is missing.

  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 already fully documents the single symbol parameter with a pattern, length constraints, and examples, so the description does not need to compensate. The description adds no parameter-specific formatting guidance, but at 100% schema coverage the 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 opens with a specific verb and resource: 'Get a current signed crypto index price from /api/index/v1/price.' It also distinguishes itself from siblings by pointing to list_index_assets for asset discovery and verify_print for exact priceText preservation, so an agent can tell this tool apart without opening schemas.

  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 clear usage context: this tool retrieves a single signed index price, and coverage changes should route the agent to list_index_assets. It also warns that a stale/unavailable response means no current price, never zero. It does not explicitly mention get_index_batch as an alternative for multiple symbols, but the provided guidance is still strong.

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

• verify_printA
  4.5/5.0
  Behavior5/5

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

  Beyond the read-only and idempotent annotations, the description discloses detailed runtime behavior: public key ring fetching with caching and refresh policy, kid-based key selection, no API key sent, and what valid=true does and does not authenticate. This is strong 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 compact and information-dense, with four sentences covering purpose, canonical bytes, key handling, and validation semantics. No fluff or redundant phrasing is present.

  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 description covers the core verification flow, key management, and the meaning of valid=true, which is sufficient given the lack of an output schema. It does not explicitly specify error behavior on missing keys or network failures, but those are secondary to the main verification purpose.

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

  Parameters5/5

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

  The description clarifies how parameters map to the canonical byte layout: 'pulse-index-v1\n<symbol>\n<priceText or String(price)>\n<at>\n<grade>'. It also explains the optional kid semantics and the role of the signature, adding meaning beyond the schema definitions.

  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 a clear, specific action: 'Verify a signed print locally with ECDSA P-256/SHA-256.' It identifies both the operation (verify) and the resource (a signed print), and the cryptographic context distinguishes it from the sibling getter tools.

  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 explains what the tool does but does not explicitly state when to prefer it over the sibling getter tools, nor does it give an alternative. It implies verification use cases but stops short of clear selection guidance.

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

• get_settlement_printA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds genuinely non-obvious details: the result is signed, deltaMs is not part of the signed content, sampling/retention are bounded, and metadata is not signed. 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?

  Compact and front-loaded: the first sentence states the purpose, and each following sentence adds essential operational detail—time formats, deltaMs, sampling limitations, and verify_print preservation. No filler or redundancy.

  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?

  Even without an output schema, the description covers the relevant response semantics: deltaMs, priceText, kid, and signed vs. non-signed metadata. This is enough for an agent to invoke the tool and correctly feed output into verify_print.

  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 describes symbol but not at. The description compensates by explaining the accepted formats for at (ISO-8601 or epoch milliseconds) and the meaning of deltaMs. It adds meaningful semantics beyond the schema, though it does not elaborate on symbol beyond what the schema already provides.

  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?

  States a specific verb plus resource: 'get the recorded signed index print nearest a requested time' from '/api/index/v1/print'. This clearly distinguishes it from live-read siblings while specifying the exact operation.

  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 important usage context: a recorded print may differ from a live read, deltaMs measures distance from the requested time, and priceText/kid should be preserved for verify_print. It does not explicitly name alternatives like get_index_price, but effectively implies when a signed historical print is needed.

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