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

Annotations already declare this a pure readOnly, idempotent, non-destructive calculation, so the safety profile is covered. The description adds real domain behavior beyond that: the multiplier formula, that excess land is excluded from the exemption and taxed separately, the required follow-on 비사업용 토지 test, and the acquisition-date rule for expropriated land.

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 English summary sentence is front-loaded and states the core rule before the dense Korean detail. The legal citations and formula are information-dense with little filler, though the Korean block is long enough that structure could be tightened.

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 5-parameter calculation with annotations covering safety and no output schema, the description supplies the rule, formula, exception handling and a statutory recency note (2025-11-28). It does not indicate what the result contains (e.g., limit area vs. excess area), which is the main remaining gap.

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%, so the description carries the full burden and mostly succeeds: urban_zone is defined (주거상업공업|녹지, only distinguished when urban and capital region), and is_urban_area/is_capital_region are explained via the 도시지역 / 수도권 multiplier narrative. building_footprint_m2 is defined as 건물 정착면적(바닥면적), but land_area_m2's role in the comparison is only implicit.

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 a specific verb+resource with scope: the maximum attached land area eligible for the one-home capital gains exemption, computed by regional multiplier. It is clearly distinguishable from sibling calculators like calc_transfer_tax or calc_property_tax, which cover different tax types.

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?

Implied usage is clear (apply the exemption limit and then threshold land separately), and it notes that excess triggers a separate 비사업용 토지 judgment under 영 §168의6~14. However, it never explicitly routes the agent to or away from a sibling tool, leaving selection to inference.

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