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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses operational tradeoffs the schema does not: maxCitations means '많을수록 느림', and deepScan=false is '빠르지만 변경·폐기 감지 생략', and includeOrdinances=false skips the nationwide ordinance fan-out. It also explains the epistemic output distinction for citations (실존불가 vs 미확인), which is exactly the kind of behavioral context an agent needs to interpret results.

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 leading purpose sentence is front-loaded, but the mode breakdown is a single dense pipe-delimited run-on mixing purpose, required params, examples, and edge cases in one breath, making it harder to scan than a structured list would be. The volume is defensible for a four-mode tool, yet the formatting costs readability.

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?

All four modes are covered with required inputs, accepted formats, and defaults, which is strong for an 11-parameter multiplexed tool with no output schema. The only gap is that return shapes are only hinted at (mermaid graph, citator status) rather than characterized, and there is no note on failure behavior when a cited provision cannot be resolved.

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 coverage is 100%, so the schema alone already justifies a 3; the description goes further by tying each parameter to its mode and explaining why (e.g., applicable_law resolves renaming laws to their old-name versions and handles administrative rules like 'NFTC 103'). The mode-to-parameter mapping table in prose adds navigational value beyond the flat per-property schema 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 names a specific resource (Korean statutory/case-law citations) and enumerates four distinct operations with concrete examples like '민법 제750조' and '대법원 2013다61381', so an agent knows exactly what each mode does. It frames the tool as the '[정밀분석] integrated 4-mode' option, which implicitly separates it from lookup siblings such as get_law_text or search_decisions, but it never names those siblings directly.

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?

Each mode carries its own trigger condition and required inputs (verify_citations needs text, cite_check needs caseNumber, applicable_law needs lawName+date, impact_map needs lawName+jo), and one use case is spelled out explicitly ('LLM 환각 방지'). What is missing is guidance on when to prefer legal_research or search_law over these modes, so selection against siblings is still inferred.

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