Server Quality Checklist

Tool Scores

• replay_windowB
  3.2/5.0
  Behavior3/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 that the tool is read-only with sandbox-only mutations, which is a key behavioral trait. However, it does not explain auth needs, rate limits, or implications of parameter values.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is three sentences, to the point, front-loaded with the main action, and provides necessary context without redundancy.

  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?

  Given 4 parameters (including nested objects) and no output schema, the description lacks enough detail about parameters, return values, and inner workings. The usage examples help but do not cover the full complexity.

  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?

  Schema description coverage is only 25% (one parameter described). The description does not explicitly describe parameters; it only hints at time window and strategy via context. This insufficiently compensates for the low schema coverage.

  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 clearly states the tool runs a sandbox replay over a time window, with a specific verb ('run') and resource ('sandbox replay'). It distinguishes from sibling tools like run_backtest by emphasizing sandbox-only and read-only nature, but does not explicitly name alternatives.

  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?

  Provides usage examples like 'replay the last hour' and 'rerun this period in sandbox', giving clear context. However, it does not mention when not to use this tool or suggest alternatives among siblings.

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

• flatten_positionsA
  4/5.0
  Behavior3/5

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

  No annotations provided. Description reveals default dry_run=true and that market orders are used, but does not disclose potential side effects like slippage or market impact.

  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 purpose, no redundant words.

  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-param tool with no output schema, description covers purpose, filtering, and default. Could mention confirmation behavior, but adequate.

  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?

  Description adds 'optionally filtered by symbol' and 'Default dry_run=true' beyond schema. Schema already describes symbol well, but dry_run semantics are minimally covered.

  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?

  Description clearly states 'Close every open position with opposite-side market orders, optionally filtered by symbol.' This is a specific verb-resource combination that distinguishes from siblings like cancel_all or cancel_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?

  Explicitly says 'Use for close everything operator actions or end-of-day flatten.' Provides context, though does not explicitly exclude other scenarios or compare with alternatives.

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

• place_orderA
  4/5.0
  Behavior3/5

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

  Without annotations, the description adds value by disclosing HTTP communication with local ControlServer, env var requirements, and dry-run behavior. However, it doesn't cover error handling, rate limits, or response behavior, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Four sentences, each adding value with no redundancy. The key actions and constraints are front-loaded, making it easy to parse quickly.

  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 description covers architecture, authentication, dry-run behavior, and approval flow for an order placement tool with 9 parameters. Missing explicit return value or error cases, but the complexity is adequately handled.

  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 67%, so baseline is 3. The description does not add further meaning to parameters like symbol or qty beyond what the schema provides, but it does explain the role of dry_run and approve_token in context.

  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 places an order via the flox engine, specifying the resource (order) and verb (place). It differentiates from sibling tools like cancel_all and cancel_order by focusing on order entry, and adds specificity with 'manual hedges or operator-driven order entry'.

  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 explains default dry_run=true and the need for approve_token in live scope, guiding when to use the tool. It provides context but does not explicitly list alternatives or when not to use it, though sibling context helps.

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

• route_amm_swapA
  4/5.0
  Behavior4/5

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

  Description discloses exact-to-wei precision, input format for amounts, error behavior on mis-routing, and the optional dependency. It lacks clarity on whether the swap is simulated or executed, but given the sibling list includes place_order, it likely simulates. No annotations provided, so description carries the burden.

  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?

  Description is concise with four sentences. It front-loads the main purpose and includes important details. Slightly dense but no unnecessary wording.

  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?

  Description adequately covers inputs and outputs, but the return value ('the fill', 'per-venue comparison') is somewhat vague. No output schema, so more detail would help. Overall sufficient for a routing tool but not fully explicit.

  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 descriptions for all three parameters. Description reiterates the amount format and venue structure but adds minimal value beyond the schema. 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?

  Description clearly states the tool performs best execution for DEX swaps across AMM pools. It specifies that it returns the best venue, fill amount, and per-venue comparison. This distinguishes it from siblings like price_amm_swap and amm_price_impact.

  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?

  Description implies usage context: provide the same notional and multiple venues to get the best fill. It mentions error handling for mis-routed swaps and a dependency requirement. However, it does not explicitly contrast with similar tools or state when not to use this tool.

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

• get_open_ordersA
  4.1/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 that the tool is read-only and describes the special response when the engine is not running. This is good behavioral context, though it could be more thorough about normal return behavior or potential errors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is three sentences long, each adding value: purpose, usage guidance, and a behavioral note. It is front-loaded and free of unnecessary words.

  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 description covers the purpose, usage, and a specific edge case (engine not running), but fails to describe the normal return structure. Since no output schema is present, the description should explain what the successful response contains (e.g., list of orders, fields). This gap lowers completeness.

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

  Parameters3/5

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

  The input schema already provides 100% coverage with clear descriptions for both parameters. The description merely rephrases the filter parameter without adding new meaning, so it meets the baseline but does not enhance understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly states 'Read in-flight orders from the runtime state snapshot,' providing a specific verb and resource. It also gives usage examples like 'what orders are pending,' which solidifies the purpose and distinguishes it from mutation tools like cancel_order or place_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?

  The description explicitly states when to use the tool: 'Use this for what orders are pending / do I have anything sitting on Bybit.' It does not explicitly list when not to use or alternatives, but the context is clear given the sibling tool names and the read-only nature.

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

• amm_price_impactA
  4.2/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 states the output is a table of average price and price impact, precise to the wei, and mentions a required dependency. However, it does not disclose read-only behavior, error conditions, or permissions.

  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 plus a dependency note, with no wasted words. It front-loads the purpose and provides necessary input format details efficiently.

  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 no output schema, the description explains inputs (pool and sizes) and outputs (price impact table). It is adequate but could include examples or mention error cases for 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?

  Schema coverage is 100% for both parameters. The description adds clarity by specifying that sizes are 'NUMBER SYMBOL' strings and detailing the pool spec structure, going beyond the generic schema 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 states it provides a depth/slippage table for an AMM pool, listing realized average price and price impact for trade sizes. This is a specific verb and resource, and it clearly differentiates from sibling tools like price_amm_swap or compute_indicator.

  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 advises using this tool to reason about how large a trade a pool can absorb before quoting. While it gives a clear usage context, it does not explicitly state when not to use it or list alternatives.

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

• cancel_allA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden. It discloses the default dry_run=true, but does not mention other behaviors like mutability, permissions, or irreversibility when dry_run=false.

  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 with no wasted words. The first sentence states the primary action; the second adds the default and context. Very well structured.

  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 tool with 2 parameters and no output schema, the description is sufficiently complete. It explains the action, filtering option, default, and usage context. A minor gap is lack of clarity on the effect if dry_run=false.

  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 50% (dry_run lacks description). The description adds 'Default dry_run=true,' which compensates for the missing schema description. For symbol, it adds no new meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states 'Cancel every open order, optionally filtered by symbol.' It uses a specific verb (cancel) and resource (open orders), and the filtering distinguishes it from cancel_order, which cancels 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?

  The description calls it 'The most common panic stop primitive after set_kill_switch,' providing context for when to use it. However, it does not explicitly state when not to use it or compare to alternatives like cancel_order.

  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?

  No annotations are provided, so the description carries the full burden. It discloses that the tool communicates via HTTP to a local ControlServer and that dry_run defaults to true. However, it does not specify destructive behavior (order cancellation is irreversible), authentication requirements, potential errors, or rate limits. Additional behavioral context would improve 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 extremely concise, consisting of two short sentences that convey all essential information. It front-loads the primary action and immediately adds key behavioral notes. No superfluous content.

  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?

  Despite no annotations or output schema, the description covers the core functionality, usage context, default behavior, and internal mechanism. It lacks information on error handling and return values, but for a simple cancellation operation, the provided details are largely sufficient for agent invocation.

  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 description coverage, leaving the description to explain both parameters. It clarifies that order_id identifies the order and that dry_run defaults to true, adding meaning beyond the schema. It does not specify constraints like order_id format, but given the low schema coverage, the description compensates effectively.

  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 'one open order', and the method 'by id'. It directly contrasts with the sibling tool 'cancel_all' which cancels all orders, providing strong differentiation.

  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 specific use cases: 'operator-driven cleanup or panic stop'. It also mentions the default dry_run behavior. While it does not explicitly exclude other scenarios or compare with alternatives, the context is sufficient for an agent to understand when to invoke this tool.

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

• explain_eventA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Describes what it does but lacks disclosure of edge cases (e.g., both parameters given, unmatched dict). 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?

  Three tightly focused sentences: purpose, input details, usage hint. No wasted words, 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 no output schema, description specifies return structure (name, type, units, description). Lacks detail on error handling or output format, but sufficient for agent to understand capability.

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

  Parameters4/5

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

  Schema coverage is 100%, but description adds meaning by clarifying the OR relationship between type_name and event, and explaining matching behavior when type_name is omitted.

  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?

  Clearly states 'Describe the fields of a FLOX event struct' with specific verb and resource. Distinguishes from sibling tools like get_event_log by focusing on structural explanation.

  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?

  Includes explicit usage hint: 'Use when the user asks what's in this event.' Provides clear context without exclusions.

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

• get_event_logA
  4.2/5.0
  Behavior4/5

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

  States read-only nature and mentions filters AND-compose and default limit 100. No annotations provided, so description carries the burden; it covers key behavioral traits but lacks details on pagination or response 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?

  Two concise sentences with examples, front-loaded with purpose. No unnecessary words.

  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?

  Covers main use cases and parameter behavior, but without output schema, it does not explain return values. Time range parameter format is not clarified.

  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 40%; description adds context like 'Filters AND-compose' and 'Default limit 100', but does not elaborate on strategy, from_ts_ns, or to_ts_ns beyond being filters.

  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 specifies the verb 'query' and the resource 'engine event log', listing event types (signals, orders, fills, risk checks). It clearly distinguishes from sibling tools like get_open_orders or get_positions.

  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 use cases ('what happened in the last 5 minutes', 'show me all the signals from ema-trend') but does not explicitly state when not to use or mention alternative tools.

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

• get_indicator_valuesA
  4.2/5.0
  Behavior4/5

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

  Explicitly states the tool is read-only, a key behavioral trait. No annotations provided, so the description carries the burden; it does so well by clarifying the live nature of the 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 sentences, no wasted words. First sentence states the core function, second gives usage examples. Perfectly concise.

  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 tool with two parameters and no output schema, the description covers purpose, filtering, read-only nature, and use cases. Does not mention error handling for invalid strategies, but that's acceptable for this simplicity.

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

  Parameters3/5

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

  The schema has 50% description coverage; only 'name' has a description. The description adds context for 'name' ('filter to one indicator'), which matches the schema. The 'strategy' parameter is not elaborated, but the description doesn't need to repeat the schema; it adds some 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 tool returns live values of indicators in a strategy, with an optional name filter. It distinguishes from siblings like 'compute_indicator' and 'list_indicators'.

  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 concrete examples like 'what's the EMA reading' and 'is the RSI overbought now', guiding the agent on when to use it. Doesn't explicitly mention alternatives, but the examples are sufficient.

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

• record_dataA
  4.2/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 explains the underlying commands for each mode (CLI vs Python script) and the result format. It does not mention side effects like overwriting existing files, but it is transparent about the general behavior.

  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 about five sentences, each serving a clear purpose: first states the tool's function, then explains modes, then gives usage examples, and ends with the result. No unnecessary words.

  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 9 parameters, no output schema, and no annotations, the description provides adequate context for an agent to understand when and how to use the tool. It covers the high-level workflow and result usage. It lacks details on error handling or permissions, but is fairly complete for its complexity.

  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 each parameter already has a description. The description adds value by grouping parameters under modes and explaining the purpose of each mode, but it does not significantly enrich individual parameter semantics beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool captures market data into a .floxlog tape, distinguishes between live and historical modes, and gives concrete examples of user requests that trigger it. It is easily differentiated from sibling tools which cover orders, strategies, etc.

  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 explicitly states when to use the tool with examples like 'record some BTC data' or 'pull a month of klines'. It does not explicitly mention when not to use, but the context is clear and the tool's purpose is well-defined relative to siblings.

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

• list_strategiesA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so the description carries full burden. It declares the tool is read-only and describes what it returns. For a simple listing tool with no parameters, this is sufficient transparency, though it could mention error handling or empty result behavior.

  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 concise sentences with front-loaded purpose. No unnecessary words, and every sentence adds value. Highly efficient.

  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 explains the return values (name, status, symbols) despite the absence of an output schema. For a simple listing tool with no parameters, this provides complete contextual information for an AI agent to understand what the tool returns.

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

  Parameters3/5

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

  The tool has zero parameters and schema coverage is 100%. According to guidelines, baseline is 3. The description adds no parameter-specific information because there are none.

  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 lists strategies with specific attributes (name, status, subscribed symbols). It effectively distinguishes from sibling tools like get_strategy_state by specifying that it lists all known strategies and their properties.

  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 usage cues: 'Use when the user asks "what's running" / "which strategies are active"' and declares the tool is read-only. It does not explicitly exclude alternative tools but gives clear context for when to invoke it.

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

• replay_pool_tapeA
  4.3/5.0
  Behavior4/5

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

  The description explains the output (price, reserves, LP-value, impermanent-loss, drift series) and mentions the optional dependency. It does not disclose potential side effects or performance implications, but for a read-only replay tool, the behavioral coverage is good.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  The description is three sentences with no redundancy. The first sentence states the main action, the second details outputs, and the third gives use case and dependency. It is front-loaded and every sentence is 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?

  Given the absence of an output schema, the description compensates by listing return values. It also explains the relationship between parameters. However, it could mention potential data format errors or the compute-intensive nature of replaying many swaps.

  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?

  The description adds significant meaning beyond the schema: it explains that 'swaps' and 'evm_logs' are mutually exclusive, describes the format of evm_logs (data word order), and clarifies that 'pool' is the starting state. With 100% schema coverage, this description provides essential guidance.

  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 backtests a DEX position from recorded pool history by replaying swaps. It distinguishes itself from siblings like 'run_backtest' by specifying the use of recorded transcript, and from 'amm_price_impact' by focusing on time series evaluation.

  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 tells when to use it ('evaluate an LP position or trading sequence against a real transcript') and mentions a dependency requirement. However, it does not explicitly state when not to use it or compare to alternatives like 'run_backtest'.

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

• validate_strategy_no_lookaheadA
  4.3/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 discloses heuristic nature, false negatives, and specific patterns checked (AST walk, negative shift, forward-index, attribute names). However, it lacks mention of the return format or side effects (presumably read-only).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Four sentences, no fluff, front-loaded with purpose. Every sentence adds value: purpose, method, patterns, limitations. Highly efficient.

  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?

  Given single parameter and no output schema, the description lacks a hint about what the tool returns (e.g., warnings list, success indicator). Also does not clarify whether it is state-modifying (should not be). Otherwise, it covers when to use and limitations.

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

  Parameters4/5

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

  Schema coverage is 100% with a basic description of 'code' parameter. The description adds significant context by explaining what kind of code (strategy module/class) and what patterns are analyzed, enriching the schema's minimal description.

  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 is a static-analysis check for lookahead bias, a specific bug. It uses a specific verb ('checks') and resource ('strategy code's AST'), and its name distinguishes it from the broader validate_strategy sibling.

  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 usage context: 'Run before trusting any backtest result.' It does not explicitly exclude scenarios or mention alternatives, but the context is strong enough for an agent to decide when to invoke it.

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

• compute_indicatorA
  4.4/5.0
  Behavior4/5

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

  Discloses important constraints (1 MiB cap, flox-py dependency) and implies a read-only compute operation, but does not explicitly state whether it has side effects or error behavior. With no annotations provided, the description bears the full burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Four sentences, each adding value: purpose, usage guideline, input cap, dependency. No fluff, well 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 no output schema and simple params, the description covers when to use, constraints, and dependency. However, it omits the return format, which could help an agent interpret results.

  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% and already describes both parameters (name, data) in detail. The description adds context about extra parameters (window/period/smoothing) but does not enhance semantics of the required params beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool runs a single FLOX indicator over a list of floats and returns output, distinguishing it from sibling tools like list_indicators and suggest_indicator.

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

  Usage Guidelines5/5

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

  Explicitly advises using it for sanity-checking indicator behavior on small arrays before strategy integration, especially for indicators with non-obvious parameters. Also notes input cap and optional dependency.

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

• get_positionsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description fully carries the burden. It discloses the read-only nature, snapshot path logic, the special 'not_running' state, and return structure. Could mention rate limits or concurrency, but overall strong.

  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 dense paragraph that front-loads the purpose. It is concise but could be better organized with bullet points for the return format and special cases.

  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 no output schema, the description provides the complete return JSON structure and explains the pre-engine state. Parameters are fully covered, and the snapshot mechanism is clarified. No gaps remain.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the state_path parameter's fallback to FLOX_RUNTIME_STATE env var and that account/strategy are filters, elevating it above the schema alone.

  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 starts with a specific verb+resource: 'Read positions' and provides example user queries. It explicitly states read-only behavior, distinguishing it from sibling mutation tools like flatten_positions.

  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 when-to-use examples ('what's in my positions') and explains the snapshot prerequisite. It lacks explicit when-not-to-use or alternatives, 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.

• price_amm_swapA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses key behaviors: exact to wei, lossless for 256-bit values, and required dependency 'flox-py'. Does not mention rate limits or side effects, but as a read-only pricing tool, this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Four sentences, front-loaded with purpose, no fluff. Every sentence adds essential information.

  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?

  Adequately describes inputs and use cases for a complex tool with nested objects and no output schema. Lacks mention of return value (likely amount_out), but context is sufficient for an AI agent to infer behavior.

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

  Parameters4/5

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

  Schema coverage is 100%, but description adds valuable context: explains that amounts are decimal strings in native wei/lamports, lossless, and breaks down pool parameter structures per venue. Goes beyond schema 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?

  Clearly states the tool's purpose: pricing a DEX swap against various AMM pool types with exact precision (wei-level). Differentiates from sibling tools like 'route_amm_swap' and 'amm_price_impact'.

  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?

  Explicitly describes when to use: to quote a fill or measure price impact on constant-product, Raydium CP, or Uniswap v3 pools. Also mentions the required dependency. Lacks explicit exclusions but 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_strategy_stateA
  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 burden of behavioral disclosure. It states 'Read-only' (implying no side effects) and describes the output format. This is adequate transparency for a simple state retrieval tool. No contradictions with annotations (none provided).

  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-loading the action and output. Every part adds value: the verb, the output type, contents, read-only nature, and example prompts. 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?

  For a simple read-only tool with one parameter and no output schema, the description sufficiently covers purpose, parameter (via example), and return structure (JSON dict with listed fields). No further context is needed given the simplicity and sibling tool landscape.

  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 0% description coverage (no parameter descriptions in schema), so the description must compensate. It implies the single 'name' parameter is the strategy identifier via the example 'ema-trend'. While not explicitly stating the parameter's meaning, the example and context make it sufficiently clear. Baseline for zero-param schema coverage is 4, and this meets that.

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

  Purpose5/5

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

  The description clearly states the tool returns a strategy's current state as a JSON dict, specifying included fields (params, position view, last decisions). It also provides concrete usage examples ('what does strategy X think right now'), which distinguish it from sibling tools that handle orders, indicators, etc.

  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 indicates read-only usage and provides user query examples, implying when to call the tool. However, it does not explicitly exclude cases where other tools (e.g., get_positions) might be preferred, nor does it mention prerequisites like the strategy must exist. The guidance is good but lacks explicit boundaries.

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

• scaffold_strategyA
  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 full burden. It discloses that the output compiles and passes validate_strategy, includes Next steps with docs_search queries, and mentions supported languages and kinds. No contradictions, but it could mention lack of side effects.

  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 front-loaded with purpose and has clear sections for usage, language, kinds, and next steps. Each sentence adds value, though it could be slightly more concise with bullet points.

  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 complexity and lack of output schema, the description covers the essential: what it does, when to use, required input, and output context (Next steps). It is sufficient for an AI agent to invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds meaning by enumerating language options (python, node, codon, quickjs) and strategy shapes (bar-driven, trade-driven, hybrid) beyond 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 returns a starter FLOX strategy class that compiles and passes validate_strategy. It specifies verb 'Return' and resource 'starter FLOX strategy class', and distinguishes from siblings like validate_strategy and get_example.

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

  Usage Guidelines5/5

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

  Explicitly says 'use this as the *first* thing you write when the user asks to build a new strategy' and instructs to ask the user for language before calling. Also provides alternatives: 'instead of writing the FLOX bookkeeping from memory'.

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

• get_pnlA
  4.6/5.0
  Behavior5/5

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

  Despite no annotations, the description thoroughly discloses read-only nature, the output structure (realized + unrealized + fees per strategy), and an error behavior (engine_not_running idle response when no snapshot). This fully compensates for missing 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?

  Three sentences covering purpose, usage, and behavior. No fluff, every sentence serves a purpose. Front-loaded with the core action in the first sentence.

  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?

  Covers return values and error case. No output schema, but description compensates by listing realized/unrealized/fees. Doesn't mention output format or limits, but for a simple snapshot read, it's adequate.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that filtering by strategy only affects the breakdown, not the total ('total still reflects the full snapshot'). This nuance is not 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 'Read PnL totals plus per-strategy breakdown' and gives concrete query examples ('what's my PnL', 'how is strategy X doing today'). It distinctly identifies the resource (runtime snapshot) and the action (read). Among 30+ sibling tools, none overlap in purpose, making it easily distinguishable.

  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?

  Explicitly advises when to use: 'for what's my PnL / how is strategy X doing today'. It doesn't list alternatives or when NOT to use, but the context is strong enough for correct selection. Lacks explicit sibling differentiation, but the use case is narrow enough.

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

• docs_searchA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It explains query syntax (AND matching, phrase, operators), indexing scope (strict allowlist, private files never indexed), and gives canonical queries. However, it does not mention whether the docs are from a fixed snapshot or live, or any rate limits.

  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: it starts with a concise purpose statement, then details query syntax, and ends with canonical workflow queries. Every sentence adds necessary information, and there is no 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?

  Given that the tool has only two parameters and no output schema, the description is complete. It covers what the tool searches, how to form queries, when to use it, and common use-case examples. No significant gaps.

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

  Parameters4/5

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

  Schema coverage is 100% as both 'query' and 'k' are described with types and default. The description adds value by elaborating on query syntax (e.g., 'Wrap a phrase in double quotes for exact match') and providing example queries, which goes beyond the schema's basic 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 it performs 'Top-k full-text search over the FLOX documentation' and lists specific types of documents it covers. It distinguishes itself from sibling tools by focusing on documentation grounding rather than other actions like order placement or strategy validation.

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

  Usage Guidelines5/5

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

  Explicitly tells the agent to use this tool 'whenever the user asks 'how do I X' / 'what does Y do' / 'where is Z documented'' and provides canonical workflow queries mapping common user intents to specific search terms. It also contrasts with relying on training data.

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

• run_backtestA
  4.8/5.0
  Behavior5/5

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

  Discloses resource limits (CPU, memory, output size, wall-clock timeout), lack of filesystem/network isolation, return format (JSON plus stdout), and internal dispatch routing based on strategy hooks. No annotations provided; description fully covers behavioral traits.

  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?

  Concise at ~150 words, front-loaded with core action, every sentence adds value: purpose, usage, safety, return, routing. No redundancy or 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?

  Covers purpose, usage, safety, return behavior, internal routing, and parameter constraints. Despite lacking output schema, it describes the return structure. Suitable for the complexity of running arbitrary code.

  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?

  Adds defaults (symbol BTCUSDT, wall_timeout_s 60), constraints (dataset_path capped at 64 MiB), and explains strategy_code expects a flox.Strategy subclass or STRATEGY variable. Describes dispatch logic tied to parameter use. All 4 parameters have schema descriptions, but description enriches them.

  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?

  Description clearly states it runs a Python FLOX strategy against a CSV dataset in a sandboxed subprocess, specifying verb, resource, and environment. It distinguishes from sibling tools like validate_strategy by emphasizing its purpose for testing strategies on 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?

  Explicitly tells when to use: 'when the user asks try this strategy on my data or does this code actually work'. Includes a strong warning against untrusted code, but does not directly mention alternatives among siblings.

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

• flox_overviewA
  4.9/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. Discloses that the tool is 'Cheap; pure bundled text' and 'Cuts the AI-agent cycles spent rediscovering what the surface is on every fresh session.' This is sufficient for a non-destructive, static 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?

  Concise, well-structured, front-loaded with the key instruction. Every sentence adds value without 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?

  Complete for a no-parameter, no-output-schema tool. Covers purpose, when to use, and expected content. No gaps.

  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?

  No parameters exist (schema coverage 100%), so description adds no parameter info. Baseline is 4 for zero-parameter tools.

  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?

  Explicitly states the tool's purpose: 'Call this FIRST when you don't know which FLOX MCP tool to use.' Clearly differentiates itself from siblings by being the orientation tool. Provides specific details about the output (Markdown narrative organized by categories).

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: 'Call this FIRST' and 'when you don't know which FLOX MCP tool to use.' Implies it should be used before exploring other tools. No alternative exclusions needed.

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

• suggest_indicatorA
  4.9/5.0
  Behavior5/5

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

  No annotations provided, so the description carries full burden. It discloses the tool is a 'pure keyword heuristic; no LLM call' and instructs on follow-up action, providing clear 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?

  Three focused sentences: purpose with examples, usage context, and behavioral note. No wasted words, front-loaded with key 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 two parameters and no output schema, the description covers purpose, usage, behavior, and follow-up. The output is implied as a 'ranked shortlist' of indicators, which is sufficient for the tool's simplicity.

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

  Parameters4/5

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

  Schema coverage is 100% with good parameter descriptions. The description adds value by listing the specific categories the 'description' parameter maps to, which is not 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 states clearly that the tool recommends FLOX indicators based on an English description of user intent, listing example categories and distinguishing itself from sibling tools like list_indicators.

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

  Usage Guidelines5/5

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

  Explicitly says when to use ('when the user describes what they want without naming an indicator') and provides post-use guidance ('Always confirm shape with list_indicators after picking one').

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

• explain_decision
  pending
• flox_venue_guide
  pending
• get_example
  pending
• get_kill_switch
  pending
• init_project
  pending
• list_bindings
  pending
• list_capi_functions
  pending
• list_indicators
  pending
• lookup_error_code
  pending
• lookup_symbol
  pending
• set_kill_switch
  pending
• validate_strategy
  pending
• whatif
  pending