Server Quality Checklist

Tool Scores

• get_market_regimeA
  4/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint and destructiveHint, so the description's 'read-only' adds little. However, it adds valuable behavioral context: live exchange API dependency, the composite nature of the verdict (trend/ranging blended with cross-venue funding sentiment), and a verified track record via performance and merkle anchor references.

  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, front-loaded with the return value, and no filler. Each sentence contributes a distinct piece of information: the output, the methodology, and the trusted/verification characteristics.

  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 classifier with three parameters and no output schema, the description sufficiently conveys the return concept and input domain. It does not specify the confidence value format or exact response shape, but the output enumeration and annotations largely cover what an agent needs to call 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%, so the schema already documents coin, exchange, and timeframe. The description adds a small amount of context by framing the tool as targeting perpetual futures, but it does not materially extend parameter meaning beyond the schema.

  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 names the exact resource (market regime for one crypto perpetual futures), enumerates the possible regime values (TRENDING_UP, TRENDING_DOWN, RANGING, VOLATILE), and specifies the returned fields (confidence and strategy hint). This clearly differentiates it from sibling trade-call/signal 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?

  Use is implied: call this when a market-regime classification is needed for a coin, exchange, and timeframe. However, there is no explicit guidance about when to prefer this over siblings like get_trade_signal, nor any when-not-to-use conditions.

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

• scan_funding_arbA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: outputs are ranked, include a composite verdict, and are 'on-chain verified merkle anchor' – enriching the behavioral picture beyond the annotations 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only three sentences with the core purpose front-loaded. The second sentence ('AI trading signal...') is somewhat promotional, but the overall structure is efficient and no essential details are buried.

  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 tool with no output schema, the description gives a reasonable sense of what is returned (ranked pairs, spread, separate verdict, merkle anchor). It could be more explicit about output fields, but given the simple params and annotations, it is sufficiently 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 descriptions cover both parameters (limit, minSpreadBps) with defaults and ranges (100% coverage). The description does not add further parameter-level meaning, so 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 clearly states the tool scans cross-venue funding arbitrage and returns ranked per-pair spreads and BUY/SELL/HOLD verdicts. The specific verb 'scan' and resource 'funding arbitrage' distinguish it from siblings like scan_trade_calls and get_trade_call.

  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 names related tools (get_trade_call, get_market_regime) providing useful alternatives for specific needs. However, it does not explicitly contrast with scan_trade_calls or mention when not to use this tool, falling just short of full guidance.

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

• scan_trade_callsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only: reads live exchange APIs, places no orders,' adding external-live-data context beyond the annotations. It also discloses that results come with confidence and market regime. No contradiction; the only missing behavioral detail is latency or rate-limit expectations.

  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 tight sentences: the first states the core action and scope, the second routes to the sibling, and the third confirms safety. Every sentence earns its place and the most decision-relevant information is front-loaded.

  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 explains the broad return shape: ranked trade calls with confidence and market regime. Combined with the rich parameter schema and the includeReasoning parameter describing per-call enrichment, the agent has enough context to invoke correctly. A more explicit output-shape example would push this to 5.

  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%, and every parameter is documented with defaults, ranges, enums, and domain meaning. The description adds no parameter-specific detail, but the schema carries the full burden. 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 names a specific verb ('Returns'), a specific resource ('ranked BUY SELL HOLD trade calls across the top crypto perpetual futures by open interest'), and the differentiating scope ('one scan for whole-market coverage'). It clearly distinguishes itself from get_trade_call without requiring the reader to open the schema.

  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?

  Explicitly states when to use this tool ('Use this for breadth') and names the alternative for a different need ('use get_trade_call for per-coin depth and reasoning'). This gives an agent concrete routing guidance between siblings.

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

• chat_knowledgeA
  4.7/5.0
  Behavior5/5

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

  Despite annotations already declaring read-only, the description adds valuable operational context beyond them: it calls an LLM (implying cost/latency), has no other side effects, and lists specific quota limits per plan (Free 10, Starter 50, Pro 200, Enterprise 2000). This exceeds the annotation baseline.

  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 three concise sentences, each with a distinct purpose: what it does, when to use it (and when not), and operational constraints (read-only, quota). No redundant or filler content.

  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?

  The description, combined with a fully documented schema and annotations, covers the tool's return type, use cases, alternatives, quota, and safety profile. Since there is no output schema, the explicit mention of 'synthesized natural-language answer with citations' sufficiently communicates the expected response.

  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 provides 100% coverage for both parameters (question with length constraints, model with enum options). The description adds no additional parameter semantics, which is the expected baseline when schema coverage is high.

  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 ('Returns'), identifies the resource ('AlgoVault knowledge bundle'), and specifies the output ('synthesized natural-language answer with citations'). It also explicitly distinguishes the tool from the sibling search_knowledge by contrasting LLM synthesis vs. raw ranked snippets.

  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?

  Clear usage guidance is provided: 'Use when you need an explanation, code pattern, or how-to', and an explicit alternative is named ('for raw ranked snippets without LLM synthesis use search_knowledge'), including the trade-off that it is faster and has no quota cost.

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

• get_trade_callA
  4.7/5.0
  Behavior5/5

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

  Even though readOnlyHint=true already exists, the description adds meaningful behavioral detail: it reads live exchange APIs, places no orders, has a verified track record, and is on-chain merkle anchored. This is valuable 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?

  Four tight sentences: core output first, scope and alternative next, then safety and verification. No filler or redundant restatement of the schema.

  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 read-only single-asset tool with fully documented parameters and enums, the description covers output, scope, alternative, and safety. No output schema exists, but the description names the returned verdict, confidence, and market regime, which is sufficient for correct invocation.

  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%, and each parameter already has explanatory text, so the baseline is 3. The description only adds the single-asset cardinality constraint and does not describe parameter formats beyond the schema.

  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 resource and output: a composite BUY/SELL/HOLD verdict with confidence and market regime for one perpetual contract. It also explicitly distinguishes itself from scan_trade_calls via the 'One asset only' scope, so an agent knows which tool this is.

  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?

  'One asset only; for a whole-market scan use scan_trade_calls' is an explicit when-not and alternative pairing. The read-only note also reinforces when it is safe to call.

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

• search_knowledgeA
  4.7/5.0
  Behavior4/5

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

  Annotations already cover read-only and non-destructive hints. The description adds valuable context: fast BM25 lexical search, no LLM call, no quota cost, and explicitly 'Read-only, no side effects.' This goes beyond the annotation basics, though it doesn't detail result structure or pagination, which is acceptable given the tool's simplicity.

  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 earning its place: functionality, usage timing, and alternative. Front-loaded with the core purpose, then key behavioral notes. No fluff or repetition of schema fields.

  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 read-only, two-parameter tool with no output schema, the description covers purpose, when to use, performance characteristics, safety, and alternative tool. It is sufficiently complete for an agent to select and invoke correctly.

  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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining the query is a natural-language question about specific topics (MCP tools, response shapes, etc.), and reinforces the limit as controlling 'ranked results'. This is more than the schema alone 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?

  The description uses a specific verb ('Returns') and resource ('AlgoVault knowledge bundle') with clear scope: ranked snippets answering questions about MCP tools, response shapes, integration patterns, or code examples. It also explicitly distinguishes itself from sibling chat_knowledge by noting that chat_knowledge provides synthesized natural-language answers.

  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?

  Provides explicit when-to-use guidance: 'Call this BEFORE other tool calls to confirm parameter usage and avoid hallucinating tool shapes.' Also names the alternative: 'For a synthesized natural-language answer use chat_knowledge.' This gives clear context and exclusions.

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

• get_trade_signalA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint=true, openWorldHint=true, and destructiveHint=false; the description adds that it reads live exchange APIs and places no orders, plus mentions a verified track record and on-chain merkle anchor. This goes beyond the annotations and gives useful context about data sources and credibility.

  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 dense but efficient: it front-loads the primary output in the first sentence, then covers single-asset scope, read-only behavior, credibility, and alias relationship. Every sentence contributes operational or routing value with no significant fluff.

  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, but the description adequately explains the return value as a composite verdict with confidence and market regime. It also covers read-only behavior, asset scope, the alternative scan_trade_calls, and the alias to get_trade_call, making the tool self-sufficient for an agent to invoke correctly.

  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 parameters are already well documented. The description adds meaningful scope constraints not explicit in the schema, such as 'one asset only' and 'crypto or tokenized-stock perpetual futures,' which clarifies how the coin parameter should be interpreted beyond the schema wording.

  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 returns a composite BUY/SELL/HOLD trade call with confidence and market regime for one crypto or tokenized-stock perpetual futures asset. It also distinguishes itself from scan_trade_calls by explicitly limiting scope to one asset, and the alias note clarifies its relationship to get_trade_call.

  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 explicitly says 'One asset only' and directs agents to scan_trade_calls for whole-market scans. It also states this tool is an alias of get_trade_call and recommends preferring get_trade_call for new integrations, giving clear when-to-use and 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.