Server Quality Checklist

Tool Scores

• close_positionA
  3.8/5.0
  Behavior3/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 mentions 'close all positions' which is a key destructive trait, and it shows the return type as 'Dict with close order details or error.' However, it lacks additional context such as whether the close is executed at market price, whether it requires an existing position, or any side effects like fees or slippage. This is basic but not rich.

  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 and well-structured. It opens with a one-sentence purpose, then clearly separates Args and Returns. Every word earns its place, with no redundancy or filler. The inclusion of a concrete parameter example is valuable without bloating the text.

  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 single-parameter tool, the description is fairly complete. It covers the purpose, parameter semantics, and return type. The existence of an output schema means the return format details need not be explained. The main omission is prerequisites or side effects, but given the tool's simplicity and the presence of an output schema, this does not significantly detract from 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 only lists 'symbol' with no description, so the description adds essential meaning by providing a format example: 'e.g., "BTC/USDC:USDC"'. This clarifies the expected structure (base/quote with separator) and gives a concrete example, fully compensating for the schema's 0% coverage.

  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 what the tool does: 'Close all positions for the specified trading pair on Hyperliquid.' It uses a specific verb (close) and resource (positions for a trading pair), and it distinguishes itself from sibling tools like place_order and cancel_open_orders by focusing on closing positions entirely.

  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 alternatives such as place_order or cancel_open_orders. It simply states the function without any context about scenarios (e.g., 'use this to exit a position entirely' or 'not for partial closures'). There is no explicit when-to-use or when-not-to-use information.

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

• cancel_open_ordersA
  4/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 the burden of disclosing behavior. It states that the tool cancels (a clear mutation) and returns 'Dict with canceled orders details or error', which is useful. However, it does not mention side effects, permissions, or edge cases like no open orders.

  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, with a clear and front-loaded main sentence followed by a simple Args/Returns block. Every sentence adds necessary information, with no redundancy or fluff.

  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 parameter, no annotations, but an output schema), the description covers the essential context: purpose, input format, and return type. It lacks deeper edge-case behavior, but for a straightforward cancel operation, it is sufficiently complete.

  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 only defines 'symbol' as a string with no description. The description compensates by providing the format ('Trading pair') and a concrete example ('BTC/USDC:USDC'), giving the agent enough information to construct a valid parameter 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?

  The description clearly states the action ('Cancel'), the resource ('all open orders'), and the scope ('for the specified trading pair on Hyperliquid'). It distinguishes this tool from siblings like place_order, close_position, and account_info by targeting a specific trading operation.

  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 its usage by stating exactly what it does ('Cancel all open orders'), but it does not provide explicit when-to-use guidance, exclusions, or alternatives. The use case is clear but left to the agent to infer.

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

• market_stateA
  4/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 the full burden. 'Get and format' implies a read-only operation with no side effects, and it discloses that the return is a formatted string. However, it does not elaborate on rate limits, error handling, or what 'market state' encompasses, which would enhance 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 front-loaded, with a one-line purpose followed by Args and Returns sections. Every sentence contributes value, and there is no redundancy or fluff.

  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 read tool with one parameter and an output schema, the description covers the essential information: purpose, symbol format, and return type. It could be more complete by mentioning potential errors or symbol variations, but given the tool's simplicity, it is adequately complete.

  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 schema only specifies the symbol as a string, but the description adds a concrete example ('BTC/USDC:USDC') and clarifies it is a trading pair. This provides meaningful semantics beyond the schema, helping the agent understand the required format despite 0% schema coverage.

  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 with a specific verb ('Get and format') and resource ('current market state'), making it obvious what the tool does. It distinguishes itself from sibling trading tools (place_order, close_position, cancel_open_orders, account_info) by focusing on market data retrieval.

  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 checking market conditions but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool mentions are provided, leaving the agent to infer applicability from the tool's name and siblings.

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

• account_infoA
  4.2/5.0
  Behavior3/5

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

  The description discloses that the return value is a formatted string with account details, which is useful. However, with no annotations provided, the description carries the full burden and does not mention authentication requirements, data scope, or the absence of side effects. It provides minimal behavioral context beyond the return format.

  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, consisting of two sentences. The first sentence front-loads the verb and resource, and the second specifies the return format. Every word earns its place without unnecessary detail.

  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 zero-parameter getter with an output schema present, the description is adequate: it identifies the resource and the return format. It could add more context about when to use this tool (e.g., for displaying account status to the user), but it is complete enough for a simple informational tool.

  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 tool has zero parameters, so the description is not required to explain parameter semantics. The schema coverage is trivially 100% with an empty object, and the description adds no param info, which is acceptable. Baseline for zero 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 clearly states 'Get and format the current account information', identifying the action (get/format) and resource (account information). It is distinct from siblings such as place_order and close_position, which are trading operations, making the tool's purpose unambiguous.

  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 implies usage for retrieving account details, and the sibling tools are all trading actions, so there is no overlap. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, though the context makes it clear.

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

• place_orderA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does a good job: it discloses that TP/SL are auto-calculated if not provided, that price defaults to current market price, and that a dict with details/error is returned. It does not mention risk or how auto-calc is derived, but the core state-changing behavior is explicit.

  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 purpose-led, then uses a clean Args block with one line per parameter and a Returns line. It is appropriately sized for a 7-parameter tool with no wasted sentences or redundant 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 output schema exists and all parameters are semantically covered, the description is complete for both selection and invocation. It covers purpose, behavior, parameter meaning, defaults, and return type without needing extra external context.

  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?

  Schema description coverage is 0%, so the description fully compensates by explaining all seven parameters with examples, defaults, and meaning (e.g., symbol format, side values, price as limit price or market, leverage default, TP/SL auto-calc). This exceeds baseline and makes the schema usable.

  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-resource pair: 'Place an order on Hyperliquid.' It further distinguishes the tool by mentioning optional market pricing and auto-calculated TP/SL, which separates it from sibling tools like close_position and cancel_open_orders.

  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 context clearly implies the tool is for opening orders, and param details clarify when defaults apply (e.g., market price when price is None). However, it does not explicitly state when not to use it or name alternatives, so it stops short of a 5.

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