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). The description adds real value by disclosing the legal basis (국세기본법 제26조의2) and the rule matrix that determines each outcome, going 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?

Front-loaded purpose followed by labeled 언제/입력/결과 sections makes it easy to scan. It is dense and the trailing rules table is somewhat redundant with the '결과' summary, but each element carries useful 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 carries the return burden and does so, specifying 제첨기간·기산일·만료일 and the legal basis. Everything needed to call it correctly 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?

Schema coverage is 100%, so parameter definitions are already complete, but the description adds meaning by mapping each param to its role (due_date, case, offshore, inheritance_gift) and tying them to the resulting limitation periods.

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: computing the national tax assessment statute of limitations and its expiration date. It is clearly distinct from the many sibling tax calculators because it targets limitation periods rather than income/VAT/penalty computation.

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 '언제' line states the trigger clearly — reverse-calculate the assessment/limitation deadline for tax of any taxable period. No explicit alternatives or exclusions are named, but the use context is unambiguous among siblings.

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 read-only, idempotent, non-destructive, closed-world calculation. The description adds value beyond that by enumerating the computed outputs (손금산입 한도, 충당금 설정금액, 상계액, 처분 익금, 소득금액 순영향, 근거), which matters because there is no output schema. It does not discuss edge cases or failure modes, but for a pure calculator the gap is small.

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 first clause, then organized under labeled sections (언제 / 입력 / 결과), which makes it scannable. It is dense but every line carries information; only the closing restatement of 일시상각충당금·압축기장충당금 is mildly redundant with the opening sentence.

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-parameter calculation tool with no output schema, the description supplies the missing return-value picture and the input mapping, which is enough to call it correctly. The optional inputs (planned_use, receipt_year, expired_unused, claim_by_return, lost_book_value) are left to the schema, which is acceptable at 100% coverage.

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 100%, so the schema already documents every parameter including the nested assets item shape. The description only maps inputs to fields (사업연도→year, 재원 구분→kind, 수령액→received, 자산별 내역→assets) and omits the five optional parameters entirely, adding little beyond the structured data. Baseline 3 is appropriate.

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 resource (국고보조금·공사부담금·보험차익 일시상각충당금·압축기장충당금) and a specific action (세무조정 계산), so the domain is unmistakable. It does not explicitly name a sibling to contrast with (e.g. depreciation_adjustment, which is closely related), which keeps it just short of 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?

The '언제:' block gives a clear triggering condition: a corporation that acquired/improved business assets using subsidies, construction contributions, or insurance proceeds, and needs 손금산입/충당금 상계/처분 calculations. It offers no explicit exclusions or named alternatives, so an agent gets clear context but no routing rules.

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 profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add computation context — and it does, enumerating the result sections (판단/계산/결과/세무조정). With no output schema, this return-shape disclosure is genuinely valuable; it stops short of explaining edge-case behavior or how the 판단 근거 are derived.

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 and statute, then cleanly sectioned into 언제/입력/결과. The 입력 block largely duplicates the schema field-by-field, which is somewhat redundant, but each line maps a Korean concept to its parameter name and remains skimmable.

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 8-parameter, nested-object computation tool with no output schema, the description supplies what structured fields cannot: the statutory basis, the invocation trigger, and the shape of the returned judgment/calculation/result blocks. Only the derivation logic and error/precondition handling are left unstated.

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 100%, so the schema already documents all 8 parameters. The description mostly restates the same parameter→name mapping, though it does add a small amount of meaning (the default 3-digit truncation rule for 대손실적률, the writeoffs item shape). Baseline 3 is correct when the schema does the heavy lifting.

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 resource pair (대손금·대손충당금) and action (세무조정), and anchors it with the governing statutes (법인세법 제19조의2·제34조). An agent can tell what it computes. It does not, however, distinguish itself from the sibling tool 'bad_debt_allowance', which appears to overlap on the allowance half.

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 언제 line gives a concrete trigger: corporate tax adjustment where bad-debt recognition AND allowance limit/excess are computed together. The word '함께' implicitly signals the differentiator from an allowance-only tool, but no alternative or exclusion is named 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?

With readOnlyHint/idempotentHint already covering the safety profile, the description adds real behavioral value: it discloses the formula being applied and what the tool returns (한도·한도초과 and the statutory 근거). It stops short of full transparency since it does not describe output format or edge-case handling, but it carries useful extra context.

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 언제/입력/결과 structure is front-loaded and each block earns its place; the formula leads. It is dense with terminology but 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 stateless calculation tool with rich annotations and 100% param coverage, the description is complete: it explains purpose, inputs, and outputs despite there being no output schema. Minor gap in not covering return structure or edge cases.

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 already 100%, so the baseline is 3. The description maps each parameter to its Korean meaning and reinforces the loss_rate decimal convention (0.02 = 2%), but adds little beyond what the schema already documents.

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 precise computation verb+resource, going as far as giving the formula (채권잔액 × max(1%, 대손실적률)) and naming the legal basis (법인세법 제34조). It is highly specific, though it does not explicitly differentiate itself from siblings like bad_debt_adjustment or vat_bad_debt_credit.

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 '언제' clause gives a clear when-to-use condition: calculating the deductible limit when setting a bad debt allowance on receivables. There is no when-not guidance and no alternative tools named, 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?

Beyond the readOnly/idempotent annotations, the description discloses material behaviour: the 지수표 applies the 2026 고시 table and years 2007–2025 are approximations flagged in the result, the sub-1,000원/㎡ truncation rule, and the 상증세-only adjustment layer. It does not cover failure modes or input validation, so a 4 rather than 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 언제/입력/결과 labelling makes it scannable and every block earns its place. However, the long formula sentence leads the description ahead of the plain 'what it is' statement, so the tool's core purpose is not front-loaded optimally.

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 13 parameters, no output schema, and a domain-specific computation, the description supplies the formula, the year/approximation caveat, the conditional parameter set, and the returned fields (기준시가·지수·잔가율·조정률·판단). Nothing an agent needs in order to invoke 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 already 100%, so the baseline is 3; the description earns above that by mapping business inputs to fields (적용연도 → year, 면적 → area_m2, 구조·용도 → structure·use) and grouping which parameters only matter when purpose='상증세' (층수·연면적·지붕·층별·안전등급). It does not add syntax guidance beyond the schema, so not 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 description states a specific resource (건물 기준시가) and the exact statutory formula and legal basis (소득세법 제99조①1호나목, 상증법 제61조①2호), so an agent knows precisely what is computed. It also names the sibling tools that cover the excluded property types (official_property_price for 주택, 국세청 고시가격 for 오피스텔), separating it from neighbours.

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 '언제' block gives concrete scenarios (비상장주식 평가, 상속·증여 신고, 양도세 환산취득가액) and explicitly routes excluded cases to alternatives: 주택·아파트 → official_property_price, 오피스텔·일괄고시 상업용 → 국세청 고시가격. It also ties to the sibling unlisted_stock_valuation.

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 is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description adds real behavioral substance beyond that: the statutory basis and the fallback ordering (감정평가가액 → 기준시가 → 장부가액) that governs the allocation logic.

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?

Uses labeled sections (언제/입력/결과), is front-loaded with purpose and statute, and every line carries information with no padding.

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 compensates by naming the returned components (건물_공급가액·토지_가액·부가가치세, 산식, 근거). Combined with the trigger condition and statutory reference, an agent has everything needed to call this 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 100% and each field already carries a description (including the {building, land} structure), so the schema does the heavy lifting and baseline is 3. The description's input mapping largely restates the schema, adding only the natural-language gloss '일괄 거래가액(원)' for total_price.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (안분/allocation) and resource (토지·건물 일괄공급) and anchors it to statute (부가법 제29조⑨, 영 제64조①). This is immediately distinguishable from the VAT siblings like vat_common_input_allocation or simplified_vat_return.

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 '언제' line gives an explicit trigger condition: land and building supplied together with unclear value separation, plus the appraisal→standard value→book value priority order. It lacks named alternatives or exclusions, so it falls just short of 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 establish readOnly, idempotent, non-destructive behavior, so the description is not burdened with safety disclosure. It adds useful behavioral context by naming the legal basis and summarizing the result components, including business-use ratio, disallowance, and depreciation limit.

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 front-loaded with the core tax concept, then organized into when/input/result sections. It is appropriately sized for a 10-parameter tax calculation, though the input mapping largely duplicates schema content.

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 tax calculation with no output schema, the description explains the result components and legal basis, and covers most inputs. The omission of acquisition_cost from the input mapping is a minor completeness gap, but the schema still documents it.

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 100%, so all parameters are already documented in the schema. The description maps most inputs to their tax concepts but omits acquisition_cost and adds little syntax or format detail beyond the schema, making the baseline 3 appropriate.

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 identifies a specific tax computation: non-deductible treatment of business passenger-car expenses, including business-use ratio, personal use, deemed ratio, and the annual depreciation cap. It is clear enough to distinguish from generic corporate tax or depreciation_adjustment tools, though it does not explicitly name sibling alternatives.

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 states when to use the tool: when calculating the deductible extent of car expenses used by executives or employees. It gives clear context but does not specify when not to use it or name alternative tools.

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 layers on substantive behavior: automatic 환산취득가액 when acquisition_price=0 and both 기준시가 are present, automatic 부담부증여 양도/취득가액 derivation with the 3%/0.3% 개산공제, date-driven 판정 of 한시 배제, and rejection when residence_start/end conflict with residence_years. It also discloses the return shape (판단·결과·산식·근거), which is valuable given 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?

It is front-loaded with the formula chain and organized under 언제/입력/지원하지 않음/결과, which helps. However, it is extremely dense and long, and the '입력' section largely duplicates parameter descriptions that already have 100% schema coverage, so several sentences do not earn their place.

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 27-parameter statutory calculator with no output schema, the description covers the computation chain, required vs. optional inputs, mutual exclusions, auto-derivations, error cases, and the structure of the returned 판단/결과/산식/근거. An agent has everything needed to decide and call 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the field descriptions: it explains parameter interactions (burdened_gift is mutually exclusive with transfer_price/acquisition_price), the multi-home surcharge rate schedule that gives houses_count/adjusted_area their purpose, and that 한시 배제 is decided by the tool from dates rather than the user. Much of the '입력' block does restate schema text, which keeps it below 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 states a precise computational chain (양도차익 → 1세대1주택 비과세·고가주택 안분 → 장기보유특별공제 → 양도소득금액) with the governing statutes, which is far more specific than the name alone. It never names the sibling capital_gains_tax, even though the apply_basic_deduction option pushes this tool into 산출세액 territory that sibling presumably owns, leaving a real boundary ambiguity.

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 '언제' line gives an explicit trigger, and the '지원하지 않음(error)' block lists concrete exclusions (분양권·조합원입주권·주식, 2018.4.1. 이전 지정지역 3주택 가산, 주택 수 계산, 고가주택 일부 양도). It also pre-empts a common false-positive ('토지는 one_house=False, exempt_met=False 입력해도 오류 아님'). What's missing is routing to alternatives — no mention of capital_gains_tax for the full tax computation.

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, but the description goes far beyond: it discloses the full rate schedule, the larger-of comparison rule, multi-home surcharge periods, which exemptions are date-determined by the tool versus user-asserted (exclusion_reason), and what the return contains. It also states hard limits, so the agent knows where the tool's judgment ends.

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?

Well front-loaded: the first line gives the input→output contract, then labeled blocks (언제/입력/세율/지원하지 않음/결과) make the density navigable. It is long and citation-heavy, but the length is justified by the statutory complexity rather than padding.

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 still specifies the return contents (산출세액, 지방소득세 10%, 적용 세율, 세율 후보, 근거). Combined with the rate rules, exclusion mechanics, and stated non-support, an agent has everything needed to decide applicability 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 coverage is 100%, so baseline is 3; the description adds real value by grouping inputs semantically (과세표준→base, 자산 종류→asset_type, 등기→registered, 지정지역→designated_area) and by clarifying the date-based versus user-claim split for exemption handling. It does not explain heavy_multi_home or exclusion_basis, which live only in the schema, so it falls 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?

Opens with a precise mapping: '양도소득 과세표준 → 산출세액·지방소득세(소득세법 제104조①·④·⑦)', naming the verb (apply rates), the input (tax base), and the outputs. It explicitly differentiates itself from the closest sibling by telling the agent to use capital_gains_income when starting from the sale price instead.

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?

'언제' clause states the precondition (tax base already given or computed separately) and names the alternative tool plus the exact parameter to use there. The '지원하지 않음' section adds explicit out-of-scope cases (pre-2018.4.1 designated-area 3+ homes, house-count determination, pre-sale rights/partnership units/stocks), which is rare and valuable 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 establish readOnly/idempotent/non-destructive, but the description adds substantial behavior: year-banded rates, age-threshold changes across years, a 부칙 exception for 2017-born children, and an explicit halt condition ('입력 확인 필요로 멈춤'). It also pre-empts a question the agent should not ask (아동수당).

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?

Well front-loaded with purpose, then 언제/입력/결과/연도별/지원 안 함 sections that each carry load. Dense for a first read, and the ① ② ③ rate notation takes parsing, but virtually no sentence is filler given the rule complexity.

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 multi-year tax computation with no output schema, the description covers the return contents (합계, 인원별 금액, 추가공제, 자녀별 판단·산식·근거), all year bands, and the unsupported territory. An agent has everything needed to call it correctly and to know when it will stop.

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 100%, but the description still adds meaning beyond it: settlement_date is only required for 손자녀 in pre-2023 귀속 stacked with post-2024 settlement, order is required for 출산·입양 children from 2017, and school_enrolled applies only to 2019-year-age-6 children. These conditional requirements are not obvious from the schema alone.

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 the specific tax credit (자녀세액공제), cites the statute (소득세법 제59조의2), and states the operation (귀속연도별 계산) and supported period (2016~2026). This distinguishes it from sibling credit tools like dividend_tax_credit and special_tax_credit without needing to open 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?

An explicit '언제' block names the scenario (종합소득세 신고·연말정산) and the required inputs, while a '지원 안 함' block lists out-of-scope years, 산출세액 초과분/적용순서, and pre-2022 손자녀 edge cases. Both when-to-use and when-not-to-use are stated.

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=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context about the calculation process, ledger handling, prior-period inputs, and the result structure (판단·계산·결과·산식·근거), which goes beyond the annotations. It does not contradict them.

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 but well structured with purpose, timing, inputs, and results. It front-loads the key legal and operational context, though the input section partially repeats schema details and could be tighter.

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 10-parameter tool with nested objects and no output schema, the description covers the purpose, usage context, required inputs, ledger semantics, prior-period dependencies, and expected result fields. An agent has enough context to invoke 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 100%, so the baseline is 3. The description adds cross-parameter meaning, especially for ledger usage and the relationship between prior_common_input_tax, prior_nondeductible, and final return processing, which is valuable beyond the 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 gives a specific verb and resource: it computes common input tax allocation/settlement and additional output tax for common-use goods under VAT Act Article 40 and related decree provisions. It is clear and detailed, but it does not explicitly distinguish itself from the sibling tool vat_common_input_allocation, so it falls short of 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?

The '언제' section clearly states when to use the tool: for composite taxable/exempt businesses calculating common input tax deduction and additional output tax in preliminary/final VAT returns. It does not explicitly state when not to use it or name an alternative sibling, so it is not 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?

The description goes far beyond the structured data by defining the calculation's legal basis (citing Articles) and detailing the expected outcome, which includes the full breakdown of judgments, inclusion amounts, and legal grounds. This adds critical context beyond the static 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 detailed and somewhat verbose, but its structure is logical (Legal basis -> Timing -> Inputs -> Results). Every complex piece of information is front-loaded or immediately explained, making the thoroughness worthwhile.

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 and 100% schema coverage, the description is exceptionally complete. It covers the functional definition, the input requirements, the expected output structure, and the governing law.

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?

Although the schema coverage is 100%, the description provides vital semantic context, such as clarifying that 'rate' can accept percentages or decimals, defining the currency (Won) for various financial inputs, and explaining the complex structure of the 'rentals' array.

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 tool's purpose is stated explicitly as calculating corporate deemed rental income, referencing specific legal acts (Tax Special Cases Act, Article 138). It clearly defines the functional boundaries of the calculation.

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 tool specifies the exact context for usage: when a corporation receives a deposit for real estate rental business. While it defines the 'when' well, it does not compare its specific calculation function against other related tax tools like `corporate_tax`.

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 behavior, so the safety profile is covered. The description adds value on top: it discloses the deterministic rate-table formula, the short-fiscal-year proration behavior, and the exact result fields with legal citation. It stops short of edge-case behavior (e.g., out-of-range years), hence not a 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?

Front-loaded with the core computation before the when/input/result blocks, so an agent gets the essence in the first clause. The Korean-English duplication and the input mapping partially restate the schema, which is minor redundancy rather than bloat.

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 enumerating the return fields (산출세액, 과세표준, 사업연도, 월수, statutory basis). Combined with the stated trigger, inputs, and formula, an agent has enough to call it correctly; only boundary/error behavior is left unstated.

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 100%, so baseline is 3. The description goes slightly further by mapping each parameter to its business meaning (과세표준 in won, fiscal year, month count) and explaining that 'months' drives the 월할 환산 proration for fiscal years under one year — semantics the schema alone only hints at.

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 — computing corporate income tax (산출세액) — and even gives the computation rule (과세표준 × 세율표, prorated for short fiscal years) plus the statutory basis. This clearly separates it from siblings like income_tax, minimum_tax, or withholding_tax without needing to open a 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?

The '언제' clause names a concrete trigger: when the tax base has been determined during corporate tax filing or tax adjustment. No alternative tool or when-not condition is given, but the trigger context is unambiguous for a single-purpose calculator.

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, idempotent, read-only, closed-world computation. The description goes further by disclosing the actual computation logic (formula, the 150,000 KRW deduction, and the sub-1,000 KRW exemption) and the legal basis returned, which is real behavioral context 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?

Front-loads the formula, then proceeds through when/input/result in an ordered, scannable structure. The trailing English gloss is mildly redundant but each section otherwise earns its place.

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 carries the return burden well, naming the result (원천징수세액) and its legal basis, and specifying inputs, range, and computation rule. 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 description coverage is 100%, so both parameters (daily_wage, year) are already documented, including the year range. The description only restates the same term-to-parameter mappings and range, adding no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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 (계산한다 / calculates 일용근로자 원천징수세액) and even embeds the exact formula, pinning the tool to daily-worker withholding. This scope is clearly distinguishable from siblings like withholding_tax, wage_income_tax, and nonresident_withholding.

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 '언제' (when) clause gives a clear trigger: paying a daily wage to a daily worker. It does not name alternative tools or state exclusions, but the scoping makes the applicable scenario 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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value beyond them: the return is the additional withholding tax amount, it is derived from specific statutory bases (법인세법 제67조, 소득세법 시행령 제192조, 소득세법 제137조), and one input is explicitly optional. It does not, however, discuss precision/rounding or any failure modes.

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, then the 언제/입력/결과 blocks are labeled and scannable. The input block mildly duplicates the schema, but the overall package is compact and nothing reads as 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?

With no output schema, the description carries the return-value burden and does so by naming the output (추가 원천징수세액) and its legal grounds. It also flags the required/optional split, so an agent has enough to call it correctly, though it omits units/rounding conventions and any dependency on the other tax figures being pre-computed.

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 100%, so all six parameters are already documented in the schema, including the '모르면 생략' note on prev_decided. The description's '입력:' mapping restates the same Korean label-to-field pairs, so it adds little beyond the schema; the 3 baseline applies.

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 phrase '소득처분 상여 연말정산 재정산(추가 원천징수세액)' names a specific verb (재정산/recompute) and resource (deemed-bonus year-end settlement), and the English gloss confirms it. It is clearly separable from sibling deemed_* tools (deemed_interest, deemed_dividend_bonus_shares) and from wage_income_tax because it targets the income-disposition bonus case specifically.

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 explicit '언제:' clause gives the trigger condition - a deemed bonus arising from a corporate-tax income adjustment. That is a clear when-to-use statement, but it never names an alternative tool or an exclusion (e.g., how it differs from wage_income_tax or deemed_dividend_bonus_shares), 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 read-only, idempotent, non-destructive behavior, and the description adds meaningful operational detail beyond that. It discloses that an unrecognized source returns 'error' without calculation, lists result fields, and explains taxability by source and the proportional allocation rule for partial revaluation reserves.

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 front-loaded with purpose and structured into 'when', 'input', 'result', and error/special-rule sections. Although long, the length is justified by the complexity of the tax calculation and there is no apparent 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?

Given a seven-parameter tax calculation with no output schema, the description covers when to use it, each input's domain meaning, result fields, error behavior, and a critical partial-capitalization allocation rule. Nothing essential for correct invocation appears to be 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 100%, so the baseline is 3, but the description adds tax-treatment meaning for source categories and legal-basis differences for shareholder_type. It also clarifies self_stock handling and lists the source vocabulary with taxable/non-taxable distinctions.

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: calculating per-shareholder deemed dividend when surplus is transferred to capital for a bonus issue. It is clear what the tool computes, but it does not explicitly name or distinguish sibling tools such as deemed_dividend_capital_reduction.

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 '언제' section gives a clear triggering condition: when a corporation capitalizes surplus and issues bonus shares, calculate each shareholder's deemed dividend. It does not state when not to use the tool or name alternatives, so it falls short of full when/when-not 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 readOnlyHint/idempotentHint=true and destructiveHint=false, so the safe-pure-computation profile is covered. The description adds real context beyond that: the exact arithmetic formula, the error contract ('사실이 빠지거나 맞지 않으면 error와 필요 입력을 돌려주고 계산하지 않음'), and the short-term cancellation rule (2-year window, 개인 excludes 주식발행초과금 전입분). It does not restate what annotations provide.

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 formula, then structured 입력:/결과: sections. It is long, but every line carries operational content (field semantics, defaults, output fields, error behavior) rather than filler. The formula-first ordering makes the purpose immediately legible.

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 carries the return burden and does so: it enumerates the result fields (의제배당금액, 단기소각주식수, 평균단가, 소멸주식 취득가액, 소각 후 1주당 장부가액, 산식, 근거) and the error shape. All 8 parameters are accounted for, so nothing needed to invoke or interpret the tool 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 100%, so the baseline is 3, but the description adds semantic rules the schema does not spell out: how to populate acquisitions by kind (유상취득→unit_cost, 무상주_과세→액면가액, 무상주_비과세→0, 처분→보유 감소) and the cancelled_shares omission default. That is genuine added meaning over the enum/description text.

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 computation ('의제배당 = 받은 금전·재산가액 − 소멸 주식 취득가액') with the exact triggering events (감자·주식소각·퇴사·탈퇴·해산), and explicitly names the sibling deemed_dividend_bonus_shares as the prior step for 무상주 과세 판단. An agent can distinguish this from other deemed-income tools without opening a 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?

The '언제:' clause gives an explicit trigger ('유상감자·주식소각·퇴사·탈퇴·해산으로 주주가 대가를 받았을 때'), and it routes the agent to deemed_dividend_bonus_shares first for 무상주 과세 판단, even stating what to pass (kind). This is a clear when-to-use plus a named 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 declare readOnly/idempotent/non-destructive, so safety is covered. The description adds value beyond them by disclosing the computational method, the composed output set (적수·시가이자·수령이자·차액·익금산입액·부당행위 여부), and the governing statute (법인세법 제52조, 시행령 제88조③·제89조③) — genuinely new context.

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 cleanly sectioned into 목적/언제/입력/결과, so an agent can scan it quickly. The 입력 paragraph is nonetheless redundant with a fully-documented schema, slightly diluting information density.

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 description compensates by enumerating the returned fields, so an agent knows what it will receive. Inputs, trigger condition, and legal basis are all covered; only edge-case behavior (e.g. missing received_interest, empty movements) is left unstated.

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 100%, so the schema already documents all six parameters including defaults and anyOf-null behavior. The '입력' block largely re-maps Korean labels to the same parameter names and repeats the schema text, adding little semantic meaning beyond it.

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 computation with its formula ('적수 × 시가 이자율') plus the secondary judgment (부당행위계산 여부), which is far more than a restated name. However it never names or distinguishes the closely-related siblings (unfair_transaction, nonbusiness_interest_disallowance, thin_capitalization), leaving the agent to infer the boundary.

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 '언제' block gives an explicit triggering condition: use when you need both the related-party 가지급금 interest and the 3억·5% unfair-transaction test together. That is clear context for selection, but no when-NOT-to-use or alternative tool is named.

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 safety is covered. The description adds genuine behavioral context beyond them: it states that incomplete or inconsistent facts return an error with the missing inputs instead of computing, and it discloses the 12-month fiscal-year-only constraint and the 2016–2026 year range.

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 언제/입력/결과 structure is well organized and front-loads purpose before inputs. The 입력 list, however, restates parameter meanings that are already fully documented in a 100%-coverage schema, adding some redundancy for a 19-parameter 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?

There is no output schema, and the description compensates by enumerating the return contents (세무조정·상각범위액·회사계상액·기말 상각부인누계액·세무상 미상각잔액·판단·근거) plus the error path. For a complex 19-parameter statutory calculation, purpose, timing, inputs, outputs, and failure behavior are all covered.

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 100%, so the per-parameter descriptions already carry the baseline burden. The description still adds cross-parameter logic not obvious from the schema: method='무신고' requires asset_class, useful_life or rate is required, prior_disallowed is negative for 감가상각의제 △유보, and the 즉시상각의제 thresholds (600만원, 300만원 pre-2019, 5% book value, sub-3-year periodic repair) that tie several inputs together.

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 tax computation (법인세 감가상각 시부인), the exact comparison it performs (개별 자산별 상각범위액 vs 회사계상액), and the governing statutes. This clearly distinguishes it from sibling adjustment tools such as bad_debt_adjustment or entertainment_adjustment, which target entirely different tax adjustments.

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 '언제' block gives explicit conditions for use: 감가상각비 세무조정 (상각부인액·시인부족액·전기 부인액 추인·감면법인 의제상각) and 세무상 미상각잔액 산출. It provides clear context but names no exclusion conditions or alternative tools, which is a minor gap given the sibling list contains no directly competing depreciation tool.

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 safety is covered; the description goes further by spelling out the computation rule for 공제대상 법인세 and two exclusion rules ('법인세법' credits are not deducted, '기타' penalties are excluded). That is genuine behavioral substance an agent cannot get from the schema. It does not discuss input validation failures or edge cases, so not a 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 언제/입력/결과 sectioning is front-loaded and scannable, and the formula line is dense but earns its place by defining the core computed quantity. It is tightly written with no filler, though the compressed multi-line 입력 block takes effort to parse.

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 ten parameters, no output schema, and no enums, the description carries real burden and meets it: it covers the trigger condition, all input groupings, the enumerated return fields (자산상실비율, 공제대상 법인세, 판정, 계산과정, 근거), the governing formula, and the two exclusion rules. An agent has what it needs to call this correctly without opening the 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 coverage is 100%, so the schema already documents all ten parameters thoroughly, which sets the baseline at 3. The 입력 section adds a useful business-concept-to-parameter mapping (사업연도→year, 당기 법인세→current_tax, 미납 법인세→unpaid_prior_tax) and signals the either/or shapes (assets vs assets_before/assets_lost, other_credits vs credit_items), which is marginal added value rather than new semantics.

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 the exact Korean tax-credit name (법인 재해손실세액공제) and the 언제 line states the action: computing the corporate tax credit for a company that lost assets in a disaster. This is specific enough to distinguish it from generic siblings like corporate_tax or special_tax_credit, though it never names an alternative tool to avoid.

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 언제 section explicitly states the triggering condition (재해로 자산을 상실한 법인의 법인세 세액공제를 계산할 때), which is clear usage context. It gives no when-not cases or named alternative tools, 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 readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuine behavioral context by describing the output shape ('결과: 익금불산입액의 피출자법인별 내역·세무조정·근거'), which is valuable given there is no output schema. It does not cover pagination or auth, but for a pure calculation this is largely sufficient.

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 front-loaded with the core purpose and then structured into 언제/입력/결과 blocks, which is easy to scan. It is compact for a 9-parameter tax tool, with no wasted 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 complex 9-parameter tax-adjustment tool with no output schema, the description covers purpose, trigger, key input mapping, and the result structure. The only gap is a lack of disambiguation from the numerous sibling tax tools, but otherwise an agent has enough to invoke 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 100%, so the schema already documents all parameters including the enum for company_type and boolean election flag. The description maps some inputs to parameter names (year, investees, interest_paid, interest_excluded, total_assets_jeoksu) but adds no semantics beyond the schema, so baseline 3 applies.

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+resource: computing the income-exclusion for domestic-corporation dividends received, with per-investee exclusion rate, interest-paid deduction, and tax adjustment. This distinguishes it from broad aggregators like financial_income_aggregate, but it does not explicitly name or differentiate from close siblings such as deemed_dividend_bonus_shares or deemed_dividend_capital_reduction.

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 trigger with '언제: 법인세 세무조정에서 수입배당금 익금을 부인할 때', which is clear context for use. However, there are no when-not conditions and no routing to alternatives among the many dividend-related siblings, so usage remains implied rather than fully guided.

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 read-only, idempotent, closed-world calculation, so the description focuses on computation behavior: year-dependent gross-up rates (11% through 2023, 10% from 2024), the non-business interest rate shift from 14% to 25% in 2017, and a precise list of unsupported scenarios that cause an input-check halt. That is exactly the kind of context annotations cannot 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?

The four-part structure (언제/입력/결과/연도) is well front-loaded and scannable. It is dense, and the inline formulas in the 결과 section are long, but they carry genuine information for a tool with no output schema.

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 the description compensates fully by enumerating each returned figure (일반산출세액, 비교산출세액, 종합소득 산출세액, 배당세액공제 한도, 배당세액공제액, 공제 후 세액) with its formula. Year bounds, rate transitions, and out-of-scope cases are all covered.

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 100%, so the parameter definitions already stand on their own; the description adds the interaction rules — that supplying 'items' means leaving grossup/financial_14/financial_25/partner_dividend empty, and that other_base and taxable_base are mutually exclusive alternatives. It stops short of restating every field, which is appropriate given the 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?

The description names the specific computation (배당세액공제와 금융소득 종합과세 비교산출세액) and cites the governing articles (소득세법 제56조·제62조·제15조2호), so an agent knows exactly which tax calculation this performs. It is clearly distinguishable from siblings such as financial_income_aggregate (which supplies inputs) and dividend_received_deduction.

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?

An explicit '언제' section states the triggering condition (금융소득 > 2천만원, comprehensive taxation) and names the outputs to obtain. A dedicated '지원하지 않음' section lists the cases where the tool must stop and ask for input, which is unusually clear 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?

With no annotations present, the description carries the full burden. It discloses the determination rule (Amid: among medium-sized enterprises, the highest direct holder, or for a corporate holder the highest individual by direct+indirect ownership) and the result shape (dominant shareholder name + reasoning), which is substantive behavioral context. It does not state side-effect/reversibility behavior, but this is a computation, not a mutation.

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 언제/입력/결과 labeling is well front-loaded and scannable. However the trailing fragment '수혜법인의 지배주주를 판정한다Amid(...)' reads as corrupted or duplicated text that repeats the purpose and muddles the close, costing clarity.

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-required-parameter tool with nested objects and no output schema, the description covers the trigger, every input's mapping, and the return content (name and reasoning), which is enough to invoke it correctly. Minor gaps remain around edge-case behavior but nothing critical 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 100%, so the baseline is 3, and the description builds on it by mapping each argument in '입력' and noting that stakes uses the same format as related_judge — a cross-tool hint the schema does not contain. It adds meaningful orientation rather than restating field types.

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 (수혜법인의 지배주주 판정) and anchors it with a legal citation (상증법 시행령 제34조의3①). It also distinguishes itself from siblings by pointing to related_judge as the reference for the shared input format, so an agent can place it precisely in the tunneling 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?

The '언제' block gives an explicit trigger condition: use when determining the dominant shareholder of the beneficiary corporation inside the 일감몰아주기 deemed-gift computation. That is a clear context, but no when-not guidance or explicit alternative (e.g. when to prefer related_judge or kinship_check instead) is offered.

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/no-open-world, so the safety profile is covered. The description adds substantive domain behavior beyond that: the applied rates (특례 50%, 일반 10%), the carryforward handling, and the year range. It does not contradict any annotation.

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 cleanly organized into 언제/입력/결과 blocks. The parameter list is somewhat long but each mapping earns its place given the generic schema labels; no filler sentences.

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 carries the return-value burden and does state the results (한도·한도초과·이월 손금산입) plus the legal citation. Inputs are fully mapped. Minor gap: no note on output units or the interaction between carried_loss and the limits.

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 100%, so baseline is 3, but the schema's own descriptions are mostly generic ('금액(원)'). The description supplies the real semantics for each name (base_income=과세표준 계산 전 소득금액, special=특례기부금 지출액, carried_loss=결손금, etc.), adding genuine meaning over the 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?

The description names a specific verb+resource (기부금 손금산입 한도 = donation deduction limit) and enumerates the exact outputs (한도·한도초과·이월 손금산입). It also anchors the tool to a legal basis (법인세법 제24조), which clearly separates it from sibling limit tools like entertainment_limit and loss_carryforward_limit.

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?

An explicit '언제' clause states when to use it: 'compute the limit and excess when deducting donations.' This is clear contextual guidance, but no when-not conditions or named alternatives (e.g. when to prefer loss_carryforward_limit) are given.

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/ openWorldHint=false, so safety needs no disclosure; the description adds valuable context that results are itemized with grounds and reasons and that excluded items (different year, different income type) are surfaced. With annotations covering safety, this context is useful but not rich: it does not state what happens when facts are incomplete (that is in the items schema), whether year limits are enforced, or any error 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?

The description is long but organized into purpose, when-to-use, input, and output blocks, with the key computation and citations front-loaded. The item-rule list, especially the year-by-year childcare limits, is dense; it earns most of its length but would read better as structured tables than as inline prose.

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 supplies the return shape (per-item taxable/non-taxable amounts, grounds, reasons; excluded items; gross pay; non-taxable total; deduction; earned income), the input contract, and the legal basis for a complex multi-kind computation. Nothing an agent needs to make a correct call 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?

The schema has 100% description coverage and only 2 top-level params, but the nested items array is typed as an empty object, so the description carries the real burden of explaining kind values, required facts per kind, per-year non-taxable limits, and fallback computations such as deriving monthly regular wage. It adds major meaning over the schema; keeping it from 5 is that the rule block is dense and leaves some kinds' fact requirements 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?

The description gives a specific verb+resource: it judges taxable/non-taxable status per earned-income item, verifies the attribution year, and computes gross pay, the earned-income deduction, and earned income, citing specific statutory articles. It does not name any sibling tool as an alternative or contrast (e.g., wage_income_tax, other_income_aggregate), so the 5 criterion of sibling differentiation is only met implicitly through a narrow payroll-specific scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The '언제' line explicitly says when to use it: when obtaining gross pay and earned income from salary, bonus, allowance, and benefit data in year-end settlement or comprehensive income tax filing. This is clear use context, but there is no explicit when-not guidance and no named alternative tool to route away from.

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 goes beyond them by naming the produced artifacts (판단·결과·세무조정·소득처분·계산·세액공제), which substitutes for the absent output schema. It also discloses the substantive rule mapping for each 성격 and 증빙 value, though it does not state defaults for omitted optional fields beyond those the schema already lists.

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 labeled '언제'/'입력'/'결과' structure that makes scanning easy. It is long and partly repeats the schema's ledger enum listing, which is the only real 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?

Six parameters, three required, no output schema, and a dense domain; the description compensates by documenting the result structure and the classification logic, and it notes that revenue is based on 기업회계기준 매출액 (영 제42조①). An agent has enough to call it correctly without further context.

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 100%, so a 3 would be the floor, but the description adds real meaning: it explains what each 증빙 value implies for the tax outcome (손금불산입, 기타사외유출, 한도 시부인) and gives the 포함/제외 rule for every 성격 value with the governing article. That is interpretation an agent could not derive from the raw enum list.

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: computes the corporate business-entertainment expense (기업업무추진비) tax adjustment item by item, with the legal basis and the naming history from 접대비. It is clear on its own, but never distinguishes itself from the sibling entertainment_limit, which plausibly also computes a 한도, so an agent cannot route between them from the text alone.

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 a clear triggering context, and the claim that 접대비-related book problems also go through this tool narrows the scope. It stops short of naming alternatives such as entertainment_limit or missing_receipt_disallowance, so there is no explicit when-not 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 this read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by stating the output contents (한도·한도초과액·근거) and the legal basis, which the annotations do not provide.

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 언제/입력/결과 structure front-loads purpose and scans well. It is slightly redundant, restating the purpose in the final sentence after the structured block already conveyed it, but nothing is incomprehensible.

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 carries the burden of describing the return value, and it does (한도, 한도초과액, 근거). Inputs are all mapped, so an agent can call the tool correctly; only the sibling-disambiguation and the year-vs-period rule interaction remain thin.

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 100%, so baseline is 3, but the description adds genuine semantic meaning: it clarifies that general_revenue is corporate-book revenue including discontinued operations, that related_revenue is revenue from related parties, that market applies from 2023, and that culture is 문화비 (the schema only says '금액(원)'). This compensates for the terse schema texts on culture/expensed.

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 computation (기업업무추진비 한도와 한도초과액) plus the tax context (법인세 세무조정, 손금불산입액) and cites the governing statute. It is unambiguous what the tool returns, though it never differentiates itself from the very similarly named sibling entertainment_adjustment.

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 '언제' clause gives a clear triggering condition (when computing the non-deductible entertainment expense in a corporate tax adjustment) and the closing line repeats the check-'over-limit' use case. There are no exclusions and no reference to alternatives, and the presence of entertainment_adjustment as a sibling makes that omission a real ambiguity.

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 declare the read-only/idempotent safety profile; the description goes well beyond with version-dependent behavior — the 2019 year rule for the simple expense-rate revenue test, the 2018 inclusion of asset-disposal gains for double-entry taxpayers, and the multiplier schedule change on 2020.3.13. It also flags that 2019 requires an explicit multiplier rather than a default, which is a real invocation hazard.

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?

Sectioning (언제/입력/연도/배율/결과) is front-loaded and easy to scan, but the 입력 block largely duplicates the already-complete schema descriptions, and the 연도 paragraph is dense. A meaningful fraction of the text does not add information beyond the structured fields.

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 9 parameters, no output schema, and year-sensitive rules, this tool needs return-value disclosure — and the 결과 section enumerates the income amount, the calculation components (수입금액, 장부구분, 적용방법, 주요경비, 한도), the judgment reasons, and cited provisions. Nothing material to a correct call 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 already 100%, so 3 is the floor; the description adds value by mapping each Korean input label to its argument name (귀속연도→year, 업종군→industry_group, etc.) and by restating the multiplier default logic in a narrative form. It stops short of adding constraints the schema 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?

Names a specific computation (추계 사업소득금액) and anchors it to the statutory provisions (소득령 제143조, 제208조⑤), which no sibling tool covers. An agent can identify this as the estimated-income computation for taxpayers without adequate books, distinct from other_income_aggregate or pension_income.

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 '언제' clause states the trigger condition precisely: when a business owner lacks books or they are insufficient, compute business income by estimation. No sibling alternative or when-not-to-use case is named, so it falls short of a full routing statement.

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 description says the tool creates and saves an .xlsx file, including 'output_dir — 저장할 폴더' and '결과.파일 — 절대경로', which is a filesystem write side effect. The annotations declare readOnlyHint=true, so the description contradicts the annotation's read-only claim; this is an annotation contradiction.

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 appropriately structured for a complex export tool: purpose first, then when to use it, inputs, results, and basis. The sections are front-loaded and each part maps to a real need, especially since there is no output schema.

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?

The description is complete for a complex export tool with no output schema: it explains re-execution behavior, tab expansion, all parameters, error conditions, file naming, and the exact result fields returned. Nothing an agent needs in order 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?

Although schema coverage is already 100%, the description adds meaningful semantics beyond the schema: calls must be 1-30, tool names cannot be missing or 'export_workbook' because recursion is forbidden, output_dir must exist, filename characters are sanitized, and layout choices are explained. These are operational constraints an agent needs in order to call the tool correctly.

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: it exports calculation-tool results into an Excel .xlsx workbook. It also explains the distinctive mechanism, namely that each call is re-executed server-side and expanded into tabs, which clearly separates it from the sibling calculation 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?

The '언제' section gives a clear usage context: when the practitioner needs calculation results such as tax adjustments, income dispositions, judgments, and formulas saved as an Excel file for review. It also states a key exclusion, no recursive export_workbook calls, but it does not explicitly compare itself with sibling tools or say when not to export.

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 no annotations, the description carries the burden and does well: it discloses that results are a draft (초안) marked as AI-generated, that human verification is required before related_judge, and it explains the dual execution path — local pypdf extraction by default vs. UPSTAGE_API_KEY enabling Document Parse + Solar Pro 4 for higher fidelity. It does not state failure modes or limits on malformed/complex PDFs, which keeps it short of a 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 labeled structure (언제 / 입력 / 결과) is helpful and front-loaded, but the closing sentence restates the opening purpose verbatim, and '오 officers' contains a typo. The duplication costs real space in an otherwise tight definition.

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 description compensates by naming the returned sections (people/family/stakes/officers), the draft status, and the AI-generated marker. Combined with the stated dependency on UPSTAGE_API_KEY and the human-review requirement, an agent has what it needs to call this 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?

One parameter with 100% schema description coverage, so the schema already documents pdf_path. The description restates 'PDF 파일 경로 → pdf_path' without adding format, path-style, or constraint details beyond the 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 (추출한다) and resource (관계표: people/family/stakes/officers) plus the source document types (주주명부·가족관계·임원명단 PDF). This clearly separates it from related_judge and kinship_check, which operate on already-structured input rather than raw PDFs.

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 '언제' clause names concrete triggering scenarios (세무조사, 의료법인 친족확인) and the exact situation (when a relationship table exists in a PDF and must be converted to tool input). It also names the downstream handoff to related_judge and states a human must verify before that step, which is explicit sequencing 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 readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so safety is covered. The description adds substantive behavioral context by explaining the calculation scope, item classification rules, and that results include judgments, amounts, and intermediate calculations.

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 well structured with explicit '언제', '입력', and '결과' sections and a bulleted kind vocabulary. Some of the kind list overlaps with schema content, but the added definitions justify most of the length.

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 calculation tool with no output schema, the description covers the required inputs, the full kind vocabulary, special fields, and the shape of the returned result at a high level. Given the rich annotations and full schema coverage, this is complete enough for an agent to invoke and interpret the 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?

Although schema coverage is 100%, the description adds real semantic meaning beyond the schema by defining each allowed kind, including tax treatment such as Gross-up eligibility, comprehensive taxation treatment, and exclusion from the financial income total. It also maps year and items to their business meaning.

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: it aggregates comprehensive income financial income (interest and dividends) and performs Gross-up calculations under cited tax law articles. It is distinguishable from generic income-tax tools because it explicitly scopes the operation to financial income aggregation and dividend gross-up.

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 '언제' section: use when determining whether financial income is subject to comprehensive taxation in a comprehensive income tax return and when calculating dividend gross-up. It does not name alternative sibling tools or when-not conditions, so it is strong but not complete 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, so the safety profile is covered; the description adds what annotations can't, namely the shape of the return (candidate list with name, one-line description, when-to-use, and match reason) and the no-result behavior. It doesn't discuss ranking or qualities of matches beyond '일치 이유', a minor gap for a search tool.

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 purpose sentence, then clearly labeled 언제/입력/결과 blocks, so an agent can scan it in one pass. Minor redundancy with the schema (e.g. restating that n is a count) keeps it just below top marks.

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 fully carries the return-value burden: it describes the candidate list fields and the empty-result branch with a concrete next step. Nothing an agent needs in order to call this correctly or interpret its output 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 100%, so the schema already documents all three parameters, including the keyword alias for korean-tax-mcp find_article compatibility. The description only adds that query may be phrased in everyday language and can be a 세목/쟁점/조문, which is a modest value-add above the baseline.

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 ('맞는 계산 도구 찾기') and immediately scopes it against the 70+ sibling tools, which makes clear this is the discovery/router tool rather than a calculation tool. It also names a distinct fallback path (korean-tax-mcp for 조문) so an agent can tell it apart from every sibling at a glance.

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 '언제' section states explicit trigger conditions: when the right tool name doesn't come to mind, and mandatorily before concluding 'this calculation tool doesn't exist.' It also gives the post-condition branch (no candidates → look up 조문 in korean-tax-mcp), leaving nothing 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?

With annotations already covering readOnly/idempotent/non-destructive, the description adds meaningful behavioral context beyond them: year-dependent rules (이월기간·손금산입방법 허용 여부가 연도별), the fact that 손금산입 only applies through 2020, changing ownership thresholds (25% → 10% in 2023, 5% for 자원개발), and explicit limitations of what the tool does NOT compute.

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 organized into 입력/결과/주의 blocks, which aids scanning. It is on the long side and partially restates the country-object fields already present in the schema, but the redundancy is limited and most lines carry unique constraints.

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 description compensates by enumerating the return contents (간접외국납부세액, Gross-up 익금산입액, 국가별 한도·공제액·이월액, 산출세액, 이월공제기간, 산식, 근거) along with the known model limitations. 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 100%, so baseline is 3, but the description goes further by clarifying non-obvious semantics: foreign_income is pre-Gross-up and pre-withholding, direct_tax excludes subsidiary withholding tax, holding_months is measured at 배당기준일, and participation_exempt applies from 2023 under 제18조의4.

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 its scope enumerated (직접·간주·간접, 국가별 한도, 한도초과 이월). It is clearly distinguishable from siblings like corporate_tax, dividend_received_deduction, and special_tax_credit.

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 '언제' clause gives explicit trigger conditions (국외원천소득에 외국 법인세를 낸 내국법인이 공제액·Gross-up·이월액을 구할 때). It also declares out-of-scope items (손자회사, 이월액 공제, 이월결손금 안분 미반영), but does not name an alternative tool for those 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 the operation read-only, idempotent, non-destructive and closed-world, so the safety bar is low. The description goes beyond them by disclosing the complete set of computed line items (과세가액 through 신고세액공제 and 납부할세액) plus '근거', which tells the agent this is a deterministic, audit-trailed calculation rather than a data lookup.

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 입력/결과/when layout is front-loaded and scannable, with each line carrying operational content. The only waste is the closing sentence '증여세 과세가액·공제·세액 계산', which restates the opening line without 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?

There is no output schema, and the description partially compensates by listing the result fields, which is the right move. But for an 18-parameter tax engine with 11 undocumented-in-description inputs, an agent lacks guidance on when to set flags like generation_skip/recipient_minor or how credits (other_credits, prior_gift_tax_paid) interact with the computed 세액 — a meaningful gap for a high-parameter 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 100%, so the baseline is 3, and the description's 한글→parameter mapping (증여일→gift_date, 부담부증여 인수채무→assumed_debt, etc.) is genuinely useful for natural-language translation. However it maps only 7 of 18 parameters and is silent on the ones most likely to be mis-specified — generation_skip, recipient_minor, share_appraisal_fee/count, excluded, nontaxable, other_credits.

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 enumerates the exact outputs (과세가액·공제·과세표준·산출세액·납부할세액), making it immediately distinguishable from siblings like inheritance_tax or inheritance_gift_valuation. The final line restates the scope compactly as gift-tax computation, so an agent knows precisely what domain this covers.

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 a use context but no exclusions and names no alternatives, even though the sibling list contains adjacent tools (inheritance_tax, inheritance_gift_valuation, tunnelling_gift) that an agent could plausibly confuse. The boundary between 'compute the tax' and 'value the gifted asset' is implied by the result list rather than stated.

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 read-only/idempotent/non-destructive, so safety is covered; the description adds real behavioral context beyond that: the computation formula, the deduction ordering ('적수가 큰 주택부터 차감'), the floor at zero, whether financial income is subtracted under estimation, and what the result contains (과세 여부·주택 수·적수·근거). It does not mention error conditions or rounding/output precision, which keeps it just short of top.

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?

Dense but well sectioned (언제 / 입력 / 판정 / 산식 / 결과) with the purpose front-loaded. The '입력' block largely duplicates the schema and could be trimmed without losing 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?

No output schema exists, and the '결과' line enumerates what is returned (taxability, house count with exclusion reasons, includable gross income, per-house 적수, legal basis). Combined with the threshold tables and formula, an agent has everything needed to call and interpret the result.

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 100%, so the schema already documents each parameter including the rate default table and the houses item shape. The '입력' section restates those mappings almost verbatim, adding little new semantics; baseline 3 is appropriate. It does reinforce that non-rented houses must still be listed, but the schema says the same.

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 the governing statute ('주택 임대 보증금 간주임대료 … 소득세법 제25조①, 시행령 제53조③④'), and explicitly disambiguates from the two nearest siblings (vat_deemed_rent for VAT, corporate_deemed_rent_income for corporations). An agent can identify the tool 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?

The '언제' section gives the triggering condition (individual leasing housing for jeonse/deposit, computing comprehensive income tax business income) and names both alternatives with the axis that separates them (VAT vs. individual vs. corporate). It also states the year-by-year eligibility rules up front, so the agent knows when the tool applies.

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 safe, deterministic, closed-world computation, so the marginal bar is met by the description disclosing what it will refuse to compute and that it stops rather than guessing, plus the year-by-year rule switches (9억/12억 기준, 2018 vs. 2019 treatment) and the output fields produced. The listed legal bases and the '입력 확인 필요로 멈춤' behavior are traits the schema and annotations do not 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?

It is long and dense, but section labels (언제 / 입력 / 판정 / 분리과세 산식 / 지원하지 않음 / 결과) keep it scannable and the purpose is front-loaded. Some of the separate-taxation formula detail duplicates what the tool computes internally, which costs a point on strict economy.

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, but the '결과' line enumerates the returned fields (과세 여부·구분·주택 수·총수입금액·분리과세 세액·종합과세 참고 세액·의무임대기간·근거), closing that gap. Combined with the supported-year bounds, the unsupported-case list, and annotations covering safety, an agent has everything needed to call this 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 100% and every parameter, including the nested houses array, is already documented in the schema. The '입력' section mostly restates those fields (year, houses, other_income_amount, rate) without adding format or syntax detail beyond the schema. Baseline 3 applies since the schema does the heavy lifting.

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 and resource: personal housing rental income taxation determination (과세 판정), and enumerates the exact decisions computed — 1-housing exemption, 20M threshold, separate vs. comprehensive taxation. It also names the sibling it is not ('간주임대료만 필요하면 housing_deemed_rent_income'), so the agent can discriminate without opening a 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?

The '언제' section states the triggering situation (individual renting a house by monthly rent/jeonse, needing taxability and 14% separate-tax amount, or comparing separate vs. comprehensive), and explicitly redirects deemed-rent-only needs to housing_deemed_rent_income. The '지원하지 않음' block lists concrete out-of-scope cases (겸용주택, 공동소유 주택 수, 국외주택 보증금 간주임대료, 조특법 제96조, 2020.10.7. 개정 갈림, 2016 이전/2027 이후) and says it halts for input confirmation — an unusually explicit when-not.

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 value beyond that by stating what the computation returns (차가감소득금액, 각사업연도소득금액, 익금산입_손금불산입, 손금산입_익금불산입, 세무조정, 판단, 근거 with cited 법인세법 articles), which no structured field provides 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?

The 언제/입력/결과 labeling front-loads purpose and makes the block scannable despite its density. The '입력:' portion is largely a paraphrase of a schema that is already fully documented, which is the one place sentences don't fully earn their place.

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 carries the burden of describing returns and does list the result fields plus the legal grounds, which is sufficient for an agent to know what to expect. Minor gaps: the exact shape of 판단/근거 and how unrecognized item 종류 are handled are 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 description coverage is 100%, so the baseline is 3. The '입력:' section restates each parameter's meaning and adds a small clarification (donation_excess is added after 차가감), but that clarification already appears in the property description, so there is little genuinely new semantic information.

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 (집계/aggregate) and a precise resource (차가감소득금액 and 각 사업연도소득금액 on the corporate tax adjustment schedule), which is far more informative than the tool name alone. It implicitly separates itself from item-level siblings (donation_limit, entertainment_adjustment, depreciation_adjustment, income_loss_offset) by taking the whole adjustment list as input, but it never states that differentiation 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?

The '언제:' block gives an explicit triggering scenario — computing 차가감소득금액/각사업연도소득금액 by adding or subtracting 익금산입·손금산입 from net income. It does not say when NOT to use it or name the alternative tools an agent should call for individual limit computations.

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 real domain behavior beyond them: 부동산임대 losses offset only against 부동산임대 income (제45조②) while 주거용임대 losses offset against other income, the estimated-taxation rule that suspends carryforward deduction without lapse (제45조④), and the mutual exclusion of history vs carryforwards. Return behavior is only sketched, keeping it below a 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?

Purpose, when-to-use, inputs, and outputs are cleanly labeled and front-loaded in a few dense lines with no filler. The input-mapping block is somewhat redundant with the schema and could be trimmed.

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 7-parameter, nested-object tool with no output schema, the description supplies both the statutory rules governing the calculation and an explicit 결과 enumeration (공제 후 소득금액, 이월결손금 이월, 소멸, 근거), covering what an agent needs before invoking.

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 100% and each property already documents format, examples, and the history/carryforwards exclusion, so the description's input-mapping list (귀속연도 → year, etc.) largely restates structured data. It adds the note that 사업소득 must go to business rather than incomes['사업'], but that too is present in the 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?

The opening line names a specific computation (종합소득금액 after 결손금/이월결손금 공제), which is clearly a tax-offset operation distinct from siblings like loss_carryforward_limit or income_adjustment_total. It does not explicitly name those siblings or state boundaries against them, so it stops short of 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?

The '언제' clause gives a clear trigger: when business-income losses or carryforward losses are to be offset against other comprehensive income. No when-not conditions or named alternatives are provided, so it is contextual but not routing-level 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 this a pure, idempotent, deterministic read/compute operation, so the burden is lower. The description adds genuinely useful context beyond the annotations: it discloses the year range (2016~2026) and that the result includes the computed tax amount plus its legal basis (소득세법 제55조), reinforcing the deterministic, table-driven nature.

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, followed by a disciplined 언제/입력/결과 (when/input/result) structure that is easy to scan. The bilingual restatement is mildly redundant but each section carries distinct information rather than padding.

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 rightly covers the return (산출세액 plus legal basis). For a two-parameter deterministic calculator that is nearly complete; the only minor omission is whether the result excludes separate local income tax, which affects how the agent presents the output.

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 100%, so the schema already documents base as the comprehensive income tax base in KRW and year as the attribution year bounded 2016~2026. The description restates these in structured form (입력: base, year) but adds little syntax or semantic detail beyond what the schema provides, so the baseline of 3 applies.

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+resource: computing the comprehensive income tax (종합소득세 산출세액) from a tax base using a year-specific rate table. It scopes the subject matter (근로·사업·기타·이자·배당 등 종합과세 대상) and notes the legal basis (소득세법 제55조), which differentiates it from siblings like wage_income_tax, corporate_tax, and retirement_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 gives a clear precondition for use: 'when the comprehensive income tax base is determined' (종합소득 과세표준이 정해지면). However, it names no explicit alternatives or exclusion conditions against the many sibling calculators, so the agent must infer routing from the resource name rather than being told.

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?

Although annotations already establish a safe read-only, idempotent computation, the description adds substantial behavioral context beyond them: the exact statutory ordering of political/hometown, special, and general donation limits, carryover priority within the same category, in-kind valuation rules, volunteer-service valuation rules, and the explicit boundary that the tax-credit amount itself is not computed. This gives the agent the calculation logic and limitations needed to invoke the tool correctly.

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 but well organized, front-loading purpose and usage before proceeding through ordering rules, valuation rules, input mapping, and output summary. Each section is relevant to correct invocation. It loses a point only because the arrow notation and statutory references make it heavier than necessary for quick reading.

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 12-parameter tax calculation with no output schema, the description is complete enough: it explains the legal basis, calculation order, in-kind and volunteer valuation, input mapping, expected outputs, and the important non-calculation boundary for tax credits. An agent would not need outside context to understand when and how to call this 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 100%, so every parameter is already documented in detail. The description's input mapping line (base_income, carried_loss, political, hometown, special, general, religious, carried_*, volunteer, in_kind) mostly mirrors what the schema already says, including the note that base_income excludes interest and dividends. It is useful as a compact orientation but adds little semantic meaning beyond the 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?

The description clearly states the specific resource and operation: calculating the necessary-expense inclusion limit for individual-business donations under Income Tax Act Article 34, including the treatment of political, hometown, special, and general/religious donations. It also explicitly scopes out the tax-credit amount calculation, which helps distinguish it from broader donation or tax-credit tools. However, it does not name the sibling tool `donation_limit`, so sibling differentiation is implicit rather than explicit.

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 '언제' section gives a clear context: use during a business-income taxpayer's comprehensive income tax filing when determining how much of each donation type is deductible as a necessary expense and how much carries over or becomes tax-credit eligible. It also states what the tool does not calculate, which prevents misuse for tax-credit computation. It stops short of explicitly naming alternative tools for overlapping donation-limit or comprehensive-income calculations.

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), yet the description still adds real domain behavior: the priority order of valuation methods and the rule that values outside the valuation window (상속 전후 6개월, 증여 전 6개월~후 3개월) are excluded from market value. That exclusion rule is the kind of trap an agent would otherwise fall into. It stops short of describing output shape in full, but it does name the result 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?

Purpose, trigger, inputs, outputs and caveats are laid out as labeled blocks with the most important information first. The input list is mildly redundant with the schema, but each remaining sentence (valuation order, exclusion window) carries distinct decision-relevant content.

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 five-parameter tool with no output schema, the definition supplies the legal basis, the valuation-tier logic, the period-exclusion caveat and a sketch of the return fields (평가액, 계산.시가·적용·담보채권액, 판단). That is close to self-sufficient; a bit more on how secured_debt interacts with the 담보권 특례 would close the 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 100%, so the schema already explains kind, valuation_date, supplementary_value, market_values and secured_debt, including the enum values and the market_values entry format. The description's '입력' block largely restates that list and adds no syntax or constraint detail (e.g., how secured_debt feeds the 담보권 특례) beyond the schema, so baseline 3 applies.

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 definition names a specific verb and resource (상속·증여재산 평가) and the exact statutory basis (상증법 제60조·제66조, 영 제49조·제63조), then immediately states the valuation waterfall (시가 → 보충적 평가 → 담보권 특례). This is clearly distinguishable from the tax-computation siblings inheritance_tax and gift_tax, which compute liability rather than property value.

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 '언제' line gives an explicit trigger (when the market value of inherited or gifted property is needed), and the fallback chain tells the agent which valuation tier applies depending on the inputs available. It does not, however, name a sibling alternative or state when this tool should not be used instead of inheritance_tax/gift_tax.

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=true, idempotentHint=true, and destructiveHint=false, so the tool is a pure calculator. The description adds useful behavioral scope: it applies only to resident decedents and enumerates the categories of deductions and credits handled, which goes 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?

Front-loads purpose, then clearly separates '언제:' (when), '입력:' (input), and '결과:' (result) sections. For a 31-parameter tool, it is dense but well-organized with no wasted sentences.

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 31 parameters, no output schema, and a complex tax calculation, the description adequately covers inputs at a high level and explicitly lists the return values (taxable amount, deductions, tax base, computed tax, credits, payable tax, deduction details, basis). It could explain a few more edge cases but is largely 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 100%, so every parameter is already documented. The description maps key concepts to parameters (estate_value, year, deemed_estate, presumed_items) and explains the spouse.legal_share format, but this largely repeats schema content. Baseline 3 is appropriate.

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: calculating inheritance tax for a resident decedent, covering taxable estate, deductions, tax base, computed tax, and payable tax. The scope and output components are precise enough to distinguish it from sibling tools like gift_tax or capital_gains_income.

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 when to use it: '상속세 신고·계산 시' (at the time of inheritance tax filing/calculation). It does not name alternatives or when-not-to-use, but the domain is clear enough that an agent can select it correctly.

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 read-only, idempotent, non-destructive behavior, so the description only needs to add operational detail — and it does: the mutual exclusivity of input_tax and bundle (error case), the internal reuse of bundled_supply_split rules, and the shape of the return (이력/결과/판단/근거). The result-field naming caveat ('건물_매입세액은 옛 이름') is a useful extra.

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 legal basis, then organized into 언제/입력/결과 blocks with no filler sentences. It is dense but every clause carries information an agent needs; only the parenthetical legacy-name note is slightly incidental.

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 enumerating the return structure (이력, 결과, 판단, 근거) and the error condition for conflicting inputs. For a complex, nested-parameter recalculation tool this is nearly complete, though exact field-level output detail is only sketched.

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 100%, so the baseline is 3; the description earns above that by mapping domain concepts to parameters (자산 종류→asset_type, 취득 과세기간→acquired) and by specifying the ordering rule for ratios (last entry must be the current period) and the internal structure of bundle.

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 (감가상각자산 공통매입세액 재계산) and anchors it to the governing statute (부가법 제41조, 영 제83조). This clearly separates it from sibling allocation tools like common_input_tax and vat_common_input_allocation, which do not address depreciable-asset recalculation.

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 '언제' section gives a concrete trigger — exemption-ratio shifting by ≥5%p versus the acquisition period at final return — which is real decision guidance. It also explains the input_tax vs bundle alternative and that supplying both is an error, but stops short of saying when a competing sibling tool should be chosen instead.

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 the safety profile is covered. The description adds real behavioral context beyond that: it is a pure calculation engine that emits adjustment-line items, per-category judgments, income/deduction totals, net adjustment amounts, and cites the governing statute (법인세법 제42조, 시행령 제73·74조).

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 purpose, then labeled sections (언제 / 입력 / 결과 / 근거) make it easy to scan. It is relatively long and the 입력 block partially restates the schema, but for a tool of this domain complexity each section carries useful 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 enumerating the result contents (adjustment list, per-category valuation, income/deduction totals, net, deadline computation, basis). Combined with the fully-covered input parameters and legal citations, an agent has enough to invoke and interpret it, though edge-case error behavior 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 100%, so baseline would be 3, but the description genuinely enriches the parameters: it enumerates category values ('제품·상품'|'반제품·재공품'|'원재료'|'저장품'|'매매목적부동산'), the 원가법 6종/'무신고' method set, the lcm flag meaning, the change_report sub-fields, and adds the new_corp deadline rule (종료일 달 말일 + 3개월) absent from the 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?

The opening states a precise verb+resource: inventory-asset valuation tax adjustment (재고자산 평가 세무조정) with the sub-scope ʻdetermining the statutory valuation method and reserving the valuation difference.ʼ This is clearly distinguishable from siblings like depreciation_adjustment or bad_debt_adjustment 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?

An explicit '언제:' clause gives the trigger condition — corporate-tax adjustments where ending inventory value differs from book value and the difference is reserved. Clear context is provided, but no when-not conditions or named alternatives are offered.

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 real behavioral context beyond that: the applicable rates, that the rate depends on the supply date, and the legal basis (부가가치세법 제60조).

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 tool's identity and rate table, then uses labeled 언제/입력/결과 sections that make it scannable. Dense but every clause carries information; no wasted 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?

With no output schema, the description usefully discloses what is returned (penalty amount, applied rate, legal basis). Inputs, trigger, and output are all covered, leaving only minor gaps like rounding or multi-year handling.

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 100%, so the schema already documents all three parameters. The description largely restates the same mapping (supply_amount, kind, supplied_on) without adding syntax or format detail beyond the schema's own '세율 기준 연도' note, so baseline 3 applies.

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 (구한다/compute) and a precise resource (세금계산서 가산세) and even enumerates the penalty types and rates it handles. The scope is clearly distinct from the other penalty siblings (underreporting_penalty, late_payment_penalty), though it never explicitly names 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?

The '언제:' clause gives an explicit trigger condition — when the invoice issuance/receipt obligation is violated. This is clear usage context, but there is no 'when-not' guidance and no named alternative tool to route against.

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 no annotations, the description carries the full burden and does reasonably well: it explains this is a query/computation returning relationship degree, reference date, kinship scope, national-tax-law kin status, and inheritance/gift kin (including in-law) status. It does not explicitly state read-only nature or any limits, but for a pure computation tool the disclosed output structure is solid behavioral context.

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?

It is well-structured with 언제/입력/결과 labels and the purpose is front-loaded. However, the closing sentence repeats the opening sentence almost verbatim, and the input list duplicates the schema, so there is some redundancy.

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 to enumerate the return contents (relationship, reference date, kinship scope, 국기법/상증법 kin status), and there is no output schema to make that redundant. For a four-parameter query tool it covers purpose, inputs, and outputs adequately.

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 100%, so the baseline is 3. The description restates the family format [[a,b,"부모자녀"|"배우자"]] and its relation to related_judge, matching what the schema already documents, adding little new semantics beyond the structured fields.

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: computing the kinship relationship (blood/in-law degree, spouse) between two named individuals and whether they fall within the kinship scope on a reference date. It also names the sibling related_judge as sharing the same input format, letting an agent place it among the tax-relation tools 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?

The '언제' clause gives explicit triggering conditions: when checking if two people are kin, or whether they fall under the Framework Act on National Taxes / Inheritance and Gift Tax Act kinship scope. It gives clear context but no when-not guidance or explicit alternatives beyond the format reference to related_judge.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond the annotations: the calculation formula, that the daily rate is split at rate-change dates, the return summary (total penalty and legal basis), and the governing statute. It does not discuss edge cases or validation, but the extra calculation semantics are valuable.

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 front-loaded with the formula, then broken into when/input/result sections, and ends with a compact English summary. Every sentence contributes to selecting or invoking the tool; there is no 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 read-only calculation tool with no output schema, the description supplies the inputs, the calculation method, the expected output summary (total penalty and legal basis), and the legal references. It is nearly complete, though it could say more about output structure or rate-change date handling.

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 100%, and the schema already documents each parameter in Korean. The description maps input meanings to parameter names ('unpaid_tax', 'due', 'until') and restates the date formats, but adds no syntax or constraints beyond the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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: calculating late-payment penalty (가산세) on unpaid tax for the number of days past the legal due date. It also gives the exact formula, distinguishing it from sibling penalty tools like underreporting_penalty or invoice_penalty, which cover different penalty 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 explicitly says when to use the tool: when tax is paid later than the legal due date ('세금을 법정납부기한보다 늦게 납부했을 때'). It does not name alternatives or exclusions, but the triggering condition is clear enough for an agent to route correctly.

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