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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict these. It adds meaningful context: the output is 'research evidence, NOT a buy or sell recommendation' and includes a caveat about symbol matching the lowercase filename. This goes beyond the structured annotations by explaining the nature and limitations of the return data.

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

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

The description is well-structured with clear headings (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loaded with the core purpose. While the trigger examples are helpful, they are somewhat redundant given the explicit 'When to call' section, making the text slightly longer than strictly necessary.

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?

For a tool that aggregates multiple data sources, the description is remarkably complete. It explains the composition of the return (three components), provides prerequisites, notes that it ends the explanation chain, and includes a disclaimer. Even without seeing the output schema, the agent understands what to expect and how to prepare inputs.

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 0%, so the description carries full responsibility. It provides substantial semantics: market_id lists allowed values and aliases ('crypto, kr_stock, us_stock; aliases coin/kr/us'), and symbol gives concrete examples ('btc, eth, 005930') plus the lowercase rule. This fully compensates for the schema's missing descriptions.

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 begins with a specific verb-resource combination: 'Multi-layer explanation for a single symbol's recent research signal.' It enumerates the three combined components (technical score_trace, Thompson + regime scores, news causality) which clearly distinguishes it from sibling getter tools. The statement 'present a structured "why" rather than a raw verdict' further differentiates it from tools that return raw data or verdicts.

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?

Explicit 'Use this when' and 'When to call' instructions are provided, including example triggers in both English and Korean. Prerequisites identify prior steps ('identify the symbol via get_signals or get_latest_decisions first') and 'Next steps: none' clarifies workflow completeness. However, it does not explicitly name alternative tools to avoid, so it lacks direct exclusions.

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