budongsan-tax

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

Annotations already cover the read-only/idempotent/no-side-effect profile, and the description adds meaningful behavior: the year-required change with rationale, mutual exclusion of heavy_type and rate_special, the rule that omitted surtaxes are treated as 0, and the shape of the returned dict. It loses a point because the 0-vs-(-1) sentinel semantics in the text conflict ambiguously with the schema defaults of -1.

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 front-loaded, but the body is very long and repeats itself across English and Korean, weaving in statutory citations, numeric examples, and parenthetical asides that an agent invoking the tool does not need. Much of the §151①/§13의2 detail duplicates what the formulas already encode.

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 an 11-parameter, no-output-schema tool this is nearly complete: rate provenance, parameter interactions, default handling, and the return keys are all present, making the missing output schema largely harmless. The residual gaps are the sentinel defaults and an explicit handoff to the judge_* siblings.

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% and has 11 parameters, so the description carries the full burden—and it largely does, explaining year, standard_rate, heavy_surcharge_rate, the two surtax rates, ordinance_adjustment_rate, rate_special's legal basis, acquisition_type's rate bands, and exclusive_area's 85㎡ threshold. The unexplained -1 sentinel defaults (e.g. standard_rate=-1) keep it from a 5.

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 names a specific verb+resource and scope: acquisition tax (취득세) on real estate plus the two surtaxes, parameterized by year and acquisition type. It is clearly distinct from sibling calculators such as calc_transfer_tax and calc_property_tax, and the bilingual restatement reinforces the purpose.

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 gives real workflow guidance: rates must be sourced via search_law("지방세법") rather than assumed, the function only applies the formula and does not judge which rate applies, and heavy_type/rate_special are mutually exclusive. It stops short of explicitly routing the agent to the judge_* determination tools (e.g. judge_acquisition_homes_and_rate) that must run first.

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

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.

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

Annotations already cover the read-only/idempotent/non-destructive safety profile, yet the description adds real behavioral content: the exact max() formula, which asset classes trigger the heavy rate (§104①1·8·10, §104⑦), that the caller must supply already-fixed rates, and that both scenarios are always returned because their difference is the decision value.

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-loaded with the EN/KR statement of purpose, then the formula and per-parameter notes, then the return behavior. Dense with legal citations and math but each sentence contributes; nothing is padded.

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?

With no output schema, the description steps in by stating that both scenarios are always returned and that their difference is the decision value. Combined with the formula and asset-scope rules, an agent has enough to invoke and interpret it correctly, though it says nothing about the caller's responsibility to fix tax rates beyond a single aside.

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%, so the description must carry the load, and it largely does: it documents the item shape of housing_trade_profits ([{라벨, 매매차익, 양도세율}]) and tax_brackets ([{upto, rate, deduction}]), and conveys the meaning of the two scalar params through the formula (종합소득 산출세액 / 과세표준). Key names are English while described in Korean, a minor mismatch.

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: comparative taxation computation for real estate dealers under Income Tax Act §64, with the decision it supports (whether switching to business-status avoids the heavy rate). It is clearly distinguishable from sibling calculators by being the §64 comparative-tax one, though it never names a sibling to differentiate against explicitly.

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?

One line hints at the decision context ('사업자 전환으로 중과세율을 피할 수 있는지 계산'), which implies when to reach for it. But there is no statement of when-not to use it, no prerequisites, and no routing to the many sibling calc_/judge_ tools for the underlying determinations.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low. The description adds genuine behavioral context: supplying `penalty` changes the result to include 결정기준_납부세액/가산세/가산세_내역/총부담세액, and omitting it yields the prior output. It stops short of describing the default (non-penalty) return 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?

The one-line English summary is front-loaded followed by dense but purposeful Korean detail; every clause carries a statute reference or threshold. It is long and mixes languages, and phrases like the internal '12차 순회까지 법문 확정 상수 사용' note are noise rather than agent-relevant signal.

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 an 11-parameter tax engine with no output schema, the description covers nearly all inputs and the conditional return fields well. Remaining gaps are the unconditional output shape and the unexplained `year` parameter, which keeps it just short of complete.

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 largely does: it explains taxable_value (시가 평가, 부담부증여 채무 차감), the relationship enum with its six deduction tiers, generation_skip rate logic, prior_gifts_10yr, prior_gift_tax_paid, marriage_birth_deduction, filing_credit_rate, and the penalty dict's keys. Only `year` is unaddressed and `is_minor_recipient` is merely implied, both minor.

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 and resource (Korea gift tax on real estate) plus the domains it covers: relationship deductions, marriage/birth deduction, prior gifts, progressive rates. This clearly separates it from siblings like calc_inheritance_tax, calc_transfer_tax, and calc_acquisition_tax, which cover other 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?

The description gives real when-not guidance by listing unsupported cases (이월과세 §97의2, 저가양수 증여의제 §35, 창업자금·가업승계 특례) and pushes valuation to a separate step (평가 별도). It doesn't explicitly contrast against sibling calculators, so routing is inferred rather than spelled out.

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

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

Annotations already declare this as a safe, read-only, idempotent, non-destructive computation, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond that: the ⚠️미지원 section explicitly lists unsupported features (금융재산공제 §22, 가업/영농상속공제, 단기재상속 세액공제 §30, post-death valuation linkage) and states the default assumption (일괄 5억). This tells the agent exactly where the tool's results stop being reliable.

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 statement is front-loaded and the parameter notes are grouped logically, but the body is dense and mixes Korean and English with symbolic markers, and several clauses are terse enough to require re-reading. Given 0% schema coverage the length is largely justified, but formatting could be tighter and more uniformly scannable.

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 an 11-parameter tool with no output schema and no schema descriptions, the description covers the consequential parameters and conditionally reveals the penalty-mode output keys (결정기준_납부세액, 가산세, 가산세_내역, 총부담세액). However, four parameters remain unexplained and the default (non-penalty) output shape is never described, leaving an agent unable to interpret normal results without experimentation.

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 it does substantial work: it defines taxable_value (과세가액 derivation), spouse_actual_inheritance / spouse_legal_share_cap (§19 min rule), use_lump_sum_deduction (§21 단서 caveat), cohabit_house_deduction (§23의2 limits), generation_skip_portion (0~1 with 30%/40% surcharge), and gives an exceptionally detailed key-by-key spec for the penalty dict. It still leaves year, other_deductions, filing_credit_rate, and over_2b_minor_skip entirely undocumented, so it does not fully compensate for the coverage gap.

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 sentence names a specific verb+resource ('Korea inheritance tax (상속세)') and enumerates the mechanisms it covers (basic, spouse, lump-sum deductions, progressive rates, estate basis). The 'estate basis (유산세 방식)' qualifier and the Korean-language restatement clearly separate it from sibling tax calculators such as calc_gift_tax and calc_transfer_tax.

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?

There is no explicit when-to-use guidance or routing to alternatives among the many tax/judge siblings. The only conditional guidance provided concerns the optional 'penalty' argument ('주면 … 안 주면 종전 출력 그대로'), which is parameter-level behavior, not tool selection. An agent still has to infer whether to use this tool versus calc_gift_tax or the judge_* nodes.

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

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

Annotations (readOnly, idempotent, non-destructive, closed-world) are consistent with a pure calculator, and the description adds far more: unsupported §9⑦⑨ special-case apportionment raises a flag and overstates credit, the burden-cap direction differs between current year (cap applied) and prior year (cap excluded), rural special tax defaults to 0 when unverified, and manual passes produce warnings. This is unusually rich disclosure of failure modes and side conditions.

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 and the critical input guidance are front-loaded, but the body is an unusually long statutory citation dump with inline formulas that belong in documentation. While many warnings are substantively useful, the block is dense, repetitive, and hard to scan, so an agent must wade through legal text to extract the operational instructions.

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?

With no output schema and 18 parameters, the description does explain the domain well: what triggers internal computation, what is flagged when unsupported, and roughly what is returned (a step-by-step dict for verification). It still does not map every parameter, but for a tool of this complexity it conveys enough to call it correctly and interpret results.

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 18 parameters, so the description must carry the full burden. It explains year, prev_year_official_price, tax_brackets (per home-count table), and that the caller determines basic_deduction, but leaves several parameters unaddressed, notably the -1 sentinel defaults for age_credit_rate, holding_credit_rate, property_tax_credit, and rural_special_tax_rate, plus credit_cap, fair_market_ratio, and burden_cap_ratio. It compensates meaningfully but not completely.

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 first two sentences give a specific verb+resource (compute Korea comprehensive real estate holding tax on housing) plus the exact scope it covers (deductions, progressive rates, property-tax credit, age/holding credits, burden cap). It is clearly distinguishable from siblings like calc_property_tax, calc_acquisition_tax, and calc_transfer_tax, which target other 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?

It states when specific inputs matter: year is mandatory (rates/deductions read from constant tables), prev_year_official_price is recommended because it makes the code compute §4의3 credit, current-year property tax, and prior-year total tax, and it warns when manual passing is acceptable but error-prone. It also says the §8④ deemed-one-home determination comes from the household-determination tree output. However, no sibling tools are named as alternatives, so routing is implied rather than explicit.

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

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

Annotations already establish a safe, deterministic, idempotent read operation, so the description's job is to add beyond that — and it does: calculation is refused with ParamNotVerified for unverified years, explicit arguments take precedence over the constant table, and the result records a '값 출처' (value provenance). The background anecdote about a prior calculation error is not strictly behavior, but the operational contract is well disclosed.

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 is front-loaded and the Korean argument list is well organized, but the statutory-citation block and the historical incident anecdote add length beyond what an agent strictly needs to invoke the tool correctly. Given nine parameters and five statutory rules, the length is largely earned, so this is not a structural failure.

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?

No output schema exists, but the description states the return shape (per-step dict plus value provenance) and the failure mode (ParamNotVerified). For a nine-parameter tax calculator whose rates live in an external constant table, everything an agent needs to call it correctly — required year, upstream table lookup, precedence of explicit args, cap handling — is present.

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 description coverage, the description carries the full burden and covers all nine parameters, including the non-obvious sentinel semantics (fair_market_ratio=0 and negative rates read from the constant table; urban_area_rate=0 explicitly means 'not applied'; taxable_base_cap=0 with prev_year_official_price triggers auto-computation). It also clarifies that one_home is judged at household level, not per individual.

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 first line names a specific verb and resource (Korea property tax on housing) and enumerates the components computed: fair-market ratio, base cap, one-household special rate, urban area levy, education tax. The sibling list is a set of distinct tax calculators, and the mention of housing-specific rules (재산세 주택분) plus the §122 note about land/buildings makes the scope distinguishable.

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?

Usage context is clear: it is the housing property-tax calculation, and the parameter notes tell the agent that prev_year_official_price is '사실상 필수' for housing and that the cap rule does not apply to housing (§122). It also implicitly excludes land/buildings by pushing cap responsibility to the caller. No sibling is named as an explicit alternative, so this 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.

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 detail beyond them: it returns an error above 20M gross revenue, computes without deduction and sets a flag when other_comprehensive_income is omitted, and apportions mixed registered/unregistered cases by revenue ratio.

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-loaded English summary followed by structured Korean rules; each sentence carries real content. The English sentence partially restates the title, and the bilingual format introduces mild redundancy, but nothing is filler.

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 4-param calculator with no output schema and complete annotation coverage, the description supplies the critical computation rules and error/missing-input behavior. It does not describe the return shape or the tax_reduction parameter, which keeps it just short of fully complete.

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 description coverage, the description must carry the param burden and largely does: it explains registered_revenue/unregistered_revenue apportionment, the role of other_comprehensive_income in gating deductions, and the deduction/expense rates. tax_reduction is left entirely unexplained, so there is one clear gap.

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: computes the 14% separate tax on residential rental income up to 20 million won. It is clear this is the calculation tool, but it never explicitly contrasts itself with the close sibling judge_rental_income_tax (eligibility judgment), leaving the boundary to inference.

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?

Clearly states applicability conditions: deductions apply only when other_comprehensive_income is ≤ 20M, and it returns an error when gross revenue exceeds 20M (out of scope for separate taxation). No alternative tool is named for the eligibility/other-income cases, so it stops short of full when-not/alternatives guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it refuses unvalidated past years, flags future years as current-law estimates, rejects the legally impossible surcharge_rate + long_term_deduction_rate combination, and documents the 2026-08-30 behavior change and the data/tax_params.json source.

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 purpose and the required-year change before the per-argument documentation, and nearly every sentence carries operative detail. The dated changelog block and repeated statutory citations add some verbal bulk that a caller does not strictly need to invoke the tool.

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?

With 11 parameters, no output schema, and 0% schema coverage, the description still covers every argument, the rejection rules, the legal cross-checks (§95②, §104⑦), and the shape of the returned dict (step-by-step so results are verifiable). Nothing needed to call it correctly is missing.

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% (bare titles only), so the description must carry the load and it does: it defines units (원, 0~1, 년), the tax_brackets object shape with 'upto'/None-final-segment, defaults (250만원 basic deduction, 0 default surcharge), and enum-like asset_type semantics including 분양권's 60% floor and 비사업용토지's +10%p.

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?

Opens with a specific verb+resource: Korea capital gains tax on real estate, enumerating the computed components (rate, long-term holding deduction, heavy rates, surtax) and the return ('the statute trail'). This is clearly separable from siblings such as calc_acquisition_tax, calc_gift_tax, and calc_inheritance_tax on the resource axis.

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 when-to-use conditions (asset_type cases, heavy_home_count multipliers, surcharge_rate precedence) and an explicit when-not section enumerating three formulas the function does not support (sub-2-year holding with heavy rates, high-value single-home apportionment, multi-transfer aggregation) plus handled by the caller workarounds.

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

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

The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds domain-specific behavior beyond annotations: statutory exclusions are applied automatically ('불산입 자동 적용'), and the counted number varies by heavy_tier even for the same house. It does not describe return type or performance characteristics, but this is a meaningful addition over structured 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 description is dense and long, but it is front-loaded with the English purpose sentence followed by Korean statutory details. Almost every clause adds substantive domain information required to invoke the tool correctly, though the English summary and Korean opening are slightly redundant. Overall it is appropriately sized for a complex tax-counting tool.

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?

With no output schema, the description indicates that the tool returns a home count and connects it to judge_transfer_reliefs's heavy_home_count field, which is enough to understand the return's purpose. It thoroughly covers the input domain and automatic exclusions, but it does not specify the exact return type or boundary cases (e.g., empty items), leaving a minor gap for a tool of this complexity.

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 must carry the full parameter burden, and it does. It defines the item object fields with meanings, units, and value domains (e.g., 종류 values, 기준시가 basis differences for 입주권 vs 분양권), explains the small-new-house judgment fields, and describes heavy_tier values 2 and 3 with their different counting rules. This richly compensates for the empty schema descriptions.

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 states a specific verb and resource (count homes for heavy capital gains rates) and scopes it by exclusions. It distinguishes itself from the non-taxable home count by explicitly saying '비과세용 주택수와 별개' and links the result to judge_transfer_reliefs's heavy_home_count. An agent can identify this as the heavy-rate home-counting tool without opening other 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 clearly frames the tool's use for heavy capital gains rates and explicitly excludes non-taxable home counting ('비과세용 주택수와 별개'). It also explains how to choose heavy_tier (2 vs 3) based on the applicable statutory series. However, it does not name the alternative tool (e.g., count_transfer_homes) for non-taxable situations, so the alternative routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so safety is covered; the description adds the notable behavioral trait that statutory exclusions are applied automatically. It further discloses the branching logic (다가구 일괄양도, 겸용주택 면적 기준) that determines the computed result, adding real value beyond the 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 English purpose sentence is front-loaded ahead of the dense Korean specification, so the reader gets the point immediately. The subsequent detail is domain-heavy but each block (item schema, 다가구 rule, 겸용주택 rule, sibling exclusion) maps to a real decision the caller must make.

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 single-parameter read-only tool with no output schema, it covers what the input must contain and the pivotal judgment branches, and it points to the output field (겸용주택_전부주택) the caller should inspect. Return-value detail is unnecessary given there is no output schema, leaving it nearly complete.

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 and only a generic untyped array (additionalProperties: true), the description carries the full burden and does so richly, enumerating the item fields (종류 with its domain of value types, 사실상주거용, 취득일 with the 분양권 2021 이후만 산입 rule, the various 특례 booleans, 구획수, 주택연면적/주택외연면적). This is meaning the schema entirely lacks.

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 sentence gives a specific verb (count) and resource (homes) scoped to the one-household-one-home capital gains exemption, and the Korean line explicitly says it applies statutory exclusions automatically. It is clearly delineated from the heavy-tax home count covered by a sibling.

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 the context (1세대1주택 비과세 판정) and explicitly excludes the 중과판정 주택수 (영 §167의3~11) count, which maps to the count_heavy_homes sibling, establishing the 세목·용도별 주택수 분리 원칙. It does not, however, name specific sibling tools or spell out prerequisites for invoking this one.

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

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

With annotations already covering readOnly, idempotent, non-destructive, and closed-world behavior, the description adds substantial context beyond those hints. It warns that all return values are estimates because valuation is determined by appraisal and there are zero judicial precedents in this area, specifies that normal_rise_rate must be fetched externally and not cached, clarifies that this is a levy (부담금) not a tax, and names the primary obligor as the association (조합). This is rich, decision-relevant behavioral information.

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 description is long but densely packed and front-loaded with a clear purpose sentence. The bilingual presentation (English summary followed by Korean legal detail) introduces minor redundancy, but almost every sentence contributes formula, rate bands, exemptions, or critical warnings. It is appropriately sized for the complexity of the domain and avoids fluff.

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?

Given the high complexity (11 parameters, no output schema, a specialized Korean levy), the description is remarkably complete. It supplies the legal basis, the computational formula, current rate bands with a warning against outdated numbers, reduction rules, and a crucial limitation that return values are all estimates. It also notes the levy's nature and obligor. No output schema exists, but the description adequately sets expectations about the returned data's reliability.

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 must carry all parameter meaning. It explains the core formula (excess profit = end price − (start price + normal rise + development cost)), thereby giving meaning to end_price_total, start_price_total, normal_rise_rate, and development_cost. It also decodes member_count via per-capita average profit, ties one_home_holding_years to the 10–70% long-holding reduction schedule, and links age_at_end to the 60+ payment deferral. However, parameters like management_plan_applied_date and the exact role/format of start_date and end_date are left unexplained, leaving a few gaps.

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 states a specific verb ('Estimate') and resource (the reconstruction excess-profit levy, 재건축부담금), and it enumerates the exact components covered: exemptions, base, rate bands, reductions. This distinguishes it from all sibling tools, which are either different tax calculators or judgment helpers. An agent can immediately tell this tool computes the levy.

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 implies usage by describing the levy calculation context and legal basis, but it never explicitly states when to call this tool versus alternatives like judge_reconstruction_membership_transfer or the other calc_* tools. It provides no when-not-to-use guidance or alternative selection criteria. The implied context is sufficient for an agent to infer it should be used to estimate this particular levy, but explicit routing guidance is absent.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses real behavioral traits: it refuses to register scenarios lacking 근거, auto-injects the 세무사법 safety-line text, and forces multi-scenario output for D–F grades rather than a single number. These are enforcement behaviors an agent would not otherwise know. It omits return/pagination details, but the enforcement profile is well covered.

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 opening sentence is front-loaded and clear, but the body is a dense, bilingual block with circled numerals, parenthetical design-doc references, and compressed tier notation that takes effort to parse. Information density is high with little waste, yet readability suffers.

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 terminal formatter with no output schema and an annotations-covered safety profile, the description supplies the enforcement contract, the scenario element shape, and the call order. It still leaves the shape of the produced output and three of five inputs (extra_flags, issue_grade, dividing_issue) undocumented, so an agent lacks full guidance for non-default invocations.

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 description coverage, the description must carry the parameters. It partly does: it details the scenarios element shape ({라벨, 세액, 전제, 근거}) and ties 차액=리드 스코어 tiers to the lead_threshold default (500만). But extra_flags, issue_grade, and dividing_issue are never explained, so the burden is only half met.

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 states a specific role: the standard output formatter for a consultation result and the final pipeline stage that enforces the §11 output protocol. It enumerates concrete formatting rules (no single-number results, forced side-by-side scenarios, auto safety-line text), which makes the purpose concrete. It does not, however, distinguish itself from the sibling format_consultation_report, leaving the agent to infer which formatter applies.

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 gives an explicit ordering: run tree ③→①→②→④ judgments, then calc_* computations, then format each scenario's tax amount with this formatter. That tells the agent when in the workflow to call it. It stops short of stating exclusions or naming the alternative sibling formatter for other cases.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavior beyond that: it enforces a validation rule ('출처 없는 설명은 리포트 전체 거부'), preserves a 'no-assertion' convention via format_consultation_output, and discloses that it auto-derives recommended-search queries returned as '추천검색'. These are concrete traits an agent could not infer from the 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 English opening sentence is a good front-loaded summary, but the Korean block largely restates it while layering multiple parenthetical rules, inflating length without proportional new information. It is readable but not tight.

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 6-parameter, no-output-schema tool with zero schema description coverage, the description conveys the pipeline role, section layout, the source-mapping validation rule, the scenarios condition, and an extra structured return ('추천검색'). The main gaps are the two undocumented params (issue_grade, dividing_issue), but overall it is sufficient to call the tool correctly.

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 must carry parameter meaning; it does so for four of six: conclusion (placed at top), evidences (explanations 1:1 with sources, whole-report rejection), owner_qa (§3 answers with grounds), and scenarios (alternates when the issue splits the tax amount). The remaining issue_grade and dividing_issue are never explained, and the object shapes behind the additionalProperties arrays are undocumented. Partial compensation only.

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 ('Format a consultation result as a report') and enumerates the output sections (conclusion, grounds mapped to sources, tailored Q&A). It also references the sibling format_consultation_output as a reuse dependency, giving partial differentiation. It stops short of fully contrasting with that sibling's role, so it lands at 4 rather than 5.

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 final step of consultation) clearly fixes when the tool is used, and it gives a conditional ('쟁점으로 세액이 갈리면 scenarios를 함께 넘겨') for passing an optional parameter. There is no explicit when-not or alternate-format selection guidance, but the context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the auth requirement (LAW_OC key) and the article-level granularity option, which the annotations do not convey. No mention of rate limits or response shape, keeping it at 4.

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 lead sentence is front-loaded and the Args block is structured, so key facts are easy to find. The Korean restatement duplicates the English meaning, which costs some space for a non-Korean-reading agent, but it is short and not padded.

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 two-parameter read tool with rich annotations and no output schema, the definition supplies what an agent needs: where doc_id comes from, how target must align, and the credential prerequisite. Return-value details are not required given no output schema, so remaining gaps are minor.

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%, so the description carries the burden and it does: doc_id is explained as the serial number from search_law (with the two possible target-specific variants), and target is documented with its two concrete values 'law'/'admrul' even though the schema declares no enum. This materially compensates for the empty schema.

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 (fetch), resource (full text of a Korean statute), scope (by name or MST id, optionally one article), and names the search_law sibling as the source of doc_id. The only wrinkle is the 'by name' claim, which the schema's single string doc_id does not obviously support, but the tool's job 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?

Explicitly ties the call to a prerequisite workflow: doc_id must be the 법령일련번호/행정규칙일련번호 returned by search_law, and target must match the target used there. That is clear routing guidance. No explicit when-not-to-use or alternative for other cases, 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.

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new context: the LAW_OC authentication requirement, real-time lookup with an explicit cache prohibition, and the caveat that if no flexible-rate clause is found the standard rate applies but reduction ordinances still need separate review.

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?

Purpose is front-loaded and the Args/Returns blocks are cleanly delineated. The middle paragraph citing §14 and §111③ is longer than strictly needed for tool selection, though it does justify the cache-prohibition rule, and the English/Korean mixing makes scanning slightly uneven.

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?

With no output schema, the Returns block usefully enumerates the three return fields (ordinances, matched_articles, flexible_rate_found) and explains how to interpret flexible_rate_found. The only gap is error handling for a missing LAW_OC key, which is mentioned as required but not described as a failure mode.

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% and both parameter titles are bare, so the description must carry the load — and it does. It specifies that sido is the full metropolitan-level name ('서울특별시', '경기도'), explicitly rules out 시군구-level values (a real footgun for acquisition tax), and defines keyword's meaning and default ('취득세').

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 ('Look up a Korean city/county tax ordinance') with the exact scope (rate adjustments, local reliefs) and immediately notes the LAW_OC key requirement. It is clearly distinguishable from siblings like get_law_detail and search_law because it targets municipal ordinances (조례) rather than statutes or rulings.

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 timing guidance: '세액 판정 전 관할 조례 확인이 필요하다' (check the jurisdiction ordinance before determining tax amount) and the no-caching rule for frequently amended ordinances. It also routes to the downstream sibling (get_law_detail(target="ordin")), but never states when NOT to use this tool versus search_law/get_law_detail directly.

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

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

Beyond the read-only/idempotent annotations, it discloses a critical trust caveat: values are C등급 기계추출 and must not be cited as confirmed grounds. It also names the returned fields (요지, 감면율, 기한), which matters since there is no output schema.

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-loaded with a one-line English purpose, then workflow and data-quality caveat. Four short sentences, each doing work; nothing redundant, though the bilingual restatement is slightly duplicative.

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 single-parameter lookup with no output schema and no enums, the description supplies the missing pieces: input format examples, returned fields, and a data-trust warning. Only the behavior on a missing/invalid article is unaddressed.

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% for the single 'article' parameter, so the description carries the burden and does so by giving concrete accepted notations ('지특법 §36의5', '조특97의3'). It stops short of stating validation rules or failure behavior for unrecognized formats.

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 precise verb and resource ('look up one relief catalog entry by statute reference') and identifies its role relative to the sibling screen_relief_candidates. An agent can distinguish it from search_law, get_law_detail, and the judge_* tools without opening any schema.

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?

Explicitly states the workflow trigger: use it to re-examine the 원문 요지·감면율·기한 of candidates that screen_relief_candidates produced. It names the sibling it follows but gives no explicit 'when not to use' or what to do if the article is not in the catalog.

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

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.

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavioral value: it discloses that exclusions (rural, inherited homes) are auto-applied, describes the returned '주택수산정' field containing counts and exclusion reasons, and instructs the agent to verify that before the conclusion. The failure-mode warning about the sibling tool further disambiguates behavior.

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-loaded with the sibling distinction, then usage guidance, then args. Every section is load-bearing, though the English and Korean statements of the same sibling relationship are mildly redundant.

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 10-parameter legal-judgment tool with no output schema and zero schema documentation, the description covers the argument conventions, the required flag, enum options, auto-applied exclusions, and even the return payload structure. Nothing essential for correct invocation is missing.

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 parameter burden and does so thoroughly: it documents the items element structure, the mandatory '양도대상' flag, the pre-sale acquisition-date rule with a court citation, and enumerates allowed values for holding_waiver_reason, sale_delay_reason, and partial_move_reason — none of which the schema provides.

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 precise verb+resource ('judges the §156-3 special case by counting homes from a holdings list') and immediately contrasts it with the sibling judge_156_3_special. An agent can tell the difference between the two without opening either schema.

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?

Explicitly directs 'use this tool first in consultations' and explains why the alternative (judge_156_3_special) is riskier: it requires manual other_homes/excluded_homes and silently assumes '1 home + 1 pre-sale right' if omitted. This names both the recommended tool and the failure mode of the alternative.

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

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

Annotations already establish the safe read-only, idempotent, closed-world profile, and the description goes well beyond them: it discloses that pre-2021-01-01 분양권 returns '특례 불필요' (which must not be read as 탈락), that part of the statutory range is unimplemented and surfaced through a '판정범위' field, and it pins three amendment-date pitfalls (2023-01-12 양도분, 2022-02-15 취득분). This is behavioral context an agent could not get from 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?

Front-loaded with purpose, then scope, then judgment order, then the trap list, then args — a sensible hierarchy with no filler sentences. It is nonetheless long, and some trap detail (e.g. the specific 부칙 article numbers) is more implementation nuance than an agent needs to select and invoke the tool.

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 14-parameter, 0%-documented, mutation-free judgment tool with no output schema, the description supplies everything needed: scope, call order, per-parameter vocabularies, edge-case behavior, and a hint at the returned 판정범위 field. Nothing an agent needs to call it correctly is missing.

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% (titles only, no enums declared), so the description carries the full load and does so: it documents every one of the 14 arguments with format (YYYY-MM-DD), semantics (분양권 취득일 = 계약일 아님), and enumerated vocabularies for holding_waiver_reason, sale_delay_reason, and partial_move_reason. It also explains how other_homes/excluded_homes interact with the 1주택+1분양권 premise.

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 verdict verb and resource (주택+분양권 1세대1주택 특례 판정) plus the governing provision (§156의3, 규칙 §75·§75의2). It explicitly differentiates itself from siblings: '입주권은 judge_155_special·§156의2 계열이 맡고, 이 툴은 분양권 전용이다'. An agent can route without opening the schema.

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 scope limits (②③항 only; ④⑤/⑥/⑦⑧ unimplemented and reported via 판정범위), a warning not to reuse the conclusion for 상속·합가·혼인 cases, and an ordered judgment sequence (②항 → 규칙 §75① → ③항). Alternatives and exclusions are named rather than inferred.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: which exemptions are auto-applied, the boundary date 2025-01-02 changing 1억↔2억, that 임대목적 취득 is allowed, and that gift follow a distinct 무상취득 track. It adds real value, though it omits a statement about the output result's shape (no output schema exists).

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 front-loaded in the opening line, and legal citations are compact. However the body is dense and bilingual with largely duplicated English/Korean phrasing, and several sentences carry overlapping legal context that could be trimmed without losing invocation-critical meaning.

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-param, 0%-coverage, annotation-only, no-output-schema legal computation tool, the description conveys the domain logic, auto-applied rules, and the pivotal acquire_date requirement well. Residual gaps are the undocumented prev_disposal/area parameters and any indication of the returned result, keeping it just under fully complete.

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 12 params, so the description must compensate, and it largely does: detailed structure of each `homes` element, the criticality and semantics of acquire_date, gift_std_value's 3억 threshold, and the meaning of disposal_to_same_household, new_home_for_rental, and is_gift. It leaves exclusive_area_m2, prev_disposal_date, prev_disposal_kind, and is_corporation largely unexplained, so the compensation is incomplete but strong.

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: counts homes for acquisition tax and decides the 1/8/12% rate, plus temporary two-home and corporate rules. It implicitly distinguishes itself from sibling judge_temporary_two_homes and from transfer-tax rules by explicitly noting the acquisition two-home relief is separate from transfer tax §155①. It stops short of naming alternatives outright, so not a 5.

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 gives conditions under which internal rules apply (low-price housing thresholds, gift track, corporate rules) and mandates including acquire_date, which is de facto usage guidance. However, it never says when to prefer this tool over calc_acquisition_tax, judge_temporary_two_homes, or count_heavy_homes, leaving alternative routing to inference.

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

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

Beyond the annotations (readOnly, idempotent, closed-world, non-destructive), it discloses a key behavioral trait: history contains only evidence-secured periods and unrecorded periods/regions return '판단불가' rather than a plausible wrong answer. This indeterminate-return behavior is exactly the kind of context annotations cannot convey; only the exact return shape is unspecified.

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 and parameter guidance are front-loaded and mostly earn their place, but the text is dense and mixes languages while carrying internal-only references (트리④ B2, data/adj_regions_history.json, backfill action backlog) that add noise without helping selection.

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 2-parameter tool with no output schema, the description covers purpose, parameter formats, an edge-case date rule, data-coverage limits, the indeterminate return value, and downstream linkage. It is nearly complete; only the precise success return structure is left implicit.

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%, so the description must carry parameter meaning, and it largely does: it gives region format examples ('서울 마포구', '성남시 분당구'), target_date format YYYY-MM-DD, and the edge-case rule that 분양권·입주권 승계취득 uses the use-approval date. This substantially compensates for the empty schema, though region naming conventions are not exhaustively defined.

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 first sentence gives a specific verb and resource: determining whether a region was an adjusted (regulated) area on a given date from designation history. It is precise and unique among siblings (no other judge_* tool covers adjusted-area status), but it does not explicitly differentiate itself from related tools like judge_exemption_requirements beyond naming a downstream link.

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 clearly frames the use case as judging '취득 당시' (at-time-of-acquisition) adjusted-area status and tells the agent to feed acquired_in_adjusted_area into judge_exemption_requirements. It gives clear context but no explicit when-not conditions or alternatives for other scenarios.

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

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

Annotations already establish a safe, read-only, idempotent profile, so the bar is lower. The description adds substantive context beyond them: the sole machine-checkable threshold derives from VAT Act rules and is screening-only rather than determinative, that residential resale counts as dealer activity (correcting a common misconception), and that divergent results emit two scenarios. This is meaningful behavioral guidance not captured by the 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 English sentence is front-loaded and clean, but the Korean block restates the purpose and then layers dense legal caveats, making the whole somewhat heavy with partial bilingual redundancy. Every clause carries information, yet the structure could be tighter for an agent parsing it.

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?

No output schema exists and the safety profile is covered by annotations, so the description focuses on legal basis and output convention, which is helpful for a complex judgment tool. Still, with six params at 0% schema coverage, the description does not fully document the inputs that drive the judgment, leaving a gap an agent must bridge.

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 must carry the burden. It gives semantic grounding to the counting parameters by explaining the 6-month period with 1+ acquisition and 2+ sales, and touches is_residential_resale via the residential-resale rule. But is_self_built_sale, has_business_registration, and business_purpose_advertised are left entirely unexplained 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 precise judgment question with both outcomes named: dealer (business income) vs individual (capital gains). The Korean line reinforces the verb+resource and ties it to a specific decision node (트리⑥, P0 Q0). An agent immediately knows this is a classification/screening tool, distinct from the calc_* tax-computation siblings.

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 labels itself a screening tool (스크리닝 전용, 단정 금지), which implies when it is appropriate, and it prescribes an output convention when results diverge. However, it never names an alternative sibling (e.g., calc_dealer_comparative_tax) or states an explicit when-not-to-use condition. Usage is implied rather than routed.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes beyond that by disclosing the actual decision algorithm and its tie-breaking order (including the deletion of clause 2 in 2008), which is genuine behavioral context an agent cannot get from the annotation block.

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?

Purpose is front-loaded and the subsequent lines build the rule structure logically. The English and Korean openings partially restate each other, and the cross-tax caveat is buried in a warning symbol at the end, but there is little outright filler for a domain this dense.

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, so the description should say what the tool returns — e.g. whether it emits the designated heir, an include/exclude flag, or a tie-break reason — and it does not. The legal logic is thorough, but the caller cannot predict the response shape for a judgment tool.

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% and the single parameter is an opaque array of additionalProperties objects, so the description carries the full burden — and it does: it enumerates the item keys (상속인, 지분율 with 0~1 range, 해당주택_거주 bool, 나이 int) and their types. It omits whether shares must sum to 1 or how ties on age are resolved numerically, keeping it short of a 5.

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 ('Attribute a co-inherited home to one heir') tied to a precise legal basis (Income Tax Decree art. 155(3)), and the Korean line confirms the same scope. It does not explicitly name the adjacent sibling judge_inherited_house_priority, so an agent must infer the boundary, but the statutory citation is a strong differentiator.

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 gives the applicable rule hierarchy (default exclusion → largest inheritor's share → same-house resident → eldest) and the ⚠️ note that conclusions differ by tax type, with 취득세 and 종부세 following other statutes. This effectively tells the agent this tool is for the income-tax question, but it never names the alternative tools (e.g. calc_acquisition_tax, calc_jongbu_tax) or states an explicit 'do not use' condition.

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

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.

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral content: the computation (annual gift benefit = loan × 4.6% − actual interest), the 10M exclusion threshold, the ~217M free-loan equivalent, and the fact that it returns flags tied to the §45 acquisition-funds presumption defense.

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-loaded and compact for a tax-screening tool; the formula and thresholds earn their space. Bilingual redundancy and heavy statutory shorthand make it slightly dense, but nothing is wasted.

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 read-only judge tool with no output schema, the description supplies the rules (rate, threshold), the computation, and the nature of the returned flags, which is enough for correct invocation. Minor gaps remain around input units and how the flag output should be interpreted.

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 must compensate. The formula (대출금 × 4.6% − 실제 이자) implies loan_amount and the interest rate, which partially maps to the two params, but it never states units, format, or the meaning of agreed_interest_rate=0 (i.e., an interest-free loan).

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?

Names a specific verb+resource pair ('Family loan vs gift screening') grounded in a specific statute (Inheritance and Gift Tax Act art. 41-4) with the 4.6% benchmark and 10M won threshold. This is far more specific than the generic calc_gift_tax / judge_gift_tax siblings, though it never explicitly contrasts itself 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?

Usage is implied by the topical specificity (screening family loans against gift-tax re-characterization), but there is no explicit 'use this when X, not calc_gift_tax' guidance and no stated exclusions. An agent infers the context rather than being told it.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description adds real behavioral context beyond them: the post-hoc clawback under §70④⑤ (2-month 추징 plus interest-equivalent) if requirements fall short, and the separate cap requiring a hand-off tool. This discloses consequences of the judgment that no annotation conveys.

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 legal basis, then uses a clean numbered ①-⑤ enumeration of requirements followed by the §69 contrast and cap hand-off. Dense but every section earns its place; slightly heavy but proportionate to a complex multi-criteria judgment.

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?

With no output schema, the description should hint at results; it instead confirms the workflow (hand off to judge_transfer_reduction_limit for final reduction) and enumerates all conditional branches, which is complete enough for correct invocation even though the return shape is not described.

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% across 9 parameters, so the description must carry the burden. It implicitly maps several inputs to legal requirements (4+ years residence, 1-year/2-year expropriation acquisition window, area 2/3 or value 1/2 ratios, combined 8-year farming), but never names or directly documents parameters such as estimate_tax or total_farming_years, leaving mapping inferential.

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 (judge/판정) and resource (farmland substitution exemption, Special Taxation Act §70) with the governing article and decree. It explicitly distinguishes this tool from the sibling judge_farmland_reduction (§69) by noting the residence-period and 8-year-timing differences, so an agent can route without opening either schema.

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?

Provides clear usage context: it lists the five qualification conditions (①-⑤) and states that even at a 100% rate the §133①2호가목 5-period/100M cap applies, directing the agent to judge_transfer_reduction_limit for the final figure. It does not frame explicit when-not-to-use exclusions beyond the §69 contrast, so it stops short of the top mark.

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

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

Annotations already establish that this is a safe, read-only, idempotent judgment. The description adds substantial behavioral context beyond that: the real gate is the income test, high-income periods are excluded from farming years, residence must be within a radius, and converted zones are disqualified after three years.

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 and warning are front-loaded, then supporting legal conditions and routing follow. The English and Korean statements of purpose are somewhat redundant, but the density is justified by the complexity of the tax judgment.

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 seven-parameter legal judgment tool with no output schema, the description supplies the core statutory requirements, data needed for the income test, and the next tool to invoke. It still does not describe the return value or explain every parameter, leaving modest gaps.

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 must carry the burden. It defines yearly_incomes as a list of year/income objects and explains the legal meaning of direct_farming, resides_within_scope, farming_years_claimed, and zone_converted_date. It does not clarify transfer_date or estimated_tax as fully, so it stops short of full coverage.

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 (exemption judgment) and resource (self-cultivated farmland capital gains exemption after 8 years), cites the governing statute, and names the downstream sibling judge_transfer_reduction_limit. An agent can identify the tool's legal target without opening the schema.

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?

Provides a clear next-step routing rule: pass results to judge_transfer_reduction_limit because the 100% reduction is capped by §133①. It also describes key eligibility gates and exclusions, but does not explicitly compare against other sibling judgment tools such as judge_farmland_daeto or judge_exemption_requirements.

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

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

Annotations already cover the safe/read-only/idempotent profile, but the description adds real domain behavior beyond structure: the 2028-12-31 sunset, the two-tier 300만원 vs 200만원 cap split, and the clawback triggers (3개월 상시거주 미개시, 3년 내 매각·증여·임대). It usefully warns that the result can conflict with the widely-known '200만원 단일' view. It stops short of describing what the judgment output looks like.

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?

Purpose and legal citation are front-loaded, and the dense rule/limit/clawback sentences each carry load. The bilingual, heavily parenthetical compression is efficient but borders on terse, and mixing English headers with Korean body text adds mild parsing friction.

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 9-param judgment tool with no output schema, the description is thorough on the substantive rule, deadline, cap tiers, and clawback. The gaps are the absence of any return-value description and no explanation of how co_owners and computed_tax factor into the judgment.

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 9 params, so the description must carry meaning. It supplies thresholds that map to no_home_history (무주택), acquisition_price (12억 이하), is_minor (미성년자 제외), exclusive_area_m2 (60㎡), in_depopulation_area, and acquired_date (2028 기한). However, co_owners, computed_tax, and house_type are never addressed, and no parameter is referenced by name, leaving the mapping to inference.

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 states a specific verb (judge) and resource (first-home acquisition tax relief) anchored to statute '지특법 §36의3', and the eligibility framing (무주택 생애최초, 12억 이하, 거주 목적) clearly distinguishes it from siblings like calc_acquisition_tax and judge_acquisition_homes_and_rate.

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 lays out the substantive eligibility conditions of the relief but never says when an agent should call this versus alternatives such as screen_relief_candidates, judge_exemption_requirements, or calc_acquisition_tax. Usage is implied by context rather than routed explicitly.

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

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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the bar is lower. The description adds real value beyond that: it cites the legal basis (거래신고령 별표 1), the concrete triggering conditions, and notes that output includes guidance on current form (별지 1호의3) items. It still does not describe the shape of the judgment result itself.

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?

Purpose is front-loaded in one clean English sentence, and the supplementary rule detail carries real information rather than filler. The second paragraph is dense with slashes and nested parentheses, which slightly hurts readability but introduces no waste.

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 judgment tool with no output schema, the description covers the intent and the statutory criteria but leaves the parameter semantics and the exact return shape (boolean? structured guidance?) to inference. It is adequate to understand the tool, not fully sufficient to invoke it confidently.

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% across 5 parameters, so the description must compensate. The criteria text indirectly maps onto every parameter (corporation → is_corporation, 6억↑ → actual_price, 규제지역 → in_adjusted_area, 투기과열지구 → in_speculation_zone, 허가구역 → in_permit_zone), but the mapping is only inferable and nothing explains units, defaults, or the boolean flags.

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 first sentence names a specific verb and resource: determining 'whether a home purchase must file a funding plan and supporting documents.' That is clearly distinguishable from the calc_* and other judge_* siblings. It stops short of naming any alternative tool, so it is clear but not explicitly differentiated.

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 Korean parenthetical supplies the triggering criteria (corporation / 600M+ / regulated area / speculation·permit zones), which implicitly frames the tool's scope but is rule substance rather than when-to-use guidance. It never states when to reach for this tool versus another judge_* or calc_* sibling.

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

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

Annotations already cover read-only/idempotent/non-destructive/closed-world, so the bar is lower. Beyond that, the description discloses the full deterministic ranking algorithm including the final tie-break by inheritor choice, and adds a genuine side-effect note that non-priority homes still count toward house count — real behavioral context 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-loaded with a one-sentence English summary before the detailed Korean rules, and every element (ranking rules, input shape, downstream handoff) earns its place. Slight redundancy between the English and Korean statements of the same concept keeps it from a 5.

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?

No output schema exists, but the description explains what the result feeds into (is_first_priority_inherited) and covers the ranking logic and input format an agent needs. A single-param pure-function tool is essentially fully specified; only per-field typing/units for the input elements remain implicit.

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% and the single 'houses' parameter is an untyped object array, so the description must compensate — and it does, enumerating the element keys (라벨, 피상속인_소유기간_년, 피상속인_거주기간_년, 상속개시당시_거주: bool, 기준시가: 원). It meaningfully fills the gap, though it doesn't state units beyond 원 or required-ness per key.

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 first sentence names a specific verb and resource ('pick the single inherited home that gets the special treatment') and the Korean adds the exact legal basis (영 §155② 1~4호). It clearly distinguishes itself from the sibling judge_155_special by naming it as the downstream consumer, so an agent can route correctly without opening the schema.

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 states the triggering condition ('when a decedent held several homes' / '상속주택이 2개 이상이면') and specifies the integration point ('결과를 judge_155_special(kind="상속주택")의 is_first_priority_inherited로 전달한다'). No explicit when-not or alternative-selection guidance, but the multiple-home precondition is a clear context signal.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds genuine behavior beyond them by noting the downstream consequence (12억 deduction and tax-credit entry), that the tax base aggregation is retained, and that a 9/16~30 application flag is included. It does not describe the shape of the verdict returned.

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 purpose sentence is front-loaded and clear, but the Korean block is dense with terse legal shorthand (6억(3억)/지방저가 4억, §8④·영 §4의2) that reads as notes rather than agent-facing guidance. Duplicated bilingual content costs more space than it earns.

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 complex, no-output-schema judgment tool with one required parameter entirely undocumented in the schema, the description covers legal basis and consequences but leaves the caller guessing about the other_homes payload and the verdict format. Adequate but with a clear gap on the core input.

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 must compensate. It does explain base_date well (과세기준일, YYYY-MM-DD, typically June 1) and supplies its default meaning, but other_homes — the sole required parameter — is not described at all, leaving its expected object structure and what counts as a 'home' undefined.

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 states a specific verb and resource: judging whether an owner is deemed a one-household-one-home holder, and enumerates the four types (attached land, temporary, inherited, cheap provincial home). This distinguishes it reasonably from siblings like judge_temporary_two_homes or judge_same_household, though it never explicitly names which sibling covers the overlapping sub-cases.

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 implies usage through legal context (statutory citations and the note that a positive finding is the entry point to the 12억 deduction and tax credit), but it does not state when to call this versus judge_temporary_two_homes, judge_same_household, or judge_inherited_house_priority. Guidance is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description goes well beyond that by disclosing the legal logic: the prohibition triggers (재건축 after 조합설립인가, 재개발 after 관리처분인가), the exceptions (gift included, inheritance/divorce excluded), the consequence for the buyer (§39③→§73 loss-compensation route), and the fact that transfer_notice_done=True voids the restriction. This is rich domain behavior an agent could not infer from 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 question is front-loaded and every clause maps to a rule or parameter, so there is little outright waste. However the body is a dense run-on block mixing Korean and English with stacked legal citations, lacking clear delineation between the rule, the exceptions, and the per-parameter guidance, which hurts scanability.

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 complex, 11-parameter legal judgment with no output schema and no annotation-level detail, the description supplies the core decision rules, exceptions, timing effects and parameter routing needed to invoke it. It does not describe the shape of the returned judgment, which is the main remaining gap given the absence of an output schema.

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 carries the full burden and does substantial work: it explains the role of in_speculation_overheated_zone, transfer_notice_done, is_one_plus_one_small (§76①7호라목 3-year resale ban), and enumerates the allowed transferor_reason values including the 시행령예외 case that drives decree_reason (§37③). Parameters such as owned_years, resided_years, association_established, management_disposal_approved and is_partial_share_transfer are only implied, so coverage is partial rather than complete.

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 judgment task — whether a reconstruction/redevelopment association membership can be transferred in a speculation zone, citing Urban Renewal Act art. 39. This is a concrete verb+resource that separates it from the calc_* and other judge_* siblings. The mixed Korean/English phrasing and legal-citation density add some friction but the purpose remains identifiable.

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?

Explicitly frames the tool as a 'salability pre-filter that comes before tax calculation' (세액 계산보다 앞선 매도가능성 선필터), which tells the agent when to call it relative to the tax siblings. It also routes the agent to search_law(admrul, '투기과열지구 지정') to verify the zone at transaction time. No explicit when-not conditions are given, so it stops 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.

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

Annotations already declare the safe read-only/idempotent profile, so the bar is lower, and the description adds genuinely useful behavior: total income over 20M KRW is honestly returned as '판단불가' because 추계경비 is an NTS-notice area. It also discloses that answers hinge on tax_year due to a 2026-01-01 statutory effective date and an annually revised deposit interest-rate constant.

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 topic is front-loaded, but the body is a dense bilingual block mixing an English fragment with untranslated Korean legal shorthand, which hurts parseability. Every clause carries domain content, but the structure could be far more scannable for an agent.

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, no-output-schema, high-complexity judgment tool, the description covers the decision flow and nested-object shapes well but leaves most scalar inputs unexplained and only partially sketches the return shape (beyond the '판단불가' case). It is adequate but has clear gaps.

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% for 12 parameters, so the description must compensate and it partly does: it documents the element keys for own_homes/spouse_homes (라벨, 기준시가, 전용면적, 공동소유, 지분율, 최대지분자, 연임대수입, 전대, 국외) and deposits (라벨, 보증금, 일수, 기준시가, 전용면적), and justifies tax_year being required. It does not explain the eight scalar params (tax_reduction, financial_income, business_registered, monthly_rent_revenue, deposit_interest_rate, registered_rent_revenue, other_comprehensive_income, revenue_before_registration).

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 ('Residential rental income tax: taxable, home count, deemed rent, separate vs global taxation') and the Korean tree label (주택임대 종합소득세 판정) makes clear this is a judgment tool. It is distinguishable from the sibling calc_rental_income_tax by framing itself as a 판정/decision-tree rather than a calculation, though it never explicitly names that sibling.

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 lays out the internal decision sequence (비과세 → 주택수 → 총수입금액 → 2천만원 분기 → 분리과세), which implies when each branch applies. However it never states when to prefer this tool over alternatives like calc_rental_income_tax or judge_small_house_rental_reduction, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantial non-obvious behavior beyond that: the definition varies per tax kind, de facto marriage is expressly excluded in acquisition tax, under-30 unmarried children need 12-month income above 40% median, and the care-merge exception age differs (65 vs 60). This is real decision context, though it omits anything about the shape of the verdict returned.

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 front-loaded, and the tax_kind warning plus the per-tax bullet structure make it scannable despite being dense. It is somewhat verbose and mixes legal citations with operational guidance, but no sentence is clearly wasteful.

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?

Given 12 parameters, a single required field, no output schema, and the complexity of a tax-law household test, the description supplies the essential per-tax rules and exceptions. It is close to complete for the inputs, with the main gap being that it never states what the judgment returns.

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 12 parameters, so the description must compensate and does so only partially. It clarifies relationship values, tax_kind, is_de_facto_marriage, merged_for_parent_care, descendant_age, and legally_divorced_but_living_together, but leaves age, is_minor, lives_together, is_married_or_was, and shares_livelihood 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?

The description opens with a specific verb+resource: 'Decide whether two people form one household (1세대) for income, acquisition or holding tax purposes.' It scopes the tool precisely (household-identity determination) and cites the governing legal bases, which lets an agent distinguish it from status-oriented siblings like judge_jongbu_one_home_status or judge_155_special.

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 gives explicit conditional guidance: tax_kind must be matched, and it details how the household definition diverges between 양도세 (same address + shared livelihood) and 취득세 (resident-registration table). It does not, however, name sibling tools as alternatives for adjacent determinations, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: sunset windows (e.g. §98의9 to 2026-12-31), the requirement that the special home be acquired after the general home, and the separate 9/16~9/30 filing for the one-home deemed status. It does not describe the response shape, which holds it below 5.

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 front-loaded, but the body is a dense bilingual wall of statutory citations that mixes Korean and English and is hard to scan. Most sentences carry real content, yet the structure is not clean enough to count as efficient.

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 13-parameter judgment tool with no output schema and no schema descriptions, the description is fairly complete: it lays out the legal framework per kind, the price/date/area thresholds, and the acquisition-order precondition. It does not explain the returned judgment or failure behavior, leaving a small 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 coverage is 0%, so the description must carry the load, and it does: it gives the kind enum values verbatim (which the schema omits), and names exclusive_area_m2, acquisition_price, first_contract, seller_is_supplier as the determiners of 준공후미분양, plus thresholds tied to published_price, is_hanok, holding_years, in_capital_area, same_sigungu, same_or_adjacent_area, and acquired_after_general_home. Mapping is embedded in prose rather than per-parameter, so not a full 5.

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 determination (homes excluded from the home count) and enumerates the four qualifying kinds (농어촌주택, 고향주택, 인구감소지역주택, 준공후미분양주택), so an agent knows what this tool judges. It does not explicitly route away from siblings like count_transfer_homes or judge_temporary_two_homes, but the resource is clear.

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?

Usage is implied through the statutory conditions attached to each kind rather than stated directly; there is no explicit 'use this when / not when' sentence and no named alternative among the many sibling judge_/count_ tools. The conditions do let an agent infer applicability, which is why this lands at minimum-viable rather than lower.

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

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

Annotations only carry the safety profile (readOnly, idempotent, non-destructive, closed-world), while the description adds real behavioral substance: the differential reduction rates (30%/75% for 1 house, 20%/50% for 2+), the statutory eligibility conditions, the 2028-12-31 sunset, and the clawback rule (reduction + interest-equivalent add-back if the rental period falls short of 4/10 years). This is context an agent cannot get from the structured fields.

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 purpose is front-loaded, followed by statutory anchors, rates, requirements, sunset, a notable carve-out, and clawback — every line carries information, no filler. The bilingual duplication is defensible because the Korean statute terms are the operative references, though it makes the block denser than strictly 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?

For a 10-parameter, output-schema-less statutory judgment tool, the description covers eligibility, rate structure, temporal validity, and consequences well. It still leaves the return shape (boolean vs. rate vs. amount) and a couple of parameter units/functions unstated, which matters more here because there is no output schema to fall back on.

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 10 parameters, so the description must carry the meaning — and it largely does, mapping requirements onto params: business registration (§168), minteukbeop registration (§5), 85㎡ cap (exclusive_area_m2), ₩600M standard price (published_price_at_start), 5% rent-increase cap (rent_increase_rate), 1 vs 2+ houses (rental_house_count), long-term-general flag, and the sunset (tax_year). Gaps remain: income_tax_before_reduction is never explained, rental_months is only implied via the 4/10-year clawback, and the unit convention for rent_increase_rate (percent vs decimal) is ambiguous.

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 verb+resource (judge eligibility and rate of the small-home landlord income tax reduction) and pins it to Special Taxation Act art. 96, so an agent can tell it apart from the generic calc_rental_income_tax / judge_rental_income_tax siblings. It also states its role explicitly as the tax_reduction branch (⑤) of calc_rental_income_tax.

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 says when the tool applies (the §96 registration, 85㎡, ₩600M standard-price, 5% rent-increase conditions) and draws a genuinely useful boundary against 소법 §64의2 separation taxation — cases where the 60% expense deduction / ₩4M credit applies but the §96 reduction does not. It does not, however, explicitly route the agent between this tool and judge_rental_income_tax or calc_rental_income_tax as separate callable alternatives.

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

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.

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive), and the description goes well beyond them: it discloses the two non-offsetting cap baskets with exact amounts, the 2025-03-14 §133② change and that older 1억/2억 citations are wrong for expropriation, and that down/up contracts or unregistered transfers cause full exclusion under §129. This is exactly the domain behavior an agent could not infer from structured fields.

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 lead line front-loads the purpose, which is good, but the body is dense bilingual prose with parentheticals, a numbered gate arrow chain, and inline JSON. Most content earns its place, yet the mixed-language, run-on framing 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 complex, high-stakes tax judgment tool with no output schema and 0% schema coverage, the description supplies substantial domain context (caps, baskets, exclusions, statutory basis). The remaining gap is coverage of the prior-4-year carry-in parameters, but overall an agent has enough to call it correctly.

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 must carry parameter meaning. It documents the reductions element shape (조문/감면세액/라벨) and ties unregistered_transfer and contract_price_mismatch to full-exclusion behavior, which is genuine added value. It says nothing about tax_year, prior_4year_reductions, or prior_4year_taking_reductions despite these being central to the five-year cap logic.

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: it judges whether transfer-tax reliefs survive the §129 exclusion, §133 aggregate caps, and §127⑦ choose-one gates. It also flags its own role ('전액 비과세 안내를 막는 것'), which is more specific than a bare restatement. It does not, however, explicitly say how it differs from siblings like judge_transfer_reliefs or screen_relief_candidates.

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 gating flow (§129 → §133 → §127⑦) implies when the tool applies, and the disclaimer about 'full exemption' guidance hints at its role. But there is no explicit when-to-use vs when-not, and no named alternative among the many judge_* siblings that also deal with transfer reliefs.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial context: date-dependent surcharge rates (2021-06-01 split), the limited-window exclusion rule, the 4-month (or 6-month) contract-date carve-out, and the 2-year holding prerequisite. It also documents return fields (surcharge_rate, long_term_deduction_rate, 과세대상_양도차익_비율), which matters since no output schema exists.

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?

Content is front-loaded with the purpose before the legal detail, which is good, but the opening English and Korean sentences restate the same purpose verbatim, and the body is dense with statute citations. Duplication and volume dilute an otherwise well-ordered description.

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 an 11-parameter tool with no output schema and no schema descriptions, the description covers the temporal rules and return values well but omits behavior for several parameters (adjusted_at_sale, sale_price, residing_years). An agent can call it correctly on the date path but not fully on the others.

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 params, so the description must carry the load and only partially does: it explains sale_date (mandatory), contract_date, deposit_received, contract_months_limit, holding_years implicitly, and the exemption/home-count inputs. Parameters such as adjusted_at_sale, sale_price, and residing_years are never given meaning, leaving real gaps.

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 (decide) and named resources (exemptions, heavy-rate exclusions, long-term deduction, high-value apportionment) and defines its role as a 판정 레이어 that converts household/home-count output into rates and deductions. This boundary statement distinguishes it from siblings like calc_transfer_tax (which consumes its output) and the count/judge prerequisite tools.

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?

Explicitly states that household/home count and exemption-requirement satisfaction are received as inputs rather than computed here, implying the correct call order relative to count_heavy_homes / judge_exemption_requirements. It also mandates sale_date, but does not name alternative sibling tools to prefer in edge cases.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the critical behavioral caveat: this is a C-grade machine-extracted index, not authoritative, and omissions cause silent client harm (over-payment), so every hit must be re-verified. This reliability/quality disclosure is exactly what annotations cannot convey.

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-loaded English one-liner followed by detailed Korean guidance; each part earns its place. However, the bilingual rendering conveys the same purpose twice, adding length and some parsing friction for an agent, so it is slightly redundant rather than maximally tight.

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?

With no output schema, no required params, and a complex domain, the description still supplies purpose, usage timing, reliability caveats, and full parameter semantics. An agent has everything needed to invoke it correctly and interpret its output cautiously.

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 does so for all 7 parameters: tax_types (comma-separated 사목), situation (free text; living language expanded to legal terms), assets, and the three boolean includes with their concrete conditions, plus limit. It adds meaning well beyond the bare schema titles.

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 (list), resource (tax reliefs and special cases), and scope (worth checking for a given situation, to avoid omissions). It explicitly differentiates itself from the judge_*/calc_* siblings by noting those produce conclusions with A-grade law nodes while this is a C-grade index that only points to where to look.

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?

Explicitly says '판정이 아니다' (this is not a determination), directs the agent to judge_*/calc_* for conclusions, and prescribes exactly when to run it (before finishing a consultation to catch missed reliefs) and how to treat results (re-verify hits with original text and judgment tools). Clear when-to-use plus the alternative tools, no inference needed.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open world), so the bar is lower. The description adds genuinely useful context beyond them: it discloses the LAW_OC key requirement (an auth precondition) and describes the specific result fields to harvest, which is not in the annotations. It omits rate-limit and pagination behavior.

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-loaded with the purpose and a well-organized Args block plus workflow note. It loses a partial point for the English/Korean duplication, where the second sentence restates the first verbatim rather than adding information.

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?

With no output schema, the description compensates by naming the key result identifiers and explaining how they feed get_law_detail, which is exactly what an agent needs for chaining. Nothing critical is missing for a three-parameter search tool.

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 must carry the full burden, and it largely does: it documents all three parameters, expanding target's enum values (law/admrul/ordin) with concrete meanings and noting display's maximum of 100. Only query and display remain fairly thin, but the target coverage is the substantive gap-filler.

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 (검색/search), the exact resource (Korean statutes, administrative rules, and ordinances), and names the database (law.go.kr). It also implicitly distinguishes itself from get_law_detail, the full-text sibling, by positioning this as the search step of a two-step workflow.

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 clear context for when to use it and explicitly routes downstream work to get_law_detail by telling the agent which result field to pass as doc_id. The target parameter's three modes are explained with real examples, though there is no explicit 'when not to use' or alternative search tool callout.

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

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

Far exceeds the annotations (readOnly/idempotent/openWorld). It discloses backend-specific search semantics (조세심판원 AND vs 국세청·행안부 OR), that the tool silently auto-quotes whitespace queries for 국세청·행안부, and that detailed results are links into the taxlaw system rather than full text. That automatic query rewriting is exactly the kind of behavior an agent must know before invoking.

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?

Purpose is front-loaded, but the body is a dense run-on mixing English and Korean, internal jargon ('판정 쟁점플래그'), record counts (17,534건), measurement dates, and a copyright-law aside about 저작권법 §7 that does nothing to help an agent call the tool. The critical AND/OR warning is buried mid-paragraph behind an emoji.

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?

No output schema exists, so the description should characterize returns; it only says results are link-only into 국세법령정보시스템, without describing result fields or pagination. Combined with the undocumented 'display' parameter, this is adequate but leaves an agent guessing about the response shape.

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 must compensate. It does so well for 'source' (four named corpora with counts and subject matter) and 'query' (semantics differ per source, auto-quoting), but 'display' — the result-count parameter — is never mentioned anywhere. Partial compensation only.

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 (search Korean tax rulings / tribunal decisions) and enumerates the four distinct corpora by name and ID (ntsCgmExpc, ttSpecialDecc, moisCgmExpc, expc), which distinguishes it from siblings like search_law and get_law_detail. An agent can tell immediately what domain this covers without opening the schema.

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 usage context ('판정 쟁점플래그의 D·E급 근거 탐색용') and an end-to-end workflow (전언 → 안건번호·회신일 대조 → D급 확정), and routes body retrieval elsewhere ('검증용 본문 수집은 scripts/fetch_rulings.py 담당'). However, it never names a sibling tool as a when-to-use alternative (e.g., search_law for statutes) or states when not to use this tool.

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