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

Since annotations are absent, the description carries the transparency burden and does disclose the exact rates (4.5%, 3.545% + long-term care, 0.9%) and notes they are approximate 2026 rates. However, it does not explain the return format, rounding behavior, income ceilings, or the long-term care rate percentage, leaving some behavioral ambiguity.

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 a single, front-loaded sentence containing all essential information—input, rates, scope, and vintage—without any filler. Every clause adds value.

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 simple one-parameter calculator, the description covers the main purpose, input, rates, and approximation basis. However, with no output schema, it should be more explicit about what the tool returns (e.g., total amount vs. itemized breakdown), and it omits the long-term care insurance rate and legal contribution 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%, with the parameter 월급 already described as '세전 월급 (원)' and an exclusive minimum. The description adds that the salary is used to compute the deduction amounts, but it does not materially enrich the parameter semantics beyond what the schema already provides.

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 uses a specific verb ('계산합니다') and clearly identifies the resource as 4대보험, enumerating the exact components and rates. This differentiates it well from sibling calculator tools such as calc_annual_salary_net or calc_severance_pay.

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 states that entering a monthly salary triggers the calculation and clarifies that only the employee burden (근로자 부담분) is computed, which provides clear usage context. It does not explicitly name alternatives or exclusion rules, but the scope is sufficiently clear for this standalone 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?

With no annotations, the description carries the full burden of behavioral disclosure. It honestly states that the calculation uses a 2026 simplified tax table approximation and is not exact per NTS standards, plus the word '추정' signals estimation. This is strong transparency for a calculator, though it does not detail output formatting or edge cases.

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 two sentences, front-loaded with the core purpose, and includes a key limitation (approximation) without unnecessary fluff. Every sentence 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?

Despite no output schema, the description specifies the output as monthly/yearly net amounts and lists the deduction components. It also warns about accuracy limitations. It does not cover the optional 비과세액 parameter, but that is documented in the schema, so the description is sufficiently complete for a simple calculator.

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 does not add parameter-specific details beyond the schema, but it contextualizes how the salary input is used (deductions applied). The schema already explains 연봉 as pre-tax annual salary and 비과세액 as monthly non-taxable income, so the description adds minimal extra value here.

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 clearly states the tool estimates monthly/yearly net salary after deducting 4 major insurances and simplified income/local income tax. The verb '추정합니다' (estimates) and the resource '연봉 실수령액' make the purpose specific and distinct from sibling calculators like calc_4major_insurance or calc_severance_pay.

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 provides clear context: use this tool when you have an annual salary input and want an estimated net amount. It does not explicitly address alternatives, but the title and description make the tool's domain obvious relative to siblings, which cover distinct calculation types (insurance, severance, tax, DSR, FX, housing score).

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. It discloses approximation behavior, the exemption warning triggered by 보유주택수, and the Gumroad license verification requirement. It does not describe the output format or failure behavior, but the disclosed constraints 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 three sentences, front-loaded with the core calculation purpose, and every sentence earns its place: function, optional behavior, license requirement. No redundant or vague phrasing.

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 simple 3-param calculator with no output schema, the description covers the main purpose, input relationships, limitations, and operational requirements. It doesn't specify the return value or edge-case handling, but these are largely implied for a calculator 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, but the description adds extra semantic value: it states the default for 보유주택수 (기본값 1) and explains why the user would input it (to generate a 비과세 warning), going beyond the schema's 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?

The description uses a specific verb (근사 계산합니다) and resource (양도소득세) and clearly scopes it as a simple calculator for real estate transfer gains. It is readily distinguishable from sibling calculators like calc_severance_pay or calc_fx_convert by naming the exact tax type and '간이' mode.

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 provides clear context: this is an approximate, not actual tax advice, and requires a premium license. However, it does not explicitly name alternative tools or say when to prefer another calculator, so it stops short of full when/when-not 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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: real-time Gumroad license verification (KR_FINANCE_LICENSE_KEY). However, it does not mention side effects, output format, or error behavior. For a calculator, this is acceptable but incomplete.

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 two sentences, front-loaded with the core function and inputs, followed by the license requirement. Every sentence earns its place; no wasted words.

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?

Given the tool has 6 parameters and no output schema, the description adequately conveys inputs, outputs (DSR/DTI ratio and limit), and the license constraint. It doesn't explain how the license key is provided or all edge cases, but it covers the essential information for a calculator.

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. The description reiterates input categories (income, existing repayments, new loan terms) but adds no additional semantics beyond the schema. 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 ('계산합니다' - calculates) and resource (DSR·DTI ratio and loan limit), with clear scope (based on income, existing loan repayments, new loan terms). This distinguishes it from sibling tools, which are other financial calculators (insurance, salary, severance, etc.).

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 clearly implies when to use this tool: when DSR/DTI calculations are needed. It provides context for the inputs and mentions the license requirement, but does not explicitly name alternatives or state when not to use it. Since no other sibling handles DSR/DTI, the context is sufficient.

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 provided, the description discloses key behaviors: it optionally calls a free public API (open.er-api.com) for real-time rates and performs real-time Gumroad license verification. This adds significant context beyond the schema, though it doesn't cover all edge cases like API failures.

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 two sentences, front-loaded with a premium tag, and every clause provides necessary information: the conversion behavior, the API fallback, and the license requirement. No filler or 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?

The description is fairly complete for a simple calculator tool: it explains the core mechanics and a prerequisite. It does not describe the output format, but the absence of an output schema and the simplicity of the task make this acceptable.

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?

The schema already describes all four parameters, giving high coverage. The description adds operational meaning by explaining that the '환율' parameter is optional and triggers a real-time API lookup when omitted, which is not apparent from the schema alone.

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 clearly states the tool converts currency, using '환율 변환' and '통화를 변환합니다.' It distinguishes itself from sibling calculator tools by specifying exchange rate conversion, and the premium tag further differentiates it.

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 provides clear context on when to use the tool: it requires a premium license and specifies the behavior when an exchange rate is provided versus omitted. It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough 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?

With no annotations, the description carries the full burden. It discloses the license validation requirement and the scoring formula, which is beyond the basic 'calculate' intention. However, it does not mention error behavior, return format, or whether any data is stored, leaving minor gaps. The license disclosure and formula transparency justify a 4.

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 compact and structured: a bracketed prefix for category, a single clear sentence stating the function and formula, and a final sentence for the license requirement. No unnecessary words or repetition, and essential information 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?

For a simple calculator with no output schema, the description covers all necessary aspects: inputs, scoring formula, and the license prerequisite. It is sufficiently complete for an agent to select and invoke the tool correctly without additional documentation.

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 adds extra semantic value by explaining how each parameter contributes to the total score (무주택기간 up to 32 points, 부양가족 up to 35, 청약통장 up to 17), giving meaningful context beyond the schema's plain descriptions. Thus a 4 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?

The description clearly states the tool calculates housing subscription scores (청약 가점) using the standard scoring table, and specifies the exact point breakdown (무주택기간 32점, 부양가족 35점, 청약통장 17점, 총 84점). It distinguishes itself from sibling tools by being a premium calculator for this specific domain.

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 provides clear context for usage: it is a premium tool requiring Gumroad license validation via KR_FINANCE_LICENSE_KEY. It implies it should be used when a housing subscription score is needed, but it does not explicitly mention alternatives or exclusions. This earns a 4 rather than 5 due to the absence of explicit when-not-to-use 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?

With no annotations provided, the description carries the full burden. It discloses the calculation formula and labels the result as '예상' (estimated), which is helpful. However, it doesn't mention assumptions such as the default 90-day period, rounding, or potential discrepancies from actual legal severance pay calculations.

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 a single, front-loaded sentence that includes the formula and required inputs. It avoids unnecessary words and communicates the essential information efficiently.

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 simple calculator with three well-documented parameters and a numeric output, the description is mostly complete. It provides the formula and inputs, but lacks an explicit disclaimer about legal accuracy or guidance on when to use the optional '최근3개월_일수' parameter, which would make it fully self-contained.

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% with descriptions for all three parameters. The description adds the formula that connects them, but it doesn't add extra syntax or format details beyond what the schema already provides.

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 clearly states the tool's function: calculate estimated severance pay using a specific formula (1-day average wage × 30 days × years of service). It names the exact inputs (근속연수 and 최근 3개월 급여합계) and uses a specific verb (계산), distinguishing it from sibling calculator tools.

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 provides clear context: this is a calculator for severance pay estimation. It doesn't explicitly mention alternatives or when not to use it, but the context is unambiguous given the tool's name and title, and the inclusion of the standard formula makes the use case evident.

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