gift_tax

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

Annotations already declare the operation read-only, idempotent, non-destructive and closed-world, so the safety bar is low. The description goes beyond them by disclosing the complete set of computed line items (과세가액 through 신고세액공제 and 납부할세액) plus '근거', which tells the agent this is a deterministic, audit-trailed calculation rather than a data lookup.

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

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

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

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

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

There is no output schema, and the description partially compensates by listing the result fields, which is the right move. But for an 18-parameter tax engine with 11 undocumented-in-description inputs, an agent lacks guidance on when to set flags like generation_skip/recipient_minor or how credits (other_credits, prior_gift_tax_paid) interact with the computed 세액 — a meaningful gap for a high-parameter tool.

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

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

Schema coverage is 100%, so the baseline is 3, and the description's 한글→parameter mapping (증여일→gift_date, 부담부증여 인수채무→assumed_debt, etc.) is genuinely useful for natural-language translation. However it maps only 7 of 18 parameters and is silent on the ones most likely to be mis-specified — generation_skip, recipient_minor, share_appraisal_fee/count, excluded, nontaxable, other_credits.

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

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

The first sentence names a specific verb (계산/산출) and enumerates the exact outputs (과세가액·공제·과세표준·산출세액·납부할세액), making it immediately distinguishable from siblings like inheritance_tax or inheritance_gift_valuation. The final line restates the scope compactly as gift-tax computation, so an agent knows precisely what domain this covers.

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

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

'언제: 증여세 신고·계산 시' gives a use context but no exclusions and names no alternatives, even though the sibling list contains adjacent tools (inheritance_tax, inheritance_gift_valuation, tunnelling_gift) that an agent could plausibly confuse. The boundary between 'compute the tax' and 'value the gifted asset' is implied by the result list rather than stated.

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