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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behavioral details: fetching klines, windowed aggTrades, OI history, and force orders via a proxy relay, running a pure engine, and explicit fault-tolerance when liquidation data is empty or fails (falling back to OI velocity + CVD absorption). This provides significant decision-relevant information about data dependencies and failure behavior.

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

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

Three tightly packed sentences: the first defines the detection logic, the second summarizes data fetching and engine execution, and the third explains fault-tolerance. The most essential pattern definition is front-loaded, with no filler or redundant restatement of schema fields.

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

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

The description thoroughly covers the detection pattern, data sources, and failure-handling behavior, and the schema covers all parameters. However, with no output schema, it does not explicitly describe the returned verdict's structure or fields, and it lacks explicit comparison to sibling tools. These are minor gaps given the strong overall informational density.

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

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

Schema description coverage is 100%, so all four parameters (symbol, interval, atrSweepMult, lookbackBars) already carry meaningful definitions. The description does not add parameter-specific semantics beyond the schema; it contextualizes the overall strategy but doesn't elaborate on how each parameter influences detection, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool's purpose with a specific verb ('Deteksi') and resource ('pola liquidity sweep'), and spells out precise detection criteria: active candle breaks an isolated swing high/low from previous candles, closes back inside range, and is confirmed by CVD absorption + OI flush. This is sharply distinguished from sibling tools like whalescope_full_pipeline and analyze_cvd_divergence because it names its own composite pattern and engine.

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

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

Usage context is implied through the detailed pattern description and the fault-tolerance note, but there is no explicit statement of when to use this tool over alternatives such as whalescope_full_pipeline or analyze_cvd_divergence. No exclusions or alternative routing guidance are provided, so the agent must infer the appropriate scenario from the pattern definition.

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