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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral semantics beyond that: the special period is date-dependent (2024-11-12 / 2018-02-13 cutoffs with prior 5-year rules), triple stacking of §155 reliefs is disallowed, and the marriage household count is taken at the merge date rather than the sale date. This is meaningful disclosure the annotations do not carry.

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?

Front-loads the plain-English purpose before the Korean detail, and the compact pipe-delimited kind list efficiently conveys the enum values. It is dense but not padded; the main cost is that the mixed-language formatting with bold markers and parenthetical citations is harder to parse than a clean list.

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 19-parameter judgment tool with only 1 required parameter and no output schema, the definition covers purpose and the key legal rules but leaves large gaps: most boolean/numeric inputs are uninterpreted, and there is no indication of how the verdict is composed or which inputs drive which case branch. Annotations cover the return-safety profile, so the remaining gap is parameter completeness.

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 0% with 19 parameters, so the description carries the burden and partially meets it: it supplies the kind values (⑤혼인, ④동거봉양, ②상속주택, ⑳거주주택), explains sale_date's role, the excluded_homes_* subtraction, and the meaning of parent_is_female for pre-2009-02-04 merges. However the majority of parameters (first_time_use, rental_registered, designated_by_agreement, residence_years_in_home, is_first_priority_inherited, separate_household_at_inheritance, general_home_acquired_before_inheritance, etc.) remain entirely unexplained.

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?

States the resource precisely: art. 155 Income Tax Decree one-home special cases, and enumerates the four case kinds (marriage, parent care, inherited, rural) plus the Korean 판정 verb. An agent can distinguish it from judge_156_3_special or judge_inherited_house_priority by the article number, though it never explicitly contrasts with them.

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?

Gives concrete use conditions: sale_date must be supplied for past transfers in 상담/경정청구 cases, excluded_homes_* must be subtracted before a 1+1 judgment, and the tool links into count_transfer_homes input flags. It never states when NOT to use this tool or names a sibling alternative, so it falls short of a 5.

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