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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the calculation semantics (손금산입 한도, 상계액, 처분 익금) but no further behavioral caveats such as statutory limits or data prerequisites beyond what the schema states.

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 three labeled blocks (what / 언제 / 입력 / 결과) are front-loaded and waste no words; the only weakness is that the 입력 and 결과 sections read as serialized lists rather than prioritized guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 9 parameters, the description usefully enumerates the returned figures (손금산입 한도, 충당금 설정금액, 상계액, 처분 익금, 소득금액 순영향, 세무조정, 근거), so an agent knows what it gets back. It is complete for calling the tool, though it does not explain how the optional fields (planned_use, expired_unused, receipt_year, claim_by_return, lost_book_value) alter the computation.

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 the schema. The description's input mapping (사업연도→year, 재원 구분→kind, 수령액→received, 자산별 내역→assets) is a restatement that adds no syntax, format, or interaction detail for the optional parameters.

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

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

The opening sentence names a specific action (세무조정) applied to precisely enumerated resources (국고보조금·공사부담금·보험차익 일시상각충당금·압축기장충당금), which is unique across the ~60 sibling tax tools and lets an agent identify it 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 a concrete triggering context (a corporation that acquired/improved business assets using subsidies, public-works contributions, or insurance proceeds, needing 손금산입·충당금 상계·처분 계산). It never names an alternative tool or an exclusion, so it stops short of a 5.

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

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

Annotations already 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?

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 declare a pure read-only, idempotent calculation, so safety is covered. The description adds value beyond that by disclosing what the result contains (업무사용비율, 손금불산입, 감가상각 한도) and the legal basis (법인세법 제27조의2, 시행령 제50조의2), which matters because there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then clearly labelled 언제/입력/결과 sections. Efficient, though listing every parameter mapping is mildly redundant against a fully documented 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?

For a complex multi-input tax calculation, the description covers purpose, trigger condition, input meaning, the returned values, and the statutory basis. With no output schema, the 결과 sentence fills that gap, so an agent has everything needed to call and interpret 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 the schema already documents all nine parameters. The description restates the same Korean labels and units with no new syntax or format information, so 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+resource: calculating 손금불산입 for 업무용승용차 관련비용, and enumerates the sub-cases it covers (업무사용비율, 사적사용, 미작성 시 기준비율, 감가상각 800만 원 한도). The domain is clearly orthogonal to every sibling (none address car expenses), so an agent can distinguish it 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 a clear trigger: when computing how much car expense for executives/employees is deductible. It gives context but names no exclusions or alternative tools to prefer, so it stops short of a 5.

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

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

Annotations already declare 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 readOnly/idempotent/non-destructive, and the description adds materially more: the exact failure mode ('재원 어휘에 없으면 error 반환(계산하지 않음)'), the full per-shareholder return shape, and a non-obvious computation rule for partial 재평가적립금 transfers with the governing statutory provisions. This is dense behavioral context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose, then cleanly sectioned into 언제 / 입력 / 결과, and every line carries calculation-relevant content. It is long and repeats a few schema facts (year range), but the density of domain rules justifies 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 7-required-parameter calculation tool with no output schema, the description is complete: it enumerates the inputs, enumerates the return fields (배정주식수, 전입전지분율, 전입후지분율, 의제배당, 과세여부, 근거, totals), and defines error behavior. An agent has everything needed to call and interpret 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 coverage is already 100%, so the baseline is 3. The description earns above baseline by classifying the source vocabulary keys into taxable vs tax-exempt vs Gross-up-exempt, and by tying shareholder_type to the differing governing statutes (법인세법 제16조 vs 소득세법 제17조). The remaining parameters largely restate 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 states a specific verb+resource+granularity: it computes per-shareholder deemed dividend (의제배당) when surplus is capitalized into capital via a bonus-share issue (무상증자). The scenario is precise enough that an agent can distinguish it from the capital-reduction sibling (deemed_dividend_capital_reduction), but no sibling is named explicitly, so it falls short of the top band.

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 an explicit trigger condition for using the tool. However, there are no when-not conditions and no alternative tool named (e.g. the deemed_dividend_capital_reduction path), so it is clear context without exclusions.

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 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?

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 this as a safe, read-only, idempotent, closed-world computation, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the fail-fast contract that missing facts cause the tool to return the required inputs, and it enumerates the result structure (per-item taxable/non-taxable, basis, reason, excluded items, totals). It does not explain handling of unsupported kinds or error surfaces.

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?

Long but tightly organized behind 언제 / 입력 / 결과 headers, with purpose front-loaded. The dense per-kind fact list is largely necessary for a tool of this complexity, though it is close to the point where detail crowds out quick scanning.

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 listing every result component. Input semantics are unusually well covered. The only shortfall is the absence of boundaries against similar siblings and of any note on limits or failure modes beyond missing facts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is nominally 100%, but the items array is effectively untyped in the schema; the description is the only place that enumerates each kind and the specific facts each kind requires (service_year, months, vehicle type, related_party, etc.). That is substantial meaning beyond structured fields, though value formats and defaults are still unstated.

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 chain: it 판정s taxable/non-taxable status per item and computes 총급여액·근로소득공제·근로소득금액, citing the exact statutory provisions. It is clearly distinguishable from generic income tools by scope, but it never names the closely related siblings (e.g. wage_income_tax, retirement_income_tax) to draw the boundary, so an agent could still confuse gross-pay computation with the actual tax-amount tool.

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 explicit triggering contexts (연말정산, 종합소득세 신고, when 총급여액/근로소득금액 are needed) and the input section implies the data shape required. There is no when-not guidance nor any pointer to an alternative tool for the tax amount versus the gross-pay base.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavior beyond that by naming the outputs (limit, excess/non-deductible, legal basis under Corporate Tax Act Art. 25 / Decree Art. 42), which matters since there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with explicit 언제/입력/결과 (when/input/result) sections that are front-loaded and scannable. Minor redundancy in the closing sentence, which restates the purpose already given in the opening line.

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 deterministic tax-calculation tool with read-only annotations and no output schema, the description covers the trigger context, the full input mapping, and the expected outputs plus legal basis. Complete enough to invoke correctly; only the sibling distinction is absent.

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 compensates for the schema's generic '금액(원)' labels by mapping Korean tax concepts to parameter names ('수입금액(일반) → general_revenue', '지출액(접대비) → expensed', etc.). This adds genuine semantic meaning over the terse 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?

States a specific verb and resource ('기업업무추진비 한도와 한도초과액 계산' / calculate the entertainment expense limit and excess). An agent can tell it computes a deduction cap, but the description never distinguishes it from the very similar sibling 'entertainment_adjustment', which appears in the same list.

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

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

Gives explicit context through the '언제' (when) cue: during corporate tax adjustment to obtain the non-deductible entertainment amount, and to check whether entertainment exceeds the limit. Clear usage context, but no when-not condition and no pointer to the near-duplicate sibling 'entertainment_adjustment'.

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 readOnly/idempotent/non-destructive. The description adds real behavioral context beyond that: per-kind treatment (which kinds are unconditionally separately taxed and therefore excluded from the 합계·합산액, e.g. 법원보증금이자, 직장공제회초과반환금), which are Gross-up 대상 vs 비대상, and the year range. It does not detail the return shape beyond category names, but the tax-treatment disclosures are substantive.

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?

Long, but front-loaded and structurally segmented into 언제/입력/결과 with a bulleted kind list. Each kind definition earns its place because the correct kind selection drives the tax treatment, though the statutory asides (e.g. the 재평가적립금 1% apportionment formula) are denser than strictly needed for invocation.

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 outlines the return categories (판단·결과·계산), so an agent knows what comes back. Combined with the annotated read-only profile and full kind semantics, it is complete enough to call correctly, with only minor gaps in exact item-object fields.

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 goes well beyond the schema by defining the meaning of each kind value (with aliases and statutory bases) and specifying that year maps to 귀속연도 2016–2026. It could still clarify the full shape of each item object ('{kind, amount, ...}' leaves extra fields implicit).

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

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

States a specific verb and resource: aggregating financial income (interest/dividends) and computing the dividend gross-up, anchored to named tax-law articles (소득세법 제14·16·17·56조). This is clearly distinguishable from siblings like other_income_aggregate, income_tax, 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?

The '언제' section explicitly states the triggering context: filing comprehensive income tax and needing to determine whether financial income is subject to aggregation and to compute the gross-up amount. It does not, however, name a sibling alternative or state when-not to use this tool.

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

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds that the tool returns an intermediate computation chain including '근거' (basis), which is mildly useful, but it discloses no validations, error conditions, or edge-case behavior beyond that.

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 organized into 언제 / 입력 / 결과 sections with purpose front-loaded. The closing sentence ('증여세 과세가액·공제·세액 계산') redundantly restates the opening, but overall it is efficient and structured.

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 18-parameter complex tax tool with no output schema, the description compensates by enumerating the returned values (과세가액 through 납부할세액 and 근거) and covering the three required inputs. It is largely complete, though it could clarify which of the 15 optional parameters materially change the computation.

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 18 parameters. The description maps seven concepts (gift_date, gift_value, relation, prior_gifts_same_donor, assumed_debt, prior_deduction_used, marriage_birth) to fields, but this largely restates the existing schema descriptions, 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 names a specific verb+resource: computing a resident donee's gift tax chain (과세가액·증여재산공제·과세표준·산출세액·납부할세액). An agent can tell it is a gift-tax calculation tool. It does not explicitly distinguish itself from siblings like inheritance_tax or tunnelling_gift, so it falls short of 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?

'언제: 증여세 신고·계산 시' gives the triggering context (gift tax filing/calculation). However, no alternatives or when-not conditions are named, even though siblings such as inheritance_tax and tunnelling_gift exist. This is implied usage, not explicit routing.

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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description adds genuinely new behavior: an error is raised if both input_tax and bundle are supplied, and bundle input is internally allocated using the same rules as bundled_supply_split. It also previews the returned sections (이력/결과/판단/근거), though it says nothing about permissions or performance.

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 as 언제/입력/결과 with short bullets; every line carries information. It is dense but not padded, with only mild redundancy between the bundle bullet and the bundle schema description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the returned structure (history with ratio, benchmark, variance, recalculation flag, elapsed periods, tax amount; result; judgment basis; legal grounds). For a 5-parameter tool with nested objects, an agent has everything needed to call and interpret 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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema by pairing Korean field labels with parameter names, specifying that ratios must run acquisition-to-current with the last entry being the current period, and documenting the input_tax/bundle exclusivity that the schema does not state.

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 legal basis (부가법 제41조, 영 제83조), and its scope is clearly narrower than sibling allocation tools like vat_common_input_allocation or common_input_tax. An agent can distinguish it 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?

The '언제' section gives an explicit trigger condition: recalculation is required at the final return when the exempt ratio moves ≥5%p versus the acquisition period. It also states the alternative input path (bundle instead of input_tax) and the mutual-exclusion rule, so both when-to-use and which-input questions are answered.

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.

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the full safety profile is already covered. The description adds the legal basis (법인세법 제13조① 단서) and the return shape (한도율 소수 and 근거), which is useful context. However, it does not mention boundary behavior for out-of-range years or whether 'sme' affects the legal citation, so a baseline 3 is appropriate.

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?

Three tightly packed sentences front-loaded with purpose, then when, inputs, and result. Every clause earns its place; no repetition of the tool name, 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 2-parameter, read-only, no-output-schema tool, the description covers purpose, trigger condition, parameter mapping, return value (한도율 소수 + 근거), and legal citation. Annotations cover safety. 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% – both year (2016–2026) and sme (중소기업 등 여부) are fully documented in the JSON schema with min/max and description. The description maps inputs to outputs ('사업연도 → year, 중소기업 등 여부 → sme') but adds no syntax or format detail beyond the schema. Baseline 3 when 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?

Clearly states the specific formula-driven metric (이월결손금 공제 한도율 based on fiscal year start) as a compound verb+resource. It is easily distinguishable from the many tax-calculation siblings (entertainment_limit, donation_limit, minimum_tax) because it names the exact tax-law provision (법인세법 제13조① 단서) and the scope (deduction limit ratio for loss carryforwards). No ambiguity about what the tool returns.

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 answers 'when': '언제: 이월결손금이 있을 때 해당 사업연도에 얼마까지 공제되는지 한도율을 확인한다.' This names the triggering condition and the question the agent should have. No alternative sibling is named, but the condition is so specific that an agent can route unambiguously.

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 safety profile is covered. The description adds that this is a deterministic formula-based calculation with a stated legal basis, but does not disclose behavior beyond the computation itself (no return format detail beyond '최저한세액, 근거'). Adequate against annotations that carry the safety load.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then uses labeled sections (언제/입력/결과) so the agent can parse it at a glance. Dense but every element earns its place; the trailing English restatement is minor 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?

For a 4-parameter calculator with no output schema, the description compensates by disclosing the return values (최저한세액, 근거) and the input-to-parameter mapping. The SME/grace-year interaction is mentioned, leaving nothing critical missing for a correct call.

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. However, the description maps each parameter to the actual formula (base_before_incentives = pre-incentive tax base, grace_year = years since SME graduation, 0~5), adding semantic role beyond the schema's field labels.

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 with the actual formula (감면 전 과세표준 × 최저한세율) and cites the statutory basis (조세특례제한법 제132조①), so the agent knows exactly what is computed. It does not explicitly contrast itself with the sibling corporate_tax, so sibling differentiation is left implicit.

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 clearly states the trigger context: checking the minimum tax still owed even after credits/deductions, including SME graduation grace years. It gives clear context but names no alternative tool or when-not condition.

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

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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds real context on top: the legal basis (법인세법 제25조②, 시행령 제41조①), the statutory thresholds that drive the computation, and the fact that it returns an aggregate disallowance amount.

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 a labeled 언제/입력/결과 structure that is easy to scan and front-loads the purpose. Slightly redundant, since the opening parenthetical and the closing sentence both restate '적격증빙 미수취 기업업무추진비 손금불산입'.

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 calculation tool with no output schema, the description supplies the input mapping, the computed result (손금불산입 합계액), the legal citation, and the thresholds. Nothing needed 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 description coverage is 100% — year and items (including nested amount/qualified/congratulatory) are already documented in the schema. The description restates the same field meanings without adding format, unit, or edge-case guidance beyond what is structured, 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?

Names a precise resource and scope: computing the non-deductible amount (손금불산입) for 기업업무추진비 where no qualified receipt was obtained, including the exact thresholds (30,000 won per case, 200,000 won congratulatory). This narrows it well against related siblings like entertainment_limit and entertainment_adjustment, though it never names those siblings explicitly to make the boundary unambiguous.

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

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

The '언제' clause gives a clear triggering condition: use it when entertainment-type expenses were incurred without a qualified receipt. It does not state when NOT to use it or point to the adjacent entertainment_limit / entertainment_adjustment tools that cover the broader cap calculation.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds substantive behavioral context beyond that: the exact formula (지급이자 × min(1, 업무무관 적수 ÷ 총 차입금 적수)) and the legal basis (법인세법 제28조①4호, 시행령 제53조).

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 tool's purpose, then cleanly labeled 언제/입력/결과 sections. Every sentence carries information: condition, inputs, output, legal citation, and formula, with 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 fully specifies inputs, the exact computation, the returned value (disallowed interest), and its statutory basis. An agent has everything needed to invoke and interpret 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 coverage is 100%, so the flat per-parameter descriptions already establish a baseline of 3. The description goes further by showing how both inputs feed the formula (per-loan interest/jeoksu plus the aggregate nonbusiness_jeoksu), which adds interpretive meaning beyond the schema's field labels.

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

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

States a precise verb+resource: computing the non-deductible portion of interest paid (지급이자 손금불산입) tied to non-business assets and 가지급금. This is specific enough to separate it from siblings like deemed_interest or thin_capitalization, which address different disallowance rules.

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) line gives a clear triggering condition: when non-business assets or provisional payments exist and you need the disallowed interest amount. It does not, however, name exclusions or adjacent alternatives (e.g. deemed_interest, thin_capitalization) among the numerous sibling 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real computation context: 적용세율 = min(국내세율, 조약 제한세율) and 지방소득세 10% separate. This tells the agent how the number is derived, which annotations cannot. It stops short of rate limits or edge-case caveats.

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 that an agent can scan quickly. It is somewhat long and the '입력' block duplicates schema content, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description compensates by describing the return contents (원천징수세액·지방소득세·적용세율·국내세율·근거) and the calculation rule. Together with 100% schema coverage this is nearly complete, though it omits treaty-rate sourcing guidance and any failure/validation behavior.

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, and the description's '입력' list largely restates the schema's field mappings. It adds only marginal framing (e.g. bond_interest/related_party being meaningful only for interest income), which the schema also notes, so baseline 3 is right.

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 precise scope ('비거주자·외국법인 국내원천소득 원천징수') and cites the governing law (소득세법 제156조 / 법인세법 제98조). The non-resident/foreign-corporation scope cleanly separates it from generic siblings like withholding_tax, wage_income_tax, and daily_worker_withholding without needing to name 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 '언제' section gives an explicit trigger condition: when paying interest, dividends, royalties, personal services or other income to a non-resident/foreign corporation. It does not state when NOT to use it or name the alternative tool for domestic withholding, so it falls short of the 5 bar.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes well beyond that by disclosing domain behavior: it operates on original facts (원래 사실관계), lists special treatments per category (배임수재/알선수재 unconditional comprehensive taxation with no withholding, 복권당첨금 unconditional separate taxation), and notes conditional required sub-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?

Front-loaded with a one-line summary, then structured under 입력/결과 labels with bulleted kind definitions. Length is justified by the domain complexity, though the kind list is dense and slightly repetitive with the schema's kind hint.

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, schema-light tool with no output schema, the description covers the result shape (판단/결과/계산) and the input vocabulary in detail. It does not specify exact output field names, but the annotation set already carries the safety profile, so the definition is essentially 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 coverage is 100%, so the baseline is 3. The description substantially enriches it: it defines the full kind vocabulary with legal meaning and aliases, and documents auxiliary sub-fields (forfeited, deposit_substituted, employment_exempt_used, actual_cost) that the schema does not mention.

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 computes 기타소득 tax classification, necessary expenses, withholding, and aggregate income — and enumerates the four output dimensions. The resource (기타소득) is clearly distinguishable from sibling aggregators like financial_income_aggregate.

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 the triggering context ('종합소득세 신고에서 기타소득의 과세 구분·필요경비·원천징수세액·종합소득 합산액을 계산할 때'), giving clear when-to-use guidance. It does not name alternatives or exclusions, 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?

With no annotations, the description carries the full burden, and it does disclose the computation model (path-product summation, circular investment handled at every stage) plus the legal basis (상증법 시행령 제34조의3②). It does not describe limits, validation of inputs, or failure behavior, but for a pure calculation tool this is substantial disclosure.

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 입력/결과/언제 labels make it well-structured and front-loaded, but the final sentence nearly restates the opening clause ('보유자→법인 직접·간접 보유비율을 계산한다'), duplicating content instead of 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, so the description usefully enumerates what is returned (직접비율, 경로별 비율, 합계, 순환출자 여부, 근거 법조). With all three parameters required and covered, the definition is close to self-sufficient, though it omits any note on input validation 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 coverage is already 100%, so the baseline is 3, but the description adds cross-tool semantics by stating stakes='[[보유자, 법인, 지분율(0~1)]]' is identical to related_judge's input and by mapping natural-language names to holder/target. That cross-reference value goes beyond the schema's own example.

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 ('보유자→법인 직접·간접 보유비율을 계산한다') and adds the algorithmic qualifier that indirect holdings are the product of per-stage ratios summed across paths with circular investment reflected. It references related_judge but only to align input format, not to disambiguate scope, so it stops short of a full sibling distinction.

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 names the concrete decision contexts (일감몰아주기, 지배주주 판정) where this tool is used to compute indirect ownership. It gives clear context but does not state when NOT to use it or point to alternative tools such as dominant_shareholder or 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?

No annotations are provided, so the description carries the behavioral burden, and it does disclose the return contract ('각 입력키의 의미·단위·필수 여부를 목록으로 반환'). It does not explicitly state that the call is side-effect-free, but for a schema-introspection tool this is minor.

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?

Three tight clauses labeled 언제/입력/결과 make the when, the input, and the output scannable with zero filler. Everything is front-loaded and each phrase 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 must explain return values, which it does (list of meaning, unit, required-ness per key). For a one-parameter introspection tool this is complete enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single enum parameter is already fully documented in the schema. The description merely restates 'tax=법인|부가|소득', adding no unit, format, or edge-case detail 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?

States a specific resource (신고서 사전검토 입력스키마) and its function, and explicitly names the sibling tools it supports (return_precheck and the English-PDF return tool). An agent can distinguish it from the dozens of tax-calculation siblings 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 precondition: use it before invoking return_precheck or the English tax-return PDF tool to discover which keys are required. This is a concrete when-to-use statement tied directly to named alternatives.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the result shape (특수관계 여부·적용 호수, 근거 조문, 기준일 시행 법령 위치), which matters because there is no output schema, but it says nothing about determinism, permissions, failure modes, or limits.

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 scannable, but the final sentence duplicates the opening sentence almost verbatim, and the full parameter enumeration duplicates the schema. Real structural value is diluted by this 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?

For a 13-parameter tool with nested objects and no output schema, the description explains both the inputs conceptually and what the return contains, including citation behavior tied to with_citation and the date-sensitive law version. A high-complexity tool is covered adequately, missing only edge-case behavior.

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 13 parameters including examples for nested structures. The '입력' block mostly restates the schema in prose and adds no syntax or format detail beyond it, fitting the baseline 3 for high coverage.

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

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

States a specific verb (판정한다) and resource (두 당사자의 특수관계 여부·호수) and names the exact statutory bases (국세기본법·법인세법·상증법), so the agent knows precisely what is being computed. It does not explicitly distinguish itself from close siblings like kinship_check, related_provision_at, or extract_relations, which keeps it 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 concrete triggering contexts (세무조사·증여의제 검토), which is clear usage guidance. It never states when NOT to use it or names an alternative sibling for overlapping cases, so no exclusion routing is provided.

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?

No annotations are provided, so the description carries the full burden. It mentions the result fields (law name, provision, original text, reference date), which is useful, but it does not disclose whether this is a read-only lookup, whether the reference date must fall within an enacted period, how it behaves if no provision existed at that date, or any authorization needs. For a legal-lookup tool with zero annotation support, this is a significant gap.

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 repetitive: the core purpose sentence appears essentially twice (opening and closing), and the law parameter values are also repeated. The structure is not front-loaded cleanly; the reader must wade through redundant sentences to extract the unique information. It wastes space on restatements instead of adding new details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does partially compensate by listing expected result fields (law name, provision, original text, reference date). However, it omits behavioral details like what happens when the reference date predates the provision, whether the tool is read-only, and how the 'law' categories map to specific laws. For a legal-database lookup with zero structured behavioral hints, more completeness is needed.

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 both parameters ('law' with allowed values '국기|법인|상증', and 'on' as YYYY-MM-DD). The description repeats the same parameter meanings and adds an example ('law=법인, on=2019-02-11 → 법인세 시행령 제87조①'), but it does not provide enum validation rules or formatting nuances beyond what is already 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 description states a specific verb and resource: confirming where a related-party scope provision existed in law on a given reference date. However, it is repetitive, restating the same purpose three times ('특수관계인 범위 조문이 기준일에 어느 법령에 있었는지 확인' appears in the opening clause and again at the end), which blurs the core purpose rather than sharpening it. It does not explicitly differentiate itself from sibling tools like related_judge or extract_relations, so the purpose is clear but not sharply distinguished.

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

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

The description includes a 'when' clause ('특수관계 판정 결과를 근거로 인용할 때 해당 기준일 시행 조문의 위치를 확인한다'), which is a usage hint, but it does not name or compare against any alternative tool, nor does it state explicit exclusions. With over 40 sibling tools including related_judge and extract_relations that could also deal with related-party rules, absent routing guidance leaves the agent guessing.

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 this is a pure read-only, idempotent computation (readOnlyHint/idempotentHint true), and the description does not contradict that. It goes further by disclosing output semantics (과목·조정 유형·소득처분 유보/△유보·소득금액_순영향) and failure behavior ('장부 증감이 맞지 않으면 error'), which annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with legal basis, then when, then inputs, then outputs — good scanning order for a dense 8-parameter tax tool. Some of the '입력' lines restate the schema field descriptions near-verbatim, which is wasted text at 100% coverage, but the added judgment rules justify keeping the section.

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 '결과' section must carry the return contract, and it does sketch the adjustment line items, the 유보/△유보 disposition, the net income effect, and the supporting calculation. A mutation-free calculator with validation and error conditions stated is adequately covered, though the exact response shape remains only loosely specified.

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 '입력' block genuinely adds decision rules: '큰 금액을 씀' for lump_sum vs actuarial, the annual-table note that the accrual ratio is 0% after 2016, and exclusion of DC members and non-eligible employees from salary. These are selection rules not stated 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 description names a specific verb+resource combination (퇴직급여충당금·확정급여형 퇴직연금충당금 세무조정) and anchors it to the governing statute (법인세법 제33조, 시행령 제44조의2·제60조). An agent can distinguish this from the sibling retirement_income_tax, which concerns taxation of retirement income rather than the corporate-tax reserve 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?

An explicit '언제' block enumerates the three concrete scenarios (한도초과, 상계·부인액 추인, 퇴직연금 부담금 손금산입 한도) that call for this tool. It never names a sibling as an alternative or states when not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: the statutory basis (소득세법 제48조·제55조②), the deduction method, and the fact that the output is the tax amount plus rationale. It is a pure calculation, so little more behavior remains to disclose.

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 easy to scan, with the key purpose stated first. Slight redundancy from the parenthetical method repeated and the trailing English restatement of the title costs it a point.

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 stating the result is 퇴직소득세 plus its legal 근거. For a two-parameter, annotation-covered calculation tool this is essentially complete, lacking only edge-case notes (e.g., years beyond 60).

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 the description's input line largely restates the schema fields (income, years_of_service) including the 1~60 range already present in the schema. It adds the '비과세 제외' caveat, but otherwise the schema does the heavy lifting, 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 names a specific verb+resource (계산한다 / 퇴직소득세) and identifies the computation method (근속연수공제·환산급여 방식), which distinguishes it from siblings like wage_income_tax and income_tax. An agent can tell this computes severance-pay income tax 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 explicitly states the triggering condition — calculating tax when severance pay is paid out. That is clear usage context, but no alternative sibling is named or excluded, 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?

No annotations are supplied, so the description carries the full burden. It usefully enumerates the outcome states (오류 의심 / 이상 없음 / 자료 부족 / 사실 확인 필요), which is real behavioral disclosure given no output schema. But it says nothing about permissions, whether the call is read-only, side effects, or limits.

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, trigger, input, and output in a handful of clauses with zero filler. Every phrase maps to something an agent needs to act on.

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 summarizing the possible result categories, and it covers the dependency on precheck_schema. What is missing is any note on input shape limits or error behavior for an invalid data dictionary, but for a 2-parameter screening tool this is close to sufficient.

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 a 3 is the baseline, but the description adds meaning by framing data as a {input_key: value} dictionary whose keys must be validated against precheck_schema first, and by restating that omitting tax covers all tax types. That workflow context goes beyond the schema 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 verb+resource pair ('신고서 사전검토' / pre-investigation suspected-error list) and scopes it to before a tax investigation begins. It is distinguishable from precheck_schema (which it explicitly defers to for input keys) and from return_precheck_pdf, though the PDF sibling is never named.

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: use before a tax investigation starts to screen return values for suspected errors. It also tells the agent to resolve input keys via precheck_schema first. No explicit when-not or named alternative tool, 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?

With no annotations, the description carries the full burden and does so well: it discloses the output list categories (오류 의심/이상 없음/자료 부족/사실 확인 필요), inter-form reconciliation and tax-chain recalculation, AI-generated marking, and critically the dual backend behavior — local pypdf extraction by default versus Document Parse + Solar Pro 4 when UPSTAGE_API_KEY is set. Auth dependency and fallback behavior are explicitly surfaced.

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 and clearly sectioned (언제 / 입력 / 결과). It loses a point because the closing sentence ('법인세 신고서 PDF에서 표를 추출해 사전검토한다') merely repeats the opening instead of 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?

No output schema exists, so the description appropriately enumerates what is returned, and it explains the environment/key contingency affecting extraction quality. An agent has everything needed to call it and interpret its 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% and there is a single parameter, so the schema fully documents pdf_path. The description restates its meaning ('PDF 파일 경로 → pdf_path') without adding format or path-syntax detail, which is acceptable at this coverage level.

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 chain: extract tables from corporate tax return PDF (forms 1, 3, 50) and run a pre-check producing a suspicion list. This is distinguishable from the sibling return_precheck, which takes already-structured values.

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 context: when extracting values from a corporate tax return PDF to prepare input for return_precheck. It names the target sibling, but does not state the inverse condition (use return_precheck directly when values are already structured), so there is no explicit 'when not to use'.

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 declaring readOnly/idempotent/non-destructive, the bar is lower, and the description usefully adds the input transformation rules (항목명 → 역할 mapping via 어휘, supply amounts converted to total/card/mileage sums) and the '원래 사실관계에서 계산' behavior. It also pre-announces the judging/calculation/result output structure, which is valuable since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and statute, then cleanly divided into 언제/입력/결과 blocks that map to how an agent needs the information. Dense but every clause earns its place given the tool's 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 6-parameter, nested-object calculator with no output schema, the description supplies the missing return-value structure (판단/계산/결과/산식/근거) and the ledger transformation logic. It stops short of giving a concrete ledger example or vocabulary key list, leaving minor gaps an agent might still need to infer.

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 meaning beyond the schema by spelling out how ledger items are mapped to roles and converted into total/card/mileage aggregates, and noting that bad_debt_confirmed does not affect the tax. This goes past merely restating the field 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?

States a specific verb (계산) and resource (간이과세자 부가가치세 확정신고 차가감납부세액) with the statutory basis (법 제63조·제68조의2·제69조·제46조), so an agent knows it computes the full simplified-taxpayer final return rather than a single credit. It does not, however, explicitly distinguish itself from component siblings such as vat_simplified_taxpayer or vat_card_sales_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 '언제' section gives a clear trigger: use during a simplified taxpayer's final return for the 1.1–12.31 period, computing from original facts. There are no explicit exclusions or named alternatives, but the context is unambiguous enough to route 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 declare the safe read-only/idempotent/non-destructive profile, so the bar is lower. The description still adds real value by disclosing what the computation returns (excess borrowings, disallowed interest, disposition, optional withholding recalculation) and its legal basis, plus the industry-multiple caveat.

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?

Organized into 언제/입력/결과 blocks that front-load the rule and map inputs, which suits a complex multi-parameter tax computation. There is mild redundancy (recipient_residence_country is explained twice), keeping it short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema, the '결과' section explicitly describes the produced values and the optional withholding recalculation, and the legal basis is supplied. Nothing an agent needs to call and 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%, setting a baseline of 3, but the schema's descriptions for equity/borrowings/total_interest are terse ('금액(원)'). The description clarifies the distinct roles of each amount (controlling-shareholder equity, borrowings, total interest paid), adding 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 names a specific computation (과소자본 손금불산입) grounded in a cited statute (국제조세조정에 관한 법률 제22조) and states the exact trigger (foreign controlling-shareholder debt exceeding the equity multiple). This is unmistakably distinct from siblings like deemed_interest or nonbusiness_interest_disallowance even without naming 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 '언제' section gives an explicit triggering condition (borrowings from overseas controlling shareholder exceeding the baseline multiple, default 2x), which is clear usage context. It does not name alternative tools or state when NOT to use this one, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the optional UPSTAGE_API_KEY, the pypdf local fallback when the key is absent, the higher-fidelity Document Parse + Solar Pro path when set, and that output is a draft requiring human confirmation with an AI-generated marker. It omits failure modes and extraction-accuracy caveats.

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 the important information, but the closing sentence ('일감몰아주기 검토 자료 PDF에서 표를 뽑는다') merely restates the opening purpose statement and adds no information, weakening an otherwise tight description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the pipeline, the optional-key behavior, the nature of the returned draft, and the human-review requirement, which is sufficient given no output schema. Missing only error/edge-case handling for malformed or non-table PDFs.

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 required parameter at 100% schema description coverage, so the schema already documents pdf_path. The description adds a small mapping ('PDF 파일 경로 → pdf_path') but no format or validity constraints beyond the schema; baseline 4 for a fully-covered single-parameter tool 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 precise pipeline verb chain: PDF table extraction then computation of 지배주주·출자관계·증여의제이익. It clearly separates this from the sibling tunnelling_gift_nts by noting it produces that tool's input, so an agent can tell the two apart.

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 explicitly names the triggering condition (a PDF-formatted 일감몰아주기 검토 자료 whose relation table must be extracted) and the downstream consumer (tunnelling_gift_nts). It does not state when NOT to use it, e.g. when the relation data is already structured, so it falls 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses scope limits that matter for correctness: ⑩항 excluded sales must be entered directly, and ⑭·⑮ are not reflected. It does not discuss permissions, but for a pure calculation tool this is a genuinely informative disclosure.

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 statutory basis and scope caveat before the input/output mapping, which is good structure. However, the closing sentence repeats '일감몰아주기 증여의제이익(상증법 제45조의3)' verbatim from the opening, and the input mapping duplicates the 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?

For a 9-parameter tool with nested objects and no output schema, the description states the return values (증여의제이익, 근거 법조항) and the calculation scope limits. Requirements are clear; only edge-case behavior for the nested people/family/stakes structures is left to 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 description coverage is 100%, so the schema already documents every parameter (including Korean labels and units). The description's Korean→param mapping (e.g., 수혜자 → beneficiary, excluded_sales) largely restates the schema, adding little beyond the required/optional status of excluded_sales.

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 일감몰아주기 증여의제이익 under 상증법 제45조의3, and explicitly names the sibling it differs from (tunnelling_gift_nts for the full NTS formula). An agent can distinguish it from the many other tax-calculation siblings 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?

Has an explicit '언제' section: use this for a simple deemed-gift calculation, with the alternative (tunnelling_gift_nts) named along with the condition that selects it (full 국세청 신고안내 formula). Nothing is left 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 no annotations, the description carries the full disclosure burden, and it does describe the output ('증여의제이익·단계별 계산') and legal grounding (상증법 제45조의3, 시행령 제34조의3). It also flags behavioral detail (unreturned_tax is included in tax), which goes beyond a bare parameter list. It still omits error handling, validation behavior, and treatment of the 8 optional/nested params, so it is not complete.

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 scannable, which helps for a 15-parameter tool. However the opening parenthetical enumerating formula components overlaps the later input list, and the final sentence ('일감몰아주기 증여의제이익 — 국세청 2026 신고안내 산식.') repeats the opening almost verbatim, which is wasted space.

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 15-param, nested-object calculation with no output schema, the description maps all inputs and states what the result contains plus the legal basis. It is broadly sufficient to invoke the tool, though it leaves optional-parameter interactions and edge-case behavior unspecified.

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 description's '입력' block largely restates the schema descriptions verbatim (same ⑫/⑮ markers, same example objects). It adds ordering and the statutory line-item context but no syntax or semantics the schema lacks, so the 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 names a specific computation (일감몰아주기 증여의제이익) computed under the NTS 2026 filing formula, with the statutory components (⑫세후영업이익, ⑬한계보유, ⑭추가 과세제외, ⑮배당공제) enumerated. It is clearly a 'calculate X under official formula' tool. It does not, however, differentiate itself from the nearby siblings tunnelling_gift and tunnelling_from_pdf, so an agent must infer that this is the NTS-formula variant.

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?

A dedicated '언제' clause says to use it when computing 일감몰아주기 증여의제이익 according to the official NTS filing-guide formula. That is an explicit trigger condition. No when-not condition or named alternative is given, so the agent gets no explicit routing between this and tunnelling_gift / tunnelling_from_pdf.

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/closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the applicable statutory rates, the governing legal basis (국세기본법 제47조의3), and what the result contains (penalty amount, applied rate, grounds).

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 rates, then structured as 언제/입력/결과, which makes it easy to scan. The trailing English one-liner partially restates the opening Korean sentence, so there is minor 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 compensates by stating what is returned (penalty, applied rate, legal basis). For a two-parameter read-only calculator this is nearly complete; only edge conditions (e.g., thresholds or caps on the penalty) are 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 the baseline would be 3, but the description adds real disambiguation: it clarifies that additional_tax is the under-reported tax amount (과소신고한 세액) rather than the penalty itself, and that fraud toggles the 10% vs 40% rate — meaning beyond the schema's terse '금액(원)' and '부정행위로 인한 과소신고 여부'.

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 (compute the under-reporting penalty) and quantifies the two regimes (10% general, 40% fraud), so an agent immediately knows what the tool returns. It does not explicitly name or distinguish itself from siblings like late_payment_penalty or invoice_penalty, though the topic is narrow enough to be self-identifying.

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: use it when the actual tax exceeds the reported tax. That is clear context for selection, but no exclusions or named alternatives (e.g., versus other penalty calculators) 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?

The annotations already establish that this is a read-only, idempotent, non-destructive calculation. The description adds useful behavioral context by naming the returned result fields (market total amount, difference, difference ratio, whether denial applies) and the legal basis, which helps the agent understand what the tool produces.

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 uses helpful labels (언제, 입력, 결과) and is front-loaded, but it repeats the unfair act calculation threshold at both the beginning and the end. The duplication costs efficiency, keeping it at an adequate rather than excellent level.

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 description compensates by listing the expected result fields and citing the legal basis. Together with the 100% schema coverage and clear usage condition, an agent has enough context to call the tool correctly, though additional edge-case guidance could improve 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%, and the schema already documents each parameter with Korean labels. The description maps the same inputs (market_price, actual_price, quantity) and units, adding little beyond what the schema provides. A baseline 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 identifies a specific tax calculation: checking whether a related-party transaction falls under the unfair act calculation denial standard. It gives the legal concept and threshold, making the purpose clear without opening the schema. It does not explicitly contrast with any sibling tool, 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?

It explicitly states when to use the tool: when a related-party transaction price differs significantly from market price and you need to check whether it is subject to unfair act calculation denial. No alternatives or when-not-to-use guidance are given, so it is clear but not exhaustive.

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