Server Quality Checklist

Tool Scores

• get_positionA
  4/5.0
  Behavior3/5

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

  Annotations already convey safety (read-only, idempotent, non-destructive). The description adds that the output matches get_positions, which is useful format context. It does not mention error behavior, but the annotation coverage lowers the bar and the added context is sufficient.

  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, focused sentence that immediately conveys the operation and scope. It includes a cross-reference to get_positions without any fluff, making every word valuable.

  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?

  The tool is simple with one parameter, an output schema, and safety annotations. The description covers the operation, parameter, and output consistency with get_positions. Minor omissions like error cases are not critical given the schema and annotations.

  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 0%, so the description must compensate. It tells the agent that 'symbol' is the identifier for the position to fetch and implies compatibility with get_positions. However, this largely restates the property name and adds only modest 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?

  The description clearly states the action ('Get'), the resource ('a single position'), and the scope ('by symbol'). It distinguishes this tool from the sibling get_positions by emphasizing 'single' and referencing get_positions for context, making its unique purpose obvious.

  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 the use case: fetch one position for a given symbol. The reference to get_positions signals that it is the singular counterpart, offering clear context even though it does not explicitly state when not to use it or provide alternative guidance.

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

• cancel_orderA
  4.2/5.0
  Behavior3/5

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

  With annotations already declaring readOnlyHint=false and destructiveHint=true, the agent knows this is a mutating destructive action. The description adds only the 'same order gate' context, which hints at validation behavior but doesn't elaborate on side effects, error handling, or reversibility. This is adequate 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 two concise sentences, front-loaded with the verb and resource. It provides necessary context without filler, making every word purposeful.

  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 simple one-parameter tool, the description covers the core action and parameter source. The 'same order gate' reference is a bit cryptic but not fatal. Since an output schema exists, the lack of return-value explanation is acceptable.

  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 0%, so the description must compensate. It adds meaningful guidance by stating the order_id is 'shown in get_orders', giving the parameter a concrete source and practical context. For a single-parameter tool, this is sufficient, though it doesn't explain formatting or edge cases.

  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 the action ('cancel') and the specific resource ('one open order'), and it distinguishes from siblings by emphasizing 'one' versus cancel_all_orders. It also identifies the required identifier source, making the purpose unmistakable.

  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 gives clear context: use this to cancel a single open order identified by order_id from get_orders. It references the 'same order gate as place_limit_order', implying shared validation constraints, but it does not explicitly name alternatives or state when not to use it, which keeps it just below a 5.

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

• get_ordersA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds that a symbol can carry multiple order records in different states, and to check status before describing as open. This goes beyond annotations with useful behavioral context about the return data.

  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 short sentences front-load the purpose and practical guidance; every sentence adds value without unnecessary 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?

  With an output schema present, the description covers the main purpose, status interpretation, and filtering. It omits timezone details for 'today' but is sufficient for a simple read-only 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 coverage is 0%, so the description must compensate. It explains `pending_only=True` filters to working orders, and implies `symbol` filters by symbol ('A symbol usually carries...'). However, it doesn't explicitly state the parameters' optionality or defaults, so compensation is partial.

  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 orders placed today with their state' — a specific verb and resource with a timeframe, and enumerates example states. This distinguishes it from sibling tools like get_positions or get_portfolio_overview by focusing on 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?

  It provides clear context: the tool retrieves today's orders and advises reading the `status` field before interpreting, plus using `pending_only=True` for working orders. However, it doesn't explicitly compare with alternative tools, so no exclusions are stated.

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

• get_positionsA
  4.3/5.0
  Behavior4/5

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

  Annotations already define a safe read-only, idempotent, non-destructive operation. The description adds value by stating 'Returns the complete list', which implies no pagination or truncation, and specifies computed fields like theoretical gain. This gives 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?

  Two sentences, front-loaded with the action and resource. Every word contributes: the first sentence lists the key output fields, the second confirms completeness. No waste or repetition.

  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 0-parameter tool with an output schema, the description fully covers what the tool does and the scope of results. It mentions the complete list and specific data fields, making it self-sufficient even without the output schema.

  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 schema is trivially complete. The description adds no parameter details, but none are needed. Baseline for 0 params is 4; no further clarification required.

  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 'every open position in the portfolio', listing specific fields (quantity, average price, theoretical gain). It distinguishes from sibling 'get_position' by using 'every' and 'complete list', indicating a plural list vs singular.

  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 a complete list of open positions, but does not explicitly mention when to use it versus alternatives like get_position or get_portfolio_overview. The context signals show sibling tools, but no direct comparison or exclusion is provided.

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

• modify_orderA
  4.3/5.0
  Behavior4/5

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

  The description adds behavioral detail beyond annotations, such as 'Confirms in the same exchange' and 'reports on_market', and clarifies that signal_price applies only to stop orders. This enriches the safety profile without contradicting the destructiveHint.

  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 brief and front-loaded with the core purpose. The phrase 'Same order gate' is slightly cryptic but the overall structure is efficient with no filler.

  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 that an output schema exists and annotations cover safety traits, the description covers purpose, parameter behavior, and key behavioral traits. It omits edge cases but references 'same order gate' for validation, making it adequate for a moderate-complexity 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?

  With 0% schema description coverage, the description compensates by explaining price as the limit price and signal_price as specific to stop orders. order_id is self-explanatory from the required field, so the added meaning is useful.

  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 a specific action: 'Change the limit price of an open order'. This distinguishes it from sibling tools like cancel_order and place_limit_order, making the purpose unmistakable.

  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?

  It provides context that the modification confirms in the same exchange like place_limit_order and reports on_market, which helps an agent infer when to use it. It does not explicitly list alternatives or exclusions but the context is sufficient.

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

• get_intraday_candlesA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly/idempotent/non-destructive. The description adds valuable context about the real-time quote entitlement requirement (code 1032), which is not captured in annotations or schema. This helps the agent anticipate authorization needs.

  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 tight, front-loaded sentences. The first states the core function and parameters; the second adds a critical entitlement requirement. No filler or 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?

  For a simple candle-retrieval tool, the description covers purpose, bucket parameter, time range, and entitlement. An output schema exists, so return values are documented elsewhere. Some details like maximum days or data freshness are omitted, but not essential for basic usage.

  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 has zero parameter descriptions. The description compensates by explaining the key parameters: 'period_minutes' for bucketing and 'last N days' for the 'days' parameter. 'symbol' is self-evident from context. Defaults are in 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 clearly states the tool retrieves intraday OHLC candles, specifies the bucketing parameter (period_minutes), and the time range (last N days). This distinguishes it from siblings like get_daily_candles and get_tick_data.

  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 clear context for when to use this tool (intraday aggregated candlestick data) and mentions the entitlement prerequisite. It doesn't explicitly name alternative tools or exclusions, but the context is sufficient for an agent to differentiate.

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

• get_tick_dataA
  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 idempotentHint=true, and the description adds further context by warning that the data 'Can be very large' and by noting the entitlement requirement. This goes beyond the annotations, though it does not mention pagination or response size limits; an output schema exists to cover return values. No contradiction with 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 sentences, front-loaded with the main action, and every phrase adds value: the purpose, a warning about large data, an explicit alternative tool, and a prerequisite. 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 2-parameter, read-only tool, the description covers the core purpose, a warning about data volume, a recommended alternative, and a prerequisite. The output schema handles return values. It is fairly complete but could include a note on maximum allowable days or pagination behavior.

  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 0%, so the description must compensate. It clarifies the 'days' parameter via 'over the last N days' but does not explicitly describe the 'symbol' parameter, which is required. While symbol is self-evident from context, the description could have specified that the parameter is a symbol string. Thus it partially compensates but not fully.

  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 begins with a specific verb 'Get' and resource 'tick-by-tick trades over the last N days', making the action and scope immediately clear. It also distinguishes itself from the sibling tool get_intraday_candles by explicitly recommending it as an alternative, resolving potential ambiguity.

  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 usage guidance: 'prefer get_intraday_candles beyond a single session' warns against using this tool for long ranges, and 'Needs the real-time quote entitlement' specifies a prerequisite. This tells the agent when to use the tool and when not to, which is exactly what this dimension requires.

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

• preview_limit_orderA
  4.4/5.0
  Behavior5/5

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

  The description reveals critical behavioral traits beyond annotations, such as: the order is 'deliberately left unconfirmed, so it never reaches the market,' and the warning to read `on_market` because if true 'the order IS live.' It also discloses the commission dependency on order value and the gate requirement. This adds depth to the sparse annotations (readOnlyHint=false, idempotentHint=true).

  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 organized into three compact paragraphs that each serve a purpose: the first states intent and usage, the second explains what happens and why, and the third adds a safety warning. No sentence is redundant, and the tool's complexity justifies the length.

  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?

  While parameter semantics are thin, the description covers the core aspects needed for safe invocation: purpose, when to use, expected response fields, a safety check (on_market), and the permissions gate. The presence of an output schema covers return structure, so the description doesn't need to list every field. However, a brief note on parameter meaning would make it fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no descriptions and schema description coverage is 0%, so the description must compensate. It does not provide any per-parameter definitions or constraints beyond what the schema already lists (symbol, side, quantity, price, order_id). Though it references 'order's value,' it does not explain how parameters interact or what each parameter means. This is a significant gap.

  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 clear verb and resource: 'Ask Darwin what an order would cost, without placing it.' It distinguishes itself from the sibling tool place_limit_order by explicitly saying 'Use this before place_limit_order,' 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 Guidelines5/5

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

  It provides explicit when-to-use guidance: 'Use this before place_limit_order, and whenever the user asks about commissions.' It also states that 'This is the only way to obtain commission figures,' ruling out alternatives, and notes the same DIRECTA_ENABLE_ORDERS gate as place_limit_order, which clarifies when it can be invoked.

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

• get_availabilityA
  4.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds useful context about what buying power includes (cash for stocks/derivatives, with/without margin), but it does not disclose any additional behavioral traits (e.g., data freshness, rate limits, or authorization requirements) beyond what annotations already imply. This matches the calibration example of get_calls where the description adds some value but not rich behavioral context.

  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 sentences long with no fluff. The first sentence immediately states the purpose and scope, while the second gives actionable usage guidance. Every word earns its place, and it is front-loaded with the most critical 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?

  For a zero-parameter tool with rich annotations (read-only, idempotent, non-destructive) and an output schema present, the description sufficiently explains what the tool does and when to use it. It clarifies the distinction from a sibling tool and provides the exact use case. There are no missing prerequisites, side effects, or return-formats to explain since the output schema covers return values.

  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 schema carries no parameter semantics (coverage is trivially 100%). The baseline for 0 parameters is 4, and the description adds meaning to the tool's output ('buying power' and its components) which indirectly clarifies what the tool returns. No parameter information is needed, and the description does not confuse with parameter details.

  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 ('Get') and resource ('buying power') and clarifies scope ('cash available for stocks and derivatives, with and without margin'). It also distinguishes itself from sibling get_account_balance by naming it and providing the exact use case ('how much can I invest'), satisfying sibling differentiation.

  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 'Use this rather than get_account_balance when the question is "how much can I invest"'. This provides clear when-to-use guidance and names the alternative, which is exactly the kind of directive expected for a 5 on this dimension.

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

• get_candle_data_rangeA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context about the required entitlement and the exact date/period formats, which are behavioral requirements not inferable from 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 sentences, front-loaded with the main purpose, and every clause adds useful information. No redundancy or filler.

  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 data retrieval tool with an output schema and good annotations, the description provides all necessary operational details: parameter formats, period options, and entitlement requirement. Complete and sufficient.

  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 0%, but the description compensates by explaining the date format with an example and mapping period_seconds values (60=1min, etc.). Symbol is self-explanatory, so the main non-obvious parameters are well described.

  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 OHLC candles within an explicit range', which is a specific verb+resource+scope. It distinguishes from siblings like get_daily_candles and get_intraday_candles by emphasizing the explicit range and configurable period_seconds.

  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 gives clear context: it is for fetching OHLC data in a specified range with a chosen bucket size. It also notes the real-time quote entitlement prerequisite. However, it does not explicitly mention alternatives or when not to use this tool, so it falls 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.

• get_daily_candlesA
  4.6/5.0
  Behavior5/5

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

  The description adds critical behavioral context beyond the annotations by disclosing the entitlement prerequisite and the specific error code 1032. The annotations only declare read-only, open-world, and idempotent behavior, so this auth/failure information is valuable and does not contradict 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 sentences: the first states the core purpose, the second adds a necessary prerequisite. It is front-loaded, concise, and free of redundancy, earning its place.

  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-only data tool, the description covers the main action, the key parameter, and a critical failure condition. The presence of an output schema handles return details, so nothing essential is omitted, though a note about timezone or data adjustments would have made it slightly more 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 description explains that the `days` parameter controls the lookback window ('last N days'), which adds meaning to a parameter that otherwise has no schema description. The `symbol` parameter is left implicit but is self-evident from the tool name, so the description provides adequate compensation for the 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 retrieves daily OHLC candles for the last N days, using a specific verb and resource. This distinguishes it from sibling tools like get_intraday_candles or get_candle_data_range, which cover different timeframes or ranges.

  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 clear context by noting the real-time quote entitlement requirement and the failure code 1032, which informs when the tool can be used. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a full when-to-use guide.

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

• place_limit_orderA
  4.6/5.0
  Behavior5/5

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

  Annotations indicate destructiveHint=true, but the description goes well beyond by detailing the two-step submit-confirm exchange, the lack of confirmation persistence, the meaning of on_market, and the possibility of a silent failure. This critical context prevents the user from assuming a successful exchange means a placed order.

  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 somewhat long but every sentence carries essential risk and workflow information. It is front-loaded with the most critical warning ('REAL limit order with real money'), followed by alternative guidance, execution mechanics, verification instructions, and parameter clarification. No fluff or 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?

  Given that this is a destructive, real-money tool with a non-trivial two-step exchange protocol, the description covers all essential aspects: prerequisite (env var), safer alternative, behavioral nuances, verification steps, and client-side order_id semantics. The presence of an output schema means return values are documented elsewhere, so the description is complete for its purpose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description must compensate for all parameters, but it only explains order_id (client-side reference, generated if omitted). Symbol, side, quantity, and price are left entirely to their names and schema types, which may be insufficient for a real-money trading tool. The description misses an opportunity to clarify units, side implications, or price precision.

  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 'Place a REAL limit order with real money' and differentiates from siblings like preview_limit_order by emphasizing there is no simulation mode. The verb 'place' and resource 'limit order' are specific, and the warning about real money makes the purpose unmistakable.

  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 gives explicit guidance: 'Prefer preview_limit_order first' as a safer alternative, and advises verifying with get_orders after execution. It also states the precondition that the server must run with DIRECTA_ENABLE_ORDERS=true, covering both when to use and when to avoid.

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

• cancel_all_ordersA
  4.7/5.0
  Behavior5/5

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

  Annotations already flag destructiveHint and idempotentHint, but the description adds substantial behavioral context: the need for user confirmation, verified symbol filtering behavior, the Darwin REVALL/TRADOK 3002 ack quirk, and the practical advice to read the resulting order list rather than trust the ack. This goes well beyond the annotations and is genuinely useful.

  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 front-loaded with the core purpose, then adds a critical safety note, a pointer to the existing order gate, and a concise but valuable implementation detail about the ack behavior. Every sentence earns its place and there is no 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?

  Given one simple parameter, rich annotations, and an output schema, the description covers the essential context: what it does, when user confirmation is required, how it behaves relative to sibling tools, and how to correctly interpret the response. It is complete enough for an agent to select and invoke the tool 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 0%, but the description compensates by explaining that the symbol acts as a filter for all open orders and includes verification evidence that only the named symbol is affected. It also warns about the ack response not identifying the symbol, which adds meaning beyond the bare schema property. Since there is only one simple string parameter, this is sufficient.

  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 operation: 'Cancel every open order for a symbol.' It uses a specific verb (cancel), identifies the resource (open orders), and scopes it by symbol, which distinguishes it from the sibling cancel_order that targets a single order.

  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?

  It provides explicit usage guidance: confirm the symbol with the user first because the action may affect orders the user didn't ask about, and it references the same order gate as place_limit_order. It does not explicitly contrast with cancel_order, but the 'every open order' scope makes the intended use clear.

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

• check_connectionA
  4.9/5.0
  Behavior5/5

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

  Annotations already indicate readOnly=true, idempotent=true, destructive=false. The description adds meaningful behavioral context beyond annotations: it distinguishes 'Darwin is not running' from 'Darwin refused the command', explains the darwin.state and darwin.hint output fields, and notes that the account need not be logged in. This enriches the agent's understanding of what the tool does at runtime.

  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 and well-structured, with each sentence contributing unique value: purpose, when to call, and what output to expect. It avoids redundancy and is front-loaded with the core purpose.

  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 (no params, clear annotations, output schema present), the description is complete. It covers purpose, usage context, behavioral nuances, and state output, leaving no significant gaps for an agent to misuse or misunderstand the 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 schema covers everything. The description adds context about what the tool checks (ports reachability) and the state/hint outputs, but since there are no parameters, the baseline of 4 is appropriate. No further param documentation is needed.

  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 function: 'Check whether Darwin's local trading and historical-data ports are reachable.' It uses a specific verb ('check') and resource ('Darwin's ports'), and distinguishes it from siblings by positioning it as the first tool to call when other tools fail, separating connection issues from command failures.

  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?

  Explicit usage guidance is provided: 'Call this first if any other tool fails' and 'This is also the tool to poll after start_darwin, once the user says they have finished the login.' It clarifies prerequisites (Darwin running and listening, not logged in) and differentiates this tool from alternatives like get_darwin_status.

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

• get_account_balanceA
  4.9/5.0
  Behavior5/5

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

  Even though annotations already declare readOnlyHint and idempotentHint, the description adds crucial behavioral context: the misleading field names (`gain_euro` is open P&L, `open_profit_loss` is cost basis), verification by reconciliation, and a warning not to quote `open_profit_loss` as a gain. This goes well 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 concise and front-loaded: the main purpose is stated in the first sentence, followed by necessary caveats and a usage pointer. Every sentence contributes value—no fluff or repetition of structured 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?

  Despite having no parameters, the description fully covers the tool's context: what it returns (liquidity, equity, two problematic fields), important data quirks, and when to choose an alternative. The presence of an output schema (per context signals) means return format details are already structured, so additional explanation is unnecessary.

  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?

  This tool has zero parameters, so the baseline is 4. There are no parameter descriptions needed in the text, and the input schema correctly shows no properties. The description effectively handles parameter semantics by omission.

  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 begins with 'Get raw account figures from dAPI INFOACCOUNT', which clearly identifies the verb, resource, and specific data items. It explicitly distinguishes itself from get_portfolio_overview by stating which tool to prefer for portfolio value/performance, making it unambiguous among siblings.

  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 provides explicit usage guidance: 'For anything about portfolio value or performance prefer get_portfolio_overview... use this tool for liquidity, equity, the account code, or when the user wants the raw line.' This gives clear when-to-use and when-not-to-use instructions with a named alternative.

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

• get_darwin_statusA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent, etc.), the description adds meaningful behavioral context: it goes through the dAPI conversation rather than a raw TCP probe, which implies a higher-level interaction and potentially different latency or dependencies. It also explains the datafeed_enabled field's significance for historical tools.

  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, front-loaded with the core purpose, then valuable differentiation and a practical tip. No wasted words.

  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 tool is simple (0 params, read-only) with an output schema available. The description covers purpose, usage, and adds behavioral context, making it complete for an agent to decide when 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?

  The tool has zero parameters, so schema coverage is trivially 100%. The description doesn't need to elaborate on parameters, and the baseline for zero-parameter tools 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 the tool gets Darwin's connection status, release, and datafeed enablement. It explicitly differentiates from the sibling tool check_connection by noting it uses the dAPI conversation rather than a raw TCP probe.

  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 provides explicit guidance on when to use this tool: when you need richer status than check_connection, and when you want to know if historical tools can work (via datafeed_enabled). It names the alternative and highlights the difference.

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

• get_portfolio_overviewA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses crucial behavioral quirks: price/value are derived from average price and theoretical gain because Darwin doesn't report current price; bonds (M. symbols) are quoted as percentage of nominal; and the tool performs internal reconciliation with the reported figures. It further instructs the agent to handle reconciliation.false by saying so and quoting the residual, which is rich, actionable 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 well-structured and front-loaded: a one-sentence value proposition, followed by a specific usage recommendation, then necessary caveats about data derivation and reconciliation. Every sentence earns its place; the warnings about bonds and reconciliation are critical for correct use and are not redundant with the schema or annotations.

  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 has no parameters and an output schema exists, the description doesn't need to document return values. It covers the full behavioral surface: the scope of data returned, the derivation quirks, the bond scaling issue, and how to handle reconciliation failures. It also positions the tool relative to siblings, making it 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?

  The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline for zero-parameter tools, the description doesn't need to add parameter semantics, and indeed it doesn't attempt to. It slightly exceeds the baseline by clarifying the tool's scope, but there is no parameter-specific information to add.

  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 clear, specific verb-resource pair: 'The whole picture in one call: every position with its current price and value, plus portfolio totals and P&L.' It explicitly distinguishes itself from the sibling tool get_positions by stating when to prefer it, making its 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 Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Prefer this over get_positions when the question is about how the portfolio is doing or what it is worth.' It also provides a strong negative guideline: 'Do not compute values yourself from get_positions' with a concrete reason about bonds, which helps the agent avoid a known pitfall.

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

• start_darwinA
  4.9/5.0
  Behavior5/5

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

  It discloses the non-waiting/async behavior, the DIRECTA_AUTOSTART=true prerequisite, the single-session limitation, and the user-facing OTP prompt—all beyond the annotations. It also qualifies the idempotentHint by warning that repeated calls can disturb login, without contradicting the hint.

  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?

  Although the description is long, every sentence carries necessary operational context: prerequisites, short-return behavior, user instructions, and safety constraints. It is front-loaded with the core purpose and wastes no words.

  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 covers preconditions, side effects, follow-up procedure, and user interaction rules. Since an output schema exists, return values need no explanation, making the description fully complete for this complex 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 there is nothing to explain. With no parameters, the baseline score is 4, and the description appropriately omits parameter details.

  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 opening sentence 'Launch dGO, Directa's launcher, so the user can bring Darwin up' uses a specific verb and resource, clearly distinguishing it from sibling tools like check_connection or get_darwin_status. The purpose is unambiguous and front-loaded.

  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 to call check_connection afterward, warns 'Do not call this repeatedly while waiting', and states 'never call it on your own initiative'—providing clear when-to-use and when-not-to-use guidance. It names the follow-up tool and explains the single-session constraint.

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