legal_research

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

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds genuinely non-structured behavior: document_review requires the text field, scenarios auto-detect from the query, task/scenario compatibility is constrained, and includeHistory warns that its section can exhaust the response budget and truncate the comparison table (#158). It does not address runtime cost despite the 'parallel API' fan-out, which would be useful.

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 long but front-loaded with the identity line, then an efficient pipe-delimited task table where every entry earns its place by decoding a cryptic enum and adding an example. Density is high and justified for a 13-parameter dispatcher, though the scenario enumeration restates much of what the schema already encodes.

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, zero-required-parameter, no-output-schema tool, the description covers routing, per-task prerequisites (text for document_review, query for all others), scenario compatibility, and one documented failure mode with an issue reference. What is missing is any indication of cost/latency or expected response shape for a tool that orchestrates several APIs in parallel.

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 baseline is 3, but the description does real work the schema cannot: it gives meaning and example queries for the otherwise opaque task enum values, and it explains the task-to-scenario compatibility matrix that the schema only alludes to via a cross-reference. The domain enum and per-task parameter tags are also clarified ([time_travel], [ordinance_compare], etc.).

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 concrete verb+resource ('다단계 법령 리서치 통합' running multiple APIs in parallel) and enumerates the eight research modes with representative example queries for each. It also explicitly distinguishes itself from siblings by stating that single-lookup questions should use search_law/get_law_text instead.

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 task value is paired with a when-to-use condition and an example query ('음주운전 처벌 기준', '관세법 체계', '과세처분 불복'), and the closing sentence gives an explicit exclusion routing single queries to search_law/get_law_text. Alternative selection between search_law, get_law_text and this tool is unambiguous.

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