realestate.kr_comprehensive

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, and the description adds meaningful computation context (basic deduction, fair-market ratio, progressive vs corporate rate, property-tax credit, age/holding credits, prior-year cap). However it omits rounding behavior, that policy_status is an output rather than an input, and says nothing about the result shape.

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?

Four sentences, front-loaded with purpose then method then caveat, with no filler. Dense but every clause carries information; only the 'policy_status' sentence is slightly ambiguous about whether it is an input or output.

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 12-parameter tax calculator with an output schema present, the description supplies the domain logic and the key parameter mappings an agent needs to invoke it correctly. Remaining gaps are minor parameter definitions rather than missing behavioral facts.

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?

With 0% schema coverage, the description compensates well: 공시가격 합계 maps to total_published_price, 법인 단일세율 to is_corporate, 연령·보유 to age/holding_years/residence_years, 직전 연도 총세액 to prior_year_total_tax, 확정 전 개정안 to include_proposed. Still silent on year, as_of, property_tax_levied, and resident_house_price.

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 (계산한다) and resource (주택분 종합부동산세 + 농어촌특별세), including the mechanical summary of how the tax base and rates are applied. It also distinguishes itself from the sibling realestate.kr_property_tax and tax.kr_rural_special_tax by naming the housing-only scope.

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 explicit exclusions ('오용 예: 토지분에 사용') and premises ('2주택 이하·3주택 이상', '법인 단일세율') that indicate when the tool applies. It lacks a pointer to which sibling handles the land portion, so the alternative is implied rather than named.

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