Server Quality Checklist

Tool Scores

• usenami_funding_currentA
  4/5.0
  Behavior4/5

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

  Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds useful context: covers 30+ venues and cost per call, enhancing transparency without 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?

  Three concise sentences: purpose, coverage, cost. Every sentence adds value, front-loaded with primary action.

  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?

  Adequate for a simple read-only data retrieval tool with a single optional parameter and no output schema. Could mention return format, but not critical given clarity.

  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?

  Input schema has 100% coverage with clear description of the optional symbol parameter. Description merely reiterates this, adding no new meaning.

  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 uses specific verb 'Returns' and resource 'current funding rates per venue'. Clearly distinguishes from sibling tools like usenami_perp_funding_spread by focusing on current rates.

  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?

  Provides context for when to use (specific symbol or all symbols) and cost guidance, but does not explicitly state when not to use or compare with alternative sibling tools.

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

• usenami_perp_funding_spreadA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the tool's safety profile is clear. The description adds the cost ($0.001 USDC per call) and states it returns a snapshot with specific components (spread in basis points). It does not contradict annotations, and provides valuable additional behavioral context beyond what annotations cover.

  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 extremely concise: two sentences plus a cost note. It immediately states the main function, then details the output components. Every sentence adds value with no redundancy. Front-loaded with the core purpose.

  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 snapshot tool with one parameter and no output schema, the description covers purpose, output components, cost, and usage context (arbitrage). Minor gaps include lack of error handling for invalid tickers or network issues, but these are not critical given the tool's simplicity and the schema's validation. Overall, it provides sufficient context for an agent to use 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?

  The only parameter 'ticker' is fully covered in the input schema with a description, pattern, and example. The description does not add any further meaning about the parameter beyond what the schema provides. Schema coverage is 100%, so baseline 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 uses specific verbs ('Returns the cross-venue funding-rate spread snapshot') and identifies the resource (base ticker). It clearly explains that it identifies long-side and short-side venues and reports the spread in basis points, which distinguishes it from siblings like usenami_funding_current (which likely returns a single venue's rate). The arbitrage context further clarifies its unique role.

  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 funding-rate arbitrage by mentioning 'directional edge', but it does not explicitly state when to use this tool vs. alternatives (e.g., usenami_funding_current). There are no 'when-not-to-use' statements or comparisons to sibling tools. The usage context is implied but not formally guided.

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

• usenami_rwa_perp_coverageA
  4.1/5.0
  Behavior3/5

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

  Annotations already cover read-only and idempotent nature. Description adds cost and venue details, but doesn't disclose response format or potential rate limits. Adequate addition beyond 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?

  Two sentences conveying all key info: purpose, scope, filter, and cost. No fluff, front-loaded with the main action.

  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?

  For a simple query tool with one optional parameter and no output schema, the description covers the return subject, scope, asset classes, filter, and cost. Complete for the tool's complexity.

  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 covers 100% of the single parameter with enum and case-insensitive description. Description merely restates the optional filter, adding no new semantic value.

  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?

  Clearly states the tool returns RWA perpetual coverage on specific DEXes, lists sub-venues and asset classes, distinguishing it from sibling tools that deal with funding, venues, etc.

  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?

  Implies usage when needing coverage data for RWA perps on HIP-3 DEXes, with filter options. No explicit when-not-to-use or alternative comparisons, but context is clear.

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

• usenami_venues_listA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context that it is a free endpoint with no payment required, and lists the types of venues tracked. No contradictions.

  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 redundancy. The first sentence states the core purpose, the second provides examples and a note about cost. Front-loaded and efficient.

  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?

  For a parameterless list endpoint with no output schema, the description sufficiently explains what the tool returns. It gives enough detail (types of venues, examples) for an agent to understand the response. No missing information.

  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?

  There are no parameters (schema has no properties). The description adds meaning by explaining the content of the catalog (CEX, DEX, etc.), which is valuable beyond the empty schema. Baseline 4 for 0 params.

  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 as returning a catalog of perpetual futures venues, listing specific examples (CEX like Binance, Bybit; DEX like Hyperliquid, dYdX). It distinguishes from sibling tools, which deal with funding, spread, etc.

  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 obtaining the list of supported venues, but does not provide explicit when/not-to-use guidance or compare with sibling tools. Context from sibling names suggests differentiation, but the description itself lacks direct usage instructions.

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

• usenami_perp_oracle_familiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the scope (30+ venues) and cost ($0.001 USDC), which is behavioral information beyond the annotations. No contradictions.

  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?

  Three sentences, each purposeful: first states the action, second provides usage context, third mentions cost. No fluff, front-loaded with key information.

  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 tool's simplicity (zero parameters, no output schema), the description fully covers what the tool does, why it's useful, and the cost. It is sufficient for an agent to decide whether to invoke it.

  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?

  Input schema has no parameters (0 params), so baseline is 4. The description does not need to explain parameters, and it adds meaning by indicating what the output will be used for, though parameter-specific semantics are not applicable.

  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 clearly states the tool returns oracle family classification for 30+ perp venues, which is a specific verb+resource. It distinguishes itself from sibling tools (funding, spread, coverage, health, list) by focusing on price source families.

  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?

  Description provides context for usage: useful for basis-risk awareness in cross-venue strategies and highlights that venues sharing price sources offer no genuine arbitrage edge. It implicitly guides when to use this tool (when assessing arbitrage opportunities) but does not explicitly name exclusion criteria or alternatives.

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

• usenami_venues_healthA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying what the tool returns (timestamps and freshness status) and confirming it's free, providing useful behavioral context beyond the 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?

  The description is two concise sentences, front-loaded with purpose and usage context. Every sentence adds value without 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?

  For a simple parameterless tool with comprehensive annotations, the description fully covers purpose, usage guidance, and output description (timestamps and freshness status). It is complete for the tool's complexity.

  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 zero parameters, and schema coverage is 100%. The description does not need to add parameter info; baseline for 0 parameters is 4.

  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 explicitly states 'Returns last-update timestamps and freshness status for each tracked venue', providing a specific verb and resource. It also distinguishes from siblings like usenami_funding_current by focusing on venue freshness, making the tool's unique purpose clear.

  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 says 'Use this to verify that data is current before paying for a snapshot', giving clear guidance on when to use. It also mentions 'Free endpoint, no payment required', implying cost context but lacks explicit when-not or alternative tools.

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