Server Quality Checklist

Tool Scores

• get_order_blocksC
  2.3/5.0
  Behavior2/5

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

  No annotations provided, so the description carries full burden. It mentions 'mitigation status' as an output detail, but does not disclose any behavioral traits (e.g., read-only, required permissions, computational cost, side effects). The description is too sparse to inform safe usage.

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

  Conciseness2/5

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

  The description is extremely concise (one sentence), but it fails to cover essential aspects like parameters, usage, or behavior. It is under-specified, not efficiently informative. Every sentence should earn its place; here it barely does.

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

  Completeness1/5

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

  Given the complexity (4 parameters, no schema descriptions, no annotations), the description is woefully incomplete. It does not explain how to configure the tool for typical tasks, nor does it leverage the existing output schema. An output schema exists, but the description still lacks necessary input behavior context.

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

  Parameters1/5

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

  Schema coverage is 0%, yet the description provides no information about parameters. The 4 parameters (symbol, limit, timeframe, impulse_pct) remain entirely unexplained. The description adds zero value beyond the schema's raw JSON structure.

  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's purpose: detecting order blocks with mitigation status. It uses a specific verb ('detect') and resource ('order blocks'). However, it does not explicitly distinguish from sibling tools like get_fair_value_gaps or get_market_structure, but the concept is distinct enough.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. No context on prerequisites, typical scenarios, or when not to use it. Users must infer based solely on the concept name.

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

• get_market_structureC
  2.7/5.0
  Behavior2/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 does not disclose behavioral traits such as data freshness, error handling, or required permissions. It only states the output content.

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

  Conciseness3/5

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

  The description is concise with two clauses, but it lacks structured organization. It could benefit from breaking down the components or providing more detail without adding verbosity.

  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 the presence of an output schema and three parameters with no descriptions, the description fails to provide sufficient context about return format or parameter usage, leaving the agent underinformed.

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

  Parameters1/5

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

  Schema coverage is 0% and the description does not explain any of the three parameters (symbol, timeframe, limit). No additional meaning is added beyond the schema field titles.

  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 provides a current trend read and identifies break-of-structure (BOS) and change-of-character (CHoCH) events, which distinguishes it from sibling tools like get_fair_value_gaps and get_liquidity_zones.

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

  Usage Guidelines2/5

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

  No guidance on when or when not to use this tool, nor any mention of alternatives. The description only states what the tool does without providing context for selection.

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

• get_fair_value_gapsC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry full behavioral transparency. It only states the core detection function, without disclosing auth needs, rate limits, or what 'fill/mitigation status' entails. The behavior is implied but not elaborated.

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

  Conciseness3/5

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

  The description is a single sentence with no fluff, but it may be too brief for a tool with five parameters. It front-loads the core purpose but lacks structure for detailed guidance.

  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 the complexity of 5 parameters and no schema descriptions, the description is insufficient. The presence of an output schema partially compensates, but the tool lacks usage guidelines and parameter context, making it incomplete.

  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 0%, and the description adds no information about the five parameters (symbol, limit, timeframe, min_gap_pct, unfilled_only). Parameter names are somewhat self-explanatory, but the description provides no additional semantics.

  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 uses a specific verb ('Detect') and resource ('3-candle fair value gaps'), clearly distinguishing from sibling tools like 'get_liquidity_zones' or 'get_market_structure'. It also specifies the additional feature of fill/mitigation status.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites or context that would help an agent choose between this and sibling tools.

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

• get_liquidity_zonesB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behaviors. It states the detection algorithm (clusters of equal highs/lows) and output sorting, but omits details like computational cost, data requirements, or how parameters like tolerance_pct affect results. It is moderately transparent but lacks depth.

  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 totaling 40 words, with no filler. The first sentence clearly defines the tool's purpose, and the second describes the output. Every sentence adds value.

  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 five parameters (one required), no schema coverage, and no annotations, the description should explain how each parameter influences the detection algorithm. It does not, leaving the agent without enough context to set parameters correctly for specific analysis goals. The return structure is only vaguely described.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning no parameter is explained in the description. The description does not add any meaning beyond the input schema's titles and defaults, leaving all five parameters (limit, symbol, timeframe, min_touches, tolerance_pct) unexplained.

  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 uses specific verb 'detect' and resource 'resting-liquidity levels', defines them as clusters of equal highs (buy-side) and lows (sell-side), and mentions output characteristics (sorted by distance, touch count, swept status). This clearly distinguishes it from sibling tools like get_fair_value_gaps or get_order_blocks.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or scenarios where this tool is preferred. The agent is left to infer usage context from the purpose alone.

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

• get_snapshotB
  3.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 returns structure, liquidity, FVGs, and order blocks, but it does not discuss any behavioral traits such as read-only nature, performance, or how 'nearest' or 'unfilled' are determined. The description is adequate but lacks depth.

  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 sentence that is concise and front-loaded with the key concept 'One-call snapshot'. However, it could be slightly more detailed without losing conciseness, such as clarifying the parameters.

  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 the complexity of the tool (aggregating three concepts) and the existence of an output schema, the description is partially complete but fails to explain the decision criteria for the aggregated elements (e.g., what 'nearest' means) and leaves parameter semantics entirely undeclared.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of the parameters (symbol, limit, timeframe) beyond their names. The agent must infer their meaning, which is insufficient for correct invocation.

  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 provides a 'snapshot' combining market structure, nearest liquidity, unfilled FVGs, and recent order blocks, which differentiates it from sibling tools that focus on individual components. The verb 'snapshot' implies a composite view, making the resource and action specific.

  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 quick overview of multiple market concepts in one call, but it does not explicitly state when to use this tool versus the more specific siblings, nor does it provide when-not scenarios or alternatives.

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