가지급금 인정이자

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 fully covered. The description adds domain behavior — it is a pure computation that returns a threshold judgment, not a lookup — but says nothing about return shape, rounding/unit conventions, or how the 5% vs 3억원 branch is resolved. Useful context, not rich 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?

One sentence, zero filler, computation and judgment front-loaded in that order. It is dense enough that the two distinct operations (calculate, then judge) run together, but nothing is wasted and no restatement of the title appears.

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 closed-world pure-computation tool with no output schema, the description covers what goes in (balance segments, actual interest received) and what comes out (적수, 인정이자, a threshold verdict). Gaps are minor: output field naming and how the two threshold criteria (5% ratio vs 3억원 absolute) are combined are left implicit.

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

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

Schema coverage is 100%, so baseline is 3. The description earns one step above baseline by explaining the relationship between parameters: segments feed the 적수 calculation and receivedInterest is the comparison base for the threshold judgment, which is meaning the schema's per-field descriptions do not convey. ratePct, rateKind, and yearDays are still left entirely to 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 pair: computing 적수 (day-weighted balance) and 인정이자 from 특수관계인 가지급금 balance segments, then judging the 부당행위계산 threshold (5% or 3억원). No sibling tool (find_statute, estimate_tax, estimate_penalty, entertainment_limit, etc.) covers this computation, so the agent can distinguish it without opening the schema. It stops short of explicitly naming an alternative for the same task.

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

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

The description implies the usage context (특수관계인 loans, comparing computed vs. actual interest) but never states when to pick this tool over e.g. estimate_tax or when it does not apply. No prerequisites, no exclusions, no mention of what data must be gathered first (balance change history) before calling.

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