compare_old_new

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

No annotations provided, so description must cover behavior. It describes the output (basic info and parallel changed clauses with '**변경**' emphasis) and mentions the API target parameter. Lacks details on error handling, rate limits, or maximum diff size, but is reasonable for a read-only comparison.

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?

Two tight sentences plus a short follow-up. Front-loads purpose and adds actionable usage details. No wasted words.

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?

No output schema, but description adequately explains output format (basic info + parallel changed clauses with highlights). Could mention if comparisons are limited in scope (e.g., only clause-level changes), but generally sufficient for its purpose.

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?

The schema describes `mst` as law serial number. The description adds critical context: it accepts both old and new law serial numbers from search_law or get_law_history, clarifying how to use the single parameter.

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 the tool compares old and new versions of a law (법령 신구법 비교), listing basic info and changed clauses with highlights. It distinguishes from siblings like compare_articles and get_historical_law by focusing on parallel comparison of two versions.

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?

Explicitly says to use for tracking differences in frequently amended laws (e.g., PIPA) and gives an example date range (2023.9 → 2025.10). Also directs to follow-up tools: get_historical_law for full text and get_law_history for other time comparisons.

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