Server Quality Checklist

Tool Scores

• get_consolidated_priceA
  4/5.0
  Behavior3/5

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

  Discloses it is a read operation aggregating data, returns specific fields. No annotations exist, so description carries full burden. Could mention rate limits or behavior if network is unavailable, but the information provided is adequate for a simple read 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?

  Two sentences, each earning its place: first defines purpose and returns, second gives usage guidance. No fluff, 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?

  Given the tool's simplicity (1 param, no output schema, no annotations), the description covers purpose, returns, and usage context adequately. Minor gap: no mention of what 'freshness in milliseconds' implies or if it's a public endpoint.

  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 coverage is 100% with description for the single parameter. The tool description does not add additional meaning beyond the schema (e.g., format or constraints), 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 clearly states it gets the consolidated Bitcoin price aggregated across the BPE network, returns price in USD, contributor count, and freshness. This is distinct from sibling tools which focus on sentiment, market briefing, funding skew, and ML signals.

  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 when-to-use guidance: 'when an agent or user asks what's the BTC price right now?' and contrasts with individual exchange calls as slower/less authoritative. Does not list exclusions but sufficiently narrows usage.

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

• get_ml_signalA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It details the model type, feature set, and return fields (direction, confidence, regime), and notes horizon evolution behavior. It does not mention auth or rate limits, but for a read-only prediction tool this is adequate.

  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, no wasted words. Front-loaded with the primary action, then model details. Efficient and clear.

  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?

  With one parameter, no output schema, and no annotations, the description sufficiently covers what the tool returns and the model context. It is complete enough for an agent to invoke correctly, though an explanation of output structure could slightly improve.

  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% for the single parameter 'horizon', explaining its behavior and fallback. The tool description adds no extra meaning beyond the schema, 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 clearly states 'Get the current ML prediction for a specified time horizon', with a specific verb and resource. It is distinct from sibling tools like get_sentiment_snapshot or get_consolidated_price.

  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 use for ML signals but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not guidance are provided.

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

• get_funding_skewA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the return format as a 'sorted table' and mentions annualised rates. However, it omits details like data freshness, sources, or error handling, which would be helpful for a read-only 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 concise: two sentences front-loaded with purpose and usage context, with a brief note on return format. Every sentence adds value without redundancy.

  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?

  With no output schema, the description's mention of a 'sorted table' is vague. It lacks specifics on columns, which venues are considered 'major', or whether the data is real-time. For a tool with no parameters, more detail about the output would improve completeness.

  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, so the description does not need to add parameter info. The tool is parameterless, and the description's mention of 'across major venues' implies no filtering, which is consistent.

  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 retrieves perpetual-futures funding rates across major venues, including the max-spread pair, and notes they are annualised. This distinguishes it from sibling tools like get_sentiment_snapshot or get_consolidated_price.

  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 provides explicit use cases: assessing perp-perp arbitrage conditions, basis trades, and overall positioning skew, with a hint that high spread indicates stretched positioning. It does not explicitly state when not to use, but the context is clear.

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

• get_sentiment_snapshotA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses behavioral traits such as the ranges of each indicator and that individual indicators may be omitted if upstream collectors haven't run. This adds value beyond the empty schema.

  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 concise (~4 sentences), front-loaded with the purpose, and every sentence adds value. No redundancy or unnecessary details.

  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 tool with no parameters, no output schema, and no annotations, the description is sufficiently complete. It explains all return components, their ranges, sources, and a behavioral note about missing indicators.

  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 100% schema description coverage, so the baseline is 4. The description adds no parameter information because none exist.

  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 verb 'Get' and the resource 'current Bitcoin market sentiment indicators', listing specific indicators and distinguishing it from sibling tools (price, briefing, funding, ML signal). It is not a tautology and provides a precise purpose.

  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 mentions use cases such as 'contextualising price action', 'detecting positioning extremes', and 'as a coarse macro filter for shorter-horizon ML signals', providing clear context. However, it does not explicitly contrast with sibling tools or state when not to use it.

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

• get_market_briefingA
  4.6/5.0
  Behavior4/5

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

  No annotations exist, so the description carries full burden. It explains the tool's behavior: returns a natural-language summary with two verbosity levels and typical line counts. It does not discuss data freshness, latency, or error handling, but the behavior is straightforward and well-described.

  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 concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value, clearly explaining the tool's function and modes without redundancy.

  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 simplicity (one optional parameter) and lack of output schema, the description covers the main aspects: data sources, modes, output length. It could mention error cases or data freshness, but is complete enough for effective use.

  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 covers 100% of the parameter, but the tool description adds meaning by detailing what each verbosity value yields ('brief returns roughly 4 lines...', 'detailed adds per-venue breakdown...'). This enriches the schema's enum descriptions.

  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 purpose: 'Get a concise natural-language summary of the current Bitcoin market state.' It specifies the data sources it synthesizes and distinguishes between two modes (brief and detailed). The sibling tools are individual raw data calls, so this tool is well-differentiated.

  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 advises when to use this tool: 'the most token-efficient way for an agent to get the "what's happening right now" picture — replaces 4-5 raw data calls plus the reasoning to summarise them.' This provides clear guidance against alternatives.

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