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

Annotations already declare a pure, side-effect-free computation (readOnly, idempotent, non-destructive, closed-world). The description still adds meaningful behavior: '하나라도 틀리면 결론이 뒤집힌다' warns that a single mis-set §154①5호 fact flips the verdict, and it notes acquired_in_adjusted_area must reflect '취득 당시' designation and that a non-resident lease voids the sangsaeng special case. Return format is not described, but the safety profile is fully covered by annotations.

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 purpose is correctly front-loaded and no sentence is decorative, but the body is a dense wall mixing English and Korean with inline statute citations (§89①3호, §154①5호), which makes it hard to scan for a downstream agent. Compression is high but structural signposting is weak.

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 16-parameter, no-output-schema judgment tool, the description covers the decision rule, the trickiest parameter interactions, and the pipeline position, so an agent can call it correctly without opening the docs. The main omission is what a '판정' result contains, though the absence of an output schema makes that less load-bearing.

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 16 parameters, so the description carries the whole burden and responds well: it enumerates waiver_reason values (""|건설임대5년거주|수용|해외이주2년|취학근무국외|부득이1년거주), acquisition_cause values (매매|분양|증여|상속|자가건설|조합가입), and explains the four decomposed facts contract_before_adjusted_announce, deposit_paid_in_full, no_home_at_contract and the succession condition for same_household_succession. Gaps remain for about seven params (sale_price, holding_years, residing_years, sangsaeng_rental_ok, is_usage_converted_after_contract, etc.) that are unaddressed in both schema and description.

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 opening line states a specific verb+resource+scope: 'Full one-household-one-home capital gains exemption test: holding, residence, price cap, adjusted area.' It also positions itself in a pipeline (tree ④) and names where the output goes (judge_transfer_reliefs), which separates it from the many sibling 'judge_*' tools. The heavy Korean legal parentheticals dilute readability but the purpose is unambiguous.

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?

The description states its inputs are the outputs of tree① (household) and tree② (home count) and that the verdict feeds judge_transfer_reliefs' meets_exemption_requirements field, which gives real sequencing context. However, it never says when to prefer this over alternatives like judge_second_home_exclusion or judge_temporary_two_homes, so selection guidance is only implied.

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