validate_candle_data

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

With no annotations provided, the description carries full responsibility. It discloses the tool's behavior: detects anomalies, auto-determines liquidity tier, applies thresholds based on crypto fat-tail and zero-volume considerations, and allows manual threshold adjustment. It does not explicitly state whether the tool modifies data (it implies read-only), nor the exact output structure beyond the score, but the threshold auto-logic is described in detail.

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?

The description is efficient, starting with a clear purpose, then listing detection types, then explaining threshold logic. It uses a structured header '[Data Quality / Validation]' to signal the domain. Each sentence adds value, and it avoids fluff, though it is slightly longer than ideal due to the detailed threshold explanation.

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?

Given the tool has 7 parameters and no output schema, the description should clarify the return format. It mentions '0-100の品質スコア（A-F）' but does not describe whether the output includes anomaly details, a breakdown, or just the score. This leaves an agent uncertain about how to consume the result. The threshold behavior is well-covered, but the missing output structure is a notable gap.

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?

The schema descriptions cover most parameters, but the description adds critical context beyond the schema: it explains that price_sigma and volume_multiplier have auto-set defaults based on the pair's liquidity tier (major/mid/minor), and that the tier is automatically determined. This enriches the meaning of those parameters and compensates for the pair parameter lacking a schema description. The focus on auto-tier logic is a meaningful supplement.

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 states the tool validates OHLCV candlestick data ('OHLCVローソク足データの品質検証') and lists specific detection targets: completeness, duplicates, OHLCV consistency, price anomalies, and volume anomalies. It also mentions computing a 0-100 quality score with grade A-F. This goes beyond a vague 'validate' and gives concrete, actionable purpose that differentiates it from sibling analyze and get tools.

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?

The description explicitly states the use case: '分析やバックテスト前に「このデータ信用できる？」を確認するためのツール' (tool to check if data is trustworthy before analysis or backtesting). This gives a clear temporal context. However, it does not explicitly name alternative tools or conditions when NOT to use it, though the context implies it is a pre-processing step distinct from analysis tools.

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