legal_analysis

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

Despite rich annotations (readOnly, openWorld, idempotent, non-destructive), the description adds substantial behavioral context beyond them: the 실존불가/미확인 (impossible/unconfirmed) distinction for cases, change/abolition detection for lineage, temporal act-time analysis with 부칙 경과조치, and graph+mermaid output generation. It discloses internal decision logic and output characteristics that annotations alone cannot convey, with no contradiction against the visible hints.

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 dense and front-loaded with the value proposition ('법제처 DB 교차검증, LLM 환각 방지') before mode breakdowns, using clear '|' and '—' separators to partition the four modes. It is a long single block, but every segment earns its place given the 4-mode complexity; slightly more whitespace or bullet structure would improve scannability.

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 complex 4-mode tool with 11 parameters and no output schema, the description covers each mode's trigger, required inputs, and key behaviors, including output hints like mermaid graphs and the '빠르지만 변경·폐기 감지 생략' tradeoff. It does not detail exact return structures, but given the mode-specific nature and rich schema, this is adequately complete for the complexity.

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% — every parameter already documents its format and mode-required markers (e.g., jo's natural-language and 6-digit code acceptance, deepScan's fast-scan tradeoff). The description's mode↔parameter mapping table and jo format acceptance adds a consolidated perspective but largely restates what the schema already encodes, so it does not significantly exceed the baseline.

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 a specific aggregate verb ('검증·분석 4종 통합') and unpacks four distinct analysis operations with concrete outcomes: cross-validating citations against the Ministry of Government Legislation DB, reverse-tracing case citations, determining act-time applicable law, and generating reverse citation graphs. It distinguishes from siblings (search_law, search_decisions, get_law_text) by being an analysis/verification tool rather than a retrieval tool, with each mode's purpose precisely named (verify_citations, cite_check, applicable_law, impact_map).

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 includes explicit purpose and required parameters ('text 필수', 'caseNumber 필수', 'lawName+date 필수', 'lawName+jo 필수'), effectively telling the agent which mode fits which scenario (e.g., 'LLM 환각 방지' for verification, '행위시법 판단' for temporal applicability). However, it lacks explicit when-not-to-use guidance or alternatives versus sibling tools like legal_research or search_law — exclusions are implied rather than stated.

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