get_move_context

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

Annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already establish a safe, read-only profile. The description adds substantial semantic caveats beyond that: the tool does not determine cause but only arranges facts chronologically; zero disclosures does not mean no material since press releases/articles are not disclosures; and partial failure is reported as '조회 실패' (unknown), not absence. These nuances materially affect how an agent interprets results and go well beyond what annotations convey.

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 front-loaded with the core purpose and use cases, followed by behavior caveats. Every sentence carries functional weight — the caveats about cause determination, zero-disclosure interpretation, and partial failure are all genuinely necessary for correct usage. It is somewhat dense and long, but there is no filler or repetition.

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 single-parameter aggregator with an existing output schema, the description is complete: it covers what is aggregated, when to use it, what it does not do, result interpretation caveats, and the parameter format. The output schema covers return structure, and annotations cover the safety profile, so nothing an agent needs to invoke it correctly is missing.

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 must compensate for the parameter documentation gap. The Args section provides code: '종목코드 6자리 (예: "036090")' — specifying the 6-digit format and giving a concrete example. This is sufficient compensation for a single parameter, though the description could optionally add validation guidance (e.g., leading zeros).

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 opens with a precise statement of the tool's function: it aggregates price, trading-volume multiples, articles, exchange disclosures, and securities-firm reports in chronological order. It explicitly names the sibling tools it replaces (get_price, get_disclosure, get_flow) and lists concrete user questions ('오늘 왜 오르나', '급등 이유') that this tool answers first, making its purpose unmistakable and clearly differentiated from siblings.

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 guidance is explicit and prescriptive: it instructs the agent to use this tool FIRST for 'why did it move' queries and explicitly warns NOT to chain get_price → get_disclosure → get_flow separately. It also routes to get_intraday_chart for a specific follow-up need (verifying whether article timing precedes price reaction), providing both when-to-use and when-not-to-use guidance with alternatives named.

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