Server Quality Checklist

Tool Scores

• parse_trade_intentC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'translates' without detailing the output shape, error behavior, or side effects. It does not clarify whether parsing is purely local or involves remote calls, nor does it describe how the structured parameters are returned.

  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 with no filler words. It conveys the essential purpose efficiently and earns its place.

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

  Completeness2/5

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

  The tool has no output schema, yet the description does not explain the structure or format of the 'structured parameters' it produces. An agent would need to know the keys, types, or example output to correctly chain this tool with downstream trading tools. The one-liner is too sparse for reliable 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 coverage is 100%, so the schema already describes the single 'prompt' parameter with an example. The description does not add parameter-level meaning beyond calling it a 'user trading prompt', which is consistent with the schema, earning the baseline score.

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

  Purpose4/5

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

  The description states a clear action ('Translates natural language user trading prompts') and a resource ('into structured parameters for Binance Agent OS'), making the core function immediately understandable. It is distinct from siblings like evaluate_trade_risk and execute_hedged_trade, though it does not explicitly name them to preempt confusion.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus its siblings, nor does it mention any preconditions or follow-up steps. It simply defines the action, leaving the agent to infer that this is a natural first step for trade intent processing.

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

• evaluate_trade_riskB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral disclosure burden. It reveals a performance trait (NVIDIA NIM sub-millisecond GPU inference) but says nothing about side effects, required permissions, output format, or read-only/read-write behavior. This is insufficient given the absence of annotation support.

  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 sentence that wastes no words and front-loads the core purpose. Mentioning the NVIDIA NIM performance detail adds relevant context without bloating the text.

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

  Completeness2/5

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

  With no output schema and no annotation support, the description needed to explain what the tool returns and how to interpret the risk/liquidation result. It omits prerequisites, return shape, and relationship to the sibling trade-execution workflow, leaving an agent without key information to invoke the tool 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 all five parameters. The description adds no extra meaning to parameter semantics and does not resolve ambiguities such as whether amount is in USD or asset units. Baseline 3 is appropriate when the schema handles parameter documentation.

  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 ('evaluates') and a precise resource ('cryptocurrency trade risk and liquidation probability'), which clearly distinguishes it from siblings like parse_trade_intent and execute_hedged_trade. The purpose is immediately recognizable and not a tautology of the tool name.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus parse_trade_intent, query_yield_arbitrage, or execute_hedged_trade. It implies a pre-trade risk assessment use case but never states conditions, exclusions, or which alternative to choose.

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

• execute_hedged_tradeB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for disclosing behavior. It mentions risk gating but gives no concrete details about what gates or rejects a trade, how overrideApproved interacts with gating, whether an order is actually placed, or what side effects or failure modes exist. This is especially significant for a trade-execution tool.

  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 a single front-loaded sentence with no filler. It briefly states what the tool does and why. It loses a point only because the phrase 'pre-trade risk sentinel gating' is jargon-heavy and compresses a lot of unexplained behavior.

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

  Completeness2/5

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

  This is a potentially irreversible financial action with no annotations and no output schema, yet the description omits crucial context: what happens when risk gating blocks, how override works, and what the caller should expect after execution. The provided schema covers parameters but not the behavioral context needed to invoke it safely.

  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 every parameter. The description adds no specific parameter-level semantics beyond the general notion of risk gating, which is appropriately at the baseline of 3.

  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 core function: routing a trade with pre-trade risk sentinel gating. It also conveys the intended outcome (prevent liquidation cascades, preserve capital), and the verb 'routes' distinguishes this execution tool from the risk-evaluation and parsing siblings.

  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 phrase 'pre-trade risk sentinel gating' implies this is the execution step after risk evaluation, and the riskScore parameter references evaluate_trade_risk. However, the description never explicitly states when to use this tool versus alternatives or 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.

• query_yield_arbitrageA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the comparison scope but does not mention what the output looks like, whether the data is live or delayed, any rate limits, or that this is a read-only operation beyond the verb 'compares'.

  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?

  A single, substantive sentence that front-loads the main action and includes valuable specifics about the compared sources. Every word earns its place with no 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?

  The two fully documented parameters make invocation straightforward, and the description conveys the core purpose. However, there is no output schema and no description of the return format or comparison results, leaving some ambiguity about what the agent will actually receive after calling the tool.

  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%, with both parameters already described with defaults and examples. The description adds no additional meaning about how 'symbol' or 'capitalUsd' affect the comparison, so the baseline score 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?

  States a specific verb ('Compares') and the exact resources being compared: Binance Earn/funding rates versus CHAINZ on-chain yield vaults. This clearly differentiates it from sibling tools like evaluate_trade_risk, parse_trade_intent, and execute_hedged_trade.

  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 comparison wording implies it should be used for yield-arbitrage assessment, but the description never explicitly states when to use this tool versus the siblings or any exclusions. There is no 'use when' language or mention of alternatives.

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