payroll.kr_salary

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

Annotations already declare readOnly/idempotent/closed-world, and the description goes well beyond them by disclosing the exact payroll formula surface: taxable pay after the non-taxable meal allowance cap, national pension floor and ceiling, and precise rounding rules (health and long-term care truncated below 10 won, other premiums and local income tax below 1 won). It stops short of describing failure modes or validation behavior for out-of-range inputs.

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 sentences, all information-dense: the objective first, the computation and rounding rules second, and the policy-dating plus the misuse warning last. No filler and the critical scope constraint is front-loaded.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. What remains missing is meaning for three of the seven inputs (dependents, children 8–20, include_proposed), which is a real gap given zero schema description coverage.

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

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

With 0% schema description coverage across 7 parameters, the description must carry all parameter meaning, and it only partly does: monthly_salary (pre-tax, in won, as a string), as_of (effective-date policy selection), and meal_allowance (비과세 식대 한도) are addressed. children_8_20, num_dependents (which drives the 간이세액표 income tax) and include_proposed are never explained anywhere.

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 and resource — converting a pre-tax monthly salary (세전 월급) into a Korean net salary (실수령액) — and enumerates the exact deductions computed (national pension within upper/lower bounds, health insurance, long-term care, employment insurance, simple tax table income tax, 10% local income tax). It does not explicitly differentiate itself from the inverse sibling payroll.kr_gross_from_net or payroll.hourly_to_monthly_net, which keeps it below 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 gives one explicit negative constraint — don't put an annual salary in the monthly salary slot (연봉을 월급 자리에 넣으면 안 된다) — and explains that as_of selects the policy effective date. However, it never states when to choose this tool over kr_gross_from_net (net→gross) or the hourly/severance siblings, leaving routing to inference.

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