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

Annotations already establish a safe read (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds substantive behavior: the disposal deadline varies by sale date (3-year vs graduated 2/1-year rules), the lease-end extension cap (acquisition+2 years), and that omitting prev_sale_date yields only the current-law 3-year deadline, plus a tax-category branch flag in the result.

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 first sentence front-loads purpose and legal basis well, but the body is dense, mixes English and Korean mid-stream, and packs a large amount of statutory detail. Most content is relevant to a complex rule, yet the sizing and language switching make it harder to scan than necessary.

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?

There is no output schema and 11 parameters at 0% coverage, so the description must be self-sufficient. It covers the core legal logic and the return flag, but does not fully define all inputs or clarify what the judgment returns in each branch, leaving gaps for an agent to resolve.

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% across 11 parameters, so the description must carry the burden. It adds the date format (YYYY-MM-DD), explains prev_sale_date omission behavior, and points to judge_adjusted_area_at_date for the two adjusted-area booleans, but leaves several parameters (prev_meets_exemption, one_year_rule_waived, moved_in_within_1y, new_contract_date) without direct semantic definition, so compensation is only partial.

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 judgment task (temporary two-home exemption test) and enumerates its components: one-year gap, disposal deadline, move-in requirement, with the exact legal citation (Income Tax Decree art. 155(1)). It also distinguishes itself from the sibling acquisition-tax tool (취득세 일시적 2주택) as a separate tax category, so an agent can tell it apart from other judges without opening schemas.

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?

It explicitly routes the agent to a sibling: check adjusted-area status via judge_adjusted_area_at_date for each acquisition/sale date before invoking this tool. It also gives when-to-use context (past transfer correction claims and tax audit consultations). It lacks an explicit when-not condition, but the prerequisite and scenario guidance are clear.

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