tax.kr_eitc

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

Annotations only declare read-only/idempotent/closed-world; the description goes well beyond by disclosing the reduction rules actually applied (재산 1.7억원 이상 50%, 기한 후 95%, 최소지급액) and that no rounding occurs because the 표 is in 천원 단위. That is the kind of calculation behavior an agent cannot infer from structured fields.

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

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

Dense but front-loaded: purpose and unit conventions first, then computation rules, then exclusions/misuse. Every clause contributes (legal basis, amount formatting, reduction rules, rounding note), though the sentence length makes it hard to scan.

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-param, rules-heavy calculator with an output schema, the description supplies the eligibility judgment logic, statutory basis, reduction percentages, and boundary exclusions. Gaps are the undocumented as_of and include_proposed parameters; return values needn't be explained since an output schema exists.

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

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

Schema coverage is 0%, so the description must carry the burden and largely does: it defines year as 귀속연도, formats as 원 단위 숫자 문자열, enumerates household_type values, and explains what business_income (업종별 조정률), religious_income, property_total, and the spouse_* fields mean. It omits as_of and include_proposed, so not fully compensating for 13 params.

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

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

States a specific verb+resource ('한국 근로장려금 … 산정') with the governing statute (§100의3/§100의5/§100의7). No sibling computes EITC, and the scope is unambiguous from the first clause.

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 lists what it does NOT judge (자녀장려금, 반기 신청, 체납 충당, 국적·부양자녀·전문직 요건) and flags a concrete misuse case (passing net-of-expense business income). Clear when-not guidance, though it doesn't route to a named alternative tool.

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