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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description adds real substance beyond them: empty entries are treated as zero, amounts are Decimal strings, and the account field is inert — all behaviors an agent would otherwise have to guess.

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?

Front-loaded with the purpose, then input shape, then return values, then the scope caveat. Short Korean sentences with no filler; the caveat is placed last where it reads as a qualifier rather than burying the main point.

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 tool is a single-parameter validator with an output schema, so return-value documentation is not strictly required, and the description supplies it anyway plus input semantics and scope limits. Nothing an agent needs to invoke it correctly is missing.

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% and the schema only says 'array of objects', so the description carries the burden and largely meets it: it specifies the {account, debit, credit} item shape, the Decimal-string amount format, and the zero-default for empty values. It does not address optionality of debit/credit or what additional keys do, leaving a modest gap.

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 and resource: validating that the debit total and credit total of a journal-entry list match. It also scopes itself out of per-account balance checking, which separates it from the other accounting.* tools such as accounting.income_statement and accounting.ratios.

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 closing sentence gives an explicit when-not-to-use: the account field is ignored in the totals, so it cannot verify per-account balances. That is strong exclusion guidance, but no named alternative is offered for the per-account case.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description adds real substance: 50-digit Decimal internal precision, HALF_EVEN rounding to `decimals` (default 4), and the important caveat that the result is a fractional sales quantity rather than being rounded up to whole units. It does not describe error behavior when unit_price <= unit_variable_cost, which is the one gap.

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?

Four sentences, formula front-loaded, then validity constraints, then numeric precision/rounding, then the output-semantics caveat. Every sentence carries information an agent needs; nothing is redundant with the schema or annotations.

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?

With an output schema present and annotations covering safety, the description need only cover computation semantics — precision, rounding, and the non-integer result — all of which it does. The only missing piece is failure behavior for an invalid denominator, a minor omission for a pure calculation 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 description coverage is 0%, so the description must carry the load, and it largely does: it specifies that amounts are finite Decimal strings, gives per-parameter validity constraints for all three required inputs, and documents `decimals` (default 4) plus its rounding mode. It stops short of naming each parameter individually, which is why it is not a 5.

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 opens with the exact formula '손익분기 판매량 = fixed_costs / (unit_price - unit_variable_cost)', which names both the verb (compute break-even sales volume) and the precise resource/definition. No sibling in the accounting.* family could be confused with this one after reading the formula.

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?

Domain context and input preconditions (fixed_costs and unit_variable_cost >= 0, unit_price > unit_variable_cost) are given, which implicitly tells the agent when the call is valid. However, there is no explicit guidance on when to use this versus alternatives (e.g. core.calc or core.solve_for), and no statement about what happens when preconditions fail.

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?

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: no rounding occurs, amounts are Decimal strings, and the sign convention (increases as positive) warns of a silent error mode if violated.

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?

Four sentences ordered as purpose, formula, numeric format, then sign convention. The critical sign warning is placed last but is stated in one tight sentence, and no sentence restates the tool name or title 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?

An output schema exists, so return-value explanation is unnecessary, and the description supplies the formula, precision rule, and sign semantics needed for an 8-parameter computation tool. The one omission is any mention of change_in_other_wc, leaving that parameter to be inferred from schema defaults.

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 parameter meaning, and it largely does: it enumerates net income, depreciation, amortization, other non-cash items, receivables, inventory, and payables, and defines the sign direction for each change term. Only change_in_other_wc is left unaddressed, a minor gap given how much is otherwise covered.

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 opens with a specific verb and resource ('간접법 영업활동현금흐름(CFO)을 계산한다') and pins down the method (indirect method), which distinguishes it from siblings like accounting.income_statement or accounting.balance. An agent can immediately tell this is a single-purpose calculation tool.

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 phrase '간접법' implicitly scopes usage to indirect-method CFO computation, but the description never states when to choose this over building the same figure via accounting.income_statement or accounting.balance, nor does it name any prerequisites or exclusions. Usage is inferable but not stated.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description goes well beyond them: it discloses the salvage floor clamp, the zero-depreciation behavior once the floor is reached, the rounding mode applied, and that the rate is taken literally rather than back-derived from life_years. That last clause pre-empts a realistic caller misconception. It does not describe output shape, but an output schema exists.

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?

Four dense sentences with no filler, front-loaded with the purpose and formula before the edge-case rules. Every sentence contributes a constraint or default; it is compact for the amount of semantics it delivers.

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 six-parameter read-only calculator with an output schema, this is nearly complete: calculation rule, clamping behavior, precision and rounding defaults, and the rate-interpretation caveat are all present. The remaining gap is the meaning of life_years, which determines how many periods the schedule emits.

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 0%, so the description carries the full burden and only partly meets it. It fully specifies rate (Decimal string, strictly between 0 and 1), decimals (default 0) and rounding (default HALF_EVEN), and implies salvage via the floor rule, but cost and especially life_years — the schedule horizon — are never explained.

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 opens with a specific verb and resource in the declining-balance method and even states the governing formula (beginning book value x rate), which distinguishes it in substance from depreciation_straight_line and depreciation_units_of_production. It stops short of naming those siblings explicitly, so the routing is inferred from the method name rather than stated.

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?

No explicit when-to-use or when-not-to-use guidance and no named alternative among the sibling depreciation tools. Usage is only implied by the method stated in the first sentence, which is adequate but leaves the agent to decide between declining-balance, straight-line and units-of-production on its own.

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?

Annotations only cover the safety profile (readOnly, idempotent, closed-world); the description adds substantive behavior: the per-year depreciation is capped at the remaining basis, and the final year amortizes the exact residual regardless of decimal places. Those are non-obvious edge-case rules that materially change results.

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 front-loaded paragraph: verb and formula first, then input constraints, then rounding and terminal-year rules, then an explicit exclusion. No sentence is redundant, and the most decision-relevant content leads.

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?

With an output schema present, the return shape needn't be explained, and the description covers inputs, constraints, rounding policy, and the final-year edge case. The one remaining hole is the accepted value set for `rounding`, which neither the schema nor the prose supplies.

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 do the work — and it does: life_years must be an integer >= 1, cost and salvage must be finite non-negative Decimal strings with cost >= salvage, decimals defaults to 0 and rounding to HALF_EVEN. The only gap is that the permitted values for the string parameter `rounding` are never enumerated (no enum in schema either), so an agent must guess valid tokens beyond the default.

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 the specific operation (정액법 감가상각, straight-line depreciation) and gives the exact formula, which immediately distinguishes it from the sibling declining-balance and units-of-production calculators. It also explicitly scopes out monthly proration and mid-year acquisition, closing off ambiguity an agent might otherwise have.

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 clearly states the applicable case (straight-line, full-year periods) and explicitly says when NOT to use it ('월할이나 기중 취득 안분은 지원하지 않는다'). It doesn't name the sibling tools by name, but the method-specific framing makes the alternative choice obvious.

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?

Annotations already cover read-only, idempotent, and closed-world behavior, so the description adds the non-obvious edge case: cumulative production exceeding total_units does not error and book value floors at salvage. It also discloses the rounding/scale post-processing, which is genuine behavioral context beyond the annotations.

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?

Four dense sentences, front-loaded with the formula and followed by constraints and edge-case behavior; nothing is filler. It could be slightly tighter by merging the rounding sentence into the parameter notes.

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?

With an output schema present, return values need not be described, and the description covers formula, input constraints, rounding, and overflow behavior. Only the enumeration of accepted rounding modes is missing for a fully self-contained definition.

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 0%, so the description carries the burden and largely succeeds: total_units must be an integer >= 1, period_units is a per-period integer list, cost/salvage are Decimal strings, and decimals/rounding defaults are restated. The only gap is that valid rounding mode values beyond the HALF_EVEN default are not enumerated.

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 (계산한다) and resource (생산량비례법 감가상각 스케줄) and then gives the exact formula, which uniquely distinguishes it from the straight-line and declining-balance siblings without needing to name them.

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 formula implies when the method applies, but there is no explicit statement about when to choose this over accounting.depreciation_straight_line or accounting.depreciation_declining_balance, nor any prerequisites. Usage is inferable but not guided.

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?

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description still adds real behavioral context beyond that — inputs are Decimal strings, revenue/total assets/total equity must be non-zero, rounding is HALF_EVEN at `decimals` (default 6), and negative equity is deliberately not rejected so the caller must validate sign. That is meaningful disclosure for a calculation tool.

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 compact sentences, front-loaded with the formula, then constraints, then rounding/sign caveats. Dense but every clause carries information; only the sign-check remark is somewhat terse in 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?

With an output schema present, return values need not be described, and the description covers input format, validity constraints, and numeric precision. The remaining gap is competitive positioning against accounting.dupont_5, which would help an agent choose correctly between the two decompositions.

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 0%, so the description must compensate, and it largely does: it establishes that the monetary parameters are Decimal strings, that three of the four required inputs are non-zero-constrained (implicitly leaving net_income able to be zero/negative), and that `decimals` defaults to 6 with HALF_EVEN rounding. It does not explain the unit/currency convention or the exact meaning of total_equity vs. average equity.

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 and resource ('DuPont 3단계 분해로 ROE = ...를 계산한다') and spells out the exact formula, so the agent knows precisely what is computed. The '3단계' qualifier implicitly distinguishes it from accounting.dupont_5, but the sibling is never named or contrasted explicitly.

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 formula and the ROE context imply when to use it (ROE decomposition into three components), but there is no explicit when-to-use/when-not guidance. Critically, the obvious alternative accounting.dupont_5 (five-step decomposition) is never mentioned, so the agent must infer the choice from the tool name alone.

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?

Annotations already guarantee read-only, idempotent, closed-world behavior, and the description adds genuinely new traits: all amounts must be passed as Decimal strings, five specific inputs must be non-zero, and results are HALF_EVEN-rounded to 6 places by default. It stops short of stating units or an error shape, but that is a minor residual gap.

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 dense sentences: formula first, then validity constraints, then precision rules — front-loaded and free of filler. Nothing is redundant, though the formula is compact enough that it requires careful reading.

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 7-parameter pure-calculation tool with an output schema already present, the description covers inputs, domain constraints, and rounding, which is essentially everything an agent needs. The only omission is whether ROE is returned as a ratio or a percentage.

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 0%, so the description carries the whole burden, and it does: it maps each argument to its formula role (net_income, pretax_income, ebit, revenue, total_assets, total_equity), declares the string/Decimal format, and documents the decimals default and rounding mode. Only the exact meaning of total_equity in the leverage term is left implicit.

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 (compute) and a precisely defined resource (5-stage DuPont decomposition of ROE), and spells out the exact factor chain from net income down to financial leverage. That formula alone separates it from accounting.dupont_3 and accounting.ratios without opening any schema.

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 never says when to reach for this instead of dupont_3 or accounting.ratios; the only conditional content is a data-validity constraint (denominators must be non-zero), not a routing rule. An agent must infer the choice from the factor count in the name.

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?

Beyond the read-only and idempotent annotations, the description discloses important calculation behavior: 50-digit Decimal precision, no separate rounding of profit figures, 6-decimal HALF_EVEN margin rounding, zero-revenue margin behavior, and out-of-range errors. These details materially help an agent predict results and failure modes.

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 front-loaded with the purpose, then proceeds through input format, precision, rounding, error behavior, and sign convention. It is compact and every sentence adds operational 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?

For a 7-parameter financial calculation with an output schema, the description covers the key computational and input constraints needed to invoke it correctly. The main remaining gap is that the description does not fully clarify how each of the optional income and expense parameters is signed or categorized.

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, the description usefully adds that all amounts are finite Decimal strings, revenue and cost of sales must be non-negative, and expense items are entered as positive numbers. It still does not explain the role or sign conventions for every parameter, especially other_income versus other_expenses, interest_expense, and tax_expense.

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 a specific resource and operation: a multi-step income statement calculating gross profit, operating profit, pre-tax profit, net profit, and margins. It is distinguishable from balance-sheet or cash-flow siblings by resource, but it does not explicitly contrast itself with related profit tools such as accounting.break_even or accounting.ratios.

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?

Usage is implied by the resource name and the listed income-statement stages, so an agent can infer when this tool is appropriate. However, there is no explicit when-to-use guidance, no exclusions, and no named alternative such as accounting.break_even for break-even analysis.

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?

Annotations already mark it read-only, idempotent, and closed-world, so the low bar is met, yet the description adds substantial beyond-schema behavior: 50-digit internal precision, HALF_EVEN rounding to decimals, error on zero denominators, and that results are multiples not percentages. These are genuinely useful invocation-shaping facts.

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?

Front-loaded with the eight ratios then the precision/rounding/error details; every sentence carries real information. It is dense and the error/percentage clauses run together, but nothing is wasted.

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 an output schema exists (return values need not be spelled out) and the tool is read-only, the description covers everything an agent needs: what it computes, precision, rounding, units, and failure conditions.

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 compensate, and it does well: it clarifies decimals (non-negative integer, default 4, out-of-range is an input error), defines amounts as finite Decimal strings, and specifies that four specific denominators erroring is the failure mode. It stops short of documenting each amount parameter's sign/validity individually.

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 action (calculate 8 ratios at once) and explicitly enumerates all eight ratios, plus names the input sources (balance sheet and income statement). An agent immediately knows what this produces and from what inputs.

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 'at once' framing implies this is the batch ratio tool, but there is no explicit guidance on when to prefer it over siblings like dupont_3, dupont_5, or finance.roi, nor any 'when not to use' exclusions. Usage is only implied.

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?

Annotations already declare readOnly/idempotent/closed-world, so the description's job is to add computation semantics — which it does: rounding to integer places, default HALF_EVEN, and Decimal-string amounts. It does not state the accepted rounding-mode vocabulary or how rate bounds/negative inputs are handled, so it stops just short of full disclosure.

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?

Four tight sentences, front-loaded with the computation before the disambiguation and format notes; no filler. Density is high but each sentence carries distinct information (formula, rounding default contrast, Decimal format, reverse tool).

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?

With an output schema present, return values need no explanation, and the description covers the formula, defaults, and the reverse-direction alternative. Only the rounding-mode vocabulary and input-format edge cases are left unstated for a tool whose parameters have zero schema descriptions.

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 load, and it largely does: it identifies net as the supply amount (required), gives rate's default 0.1, and gives rounding's default HALF_EVEN plus the fact that rounding targets integer places. The gap is that the allowed rounding enum values and the expected rate string format (fraction vs percent) are never enumerated.

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 and resource (add VAT to the supply amount to get the gross amount) and names the exact formula (VAT = net × rate). It also names the sibling it is not: vat_extract, which goes the other direction.

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 routes the agent: use vat_add when going net→gross, and use vat_extract when going gross→net. It further disambiguates the two by flagging that their default rounding modes differ (HALF_EVEN vs DOWN), which is exactly the kind of detail that prevents a wrong sibling choice.

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?

Goes beyond the readOnly/idempotent annotations by giving the exact formula, the default truncation behavior of rounding (DOWN/절사), the default rate, and the Decimal-string input convention. Only the full set of accepted rounding values is left implicit.

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, each carrying distinct load: purpose, computation/rounding rule, and sibling routing. The alternative is placed last, after the core semantics, which is the right ordering.

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 not be explained, and the description still spells out what the two outputs are and how they are computed. Nothing an agent needs to invoke this correctly is missing.

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 0%, yet the description covers all three parameters: gross is defined as the VAT-inclusive amount, rate's default of 0.1, and rounding's default of DOWN with the meaning of truncation to integer. This compensates fully for the empty schema descriptions, with only the alternate rounding values unspecified.

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 (역산/extract) and resource (gross → supply value + VAT), and immediately disambiguates from the sibling that performs the opposite direction. An agent can select it without opening the schema.

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 names vat_add as the tool for the forward calculation (공급가액 → 공급대가), making the split between the two tools unambiguous. That is a direct when-to-use-this-vs-alternative statement.

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?

Annotations already cover safety (readOnlyHint, idempotentHint, closed-world), so the description earns credit for adding domain behavior: computation to 50 significant digits and no separate rounding step. It does not mention limits on operand count or error behavior for malformed input, keeping it short of a 5.

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?

Four short sentences, front-loaded with precision and return form, then constraints, then the usage directive. Every sentence carries information, though the trace_level sentence is slightly abrupt and could tie more clearly to output behavior.

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-value detail is not required from the description, and the description still names the result string and precision. For a two-parameter arithmetic primitive with read-only annotations, nothing essential is missing.

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 0%, so the description must carry the load, and it largely does: operands are described as a list of numeric strings without commas, units, or spaces, and trace_level is given its three values with 'summary' marked as the default. It stops short of stating what full vs none actually change in the output, so not a 5.

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 and resource ('Decimal 정밀 덧셈') and adds the output form ('합을 result 문자열로 반환'). An agent can distinguish it from core.sub/core.mul/core.div purely from the name plus this sentence.

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 directs the agent to use the tool rather than doing mental arithmetic ('합계를 직접 암산하지 말고 이 도구로 구한다'), which is real usage guidance. It does not name alternatives such as core.calc or core.batch, so the sibling-routing guidance is implied rather than stated.

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?

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, and the description usefully confirms and explains that only read-only tools are executed. It adds result ordering (input id order) and per-item status values (ok, error, timeout), but says nothing about how max_workers or deterministic change execution behavior, or what happens when some items fail.

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?

Four dense sentences, front-loaded with purpose, then constraints, then the sibling redirect. No filler, though the timeout sentence packs both the status model and two timeout params into a way that makes the two undocumented params easy to miss.

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?

Return shape need not be explained since an output schema exists, yet the description still covers ordering and status codes. For a 5-param orchestration tool, the remaining gap is the semantics of max_workers and deterministic, which no structured field covers.

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 0% and the items property is an untyped object with additionalProperties:true, so the description's breakdown (id, tool, args) is essential and well beyond the schema. It also explains item_timeout_s and batch_timeout_s, but leaves max_workers and deterministic completely undocumented.

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 and resource ("서로 독립인 도구 호출 N개를 병렬 실행한다") and immediately names the semantic boundary versus core.pipeline (independent vs. dependent items). An agent can distinguish batch from pipeline without opening either schema.

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 routes the agent: use core.pipeline when later inputs depend on earlier results, implying core.batch is for independent calls. It also gives hard constraints (max 500 items, unique ids, read-only tools only) that act as when-not conditions.

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 readOnlyHint/idempotentHint already declaring the safety profile, the description adds genuine behavior: the accepted operator/function/constant set, the hard rejection of comparisons and attribute access, and that variables must be Decimal strings. It omits any mention of trace_level, whose effect on the response is left unexplained.

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?

Four dense sentences, each carrying distinct information (capability, input types, output format, exclusions), with the core purpose front-loaded. No filler.

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?

Output schema exists, so return values need no prose; the description still usefully states the result is a precision-digit decimal string. The only gap is trace_level, an unannotated parameter with no explanation anywhere.

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 0%, so the description must compensate; it does so for three of four parameters — expression (allowed operators, functions, constants), variables (Decimal strings only), and precision (default 50, digits of the decimal-string result). trace_level receives no semantics at all.

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?

Names the mechanism (AST-based safe expression evaluator) and the resource (arithmetic expressions), which cleanly separates it from core.add/core.mul/core.div and from the domain-specific formulas in finance.*/tax.*. The added note that comparisons, conditionals and attribute access are refused further pins down the boundary.

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 states what is rejected (comparisons, conditional expressions, attribute access) and routes the agent elsewhere for tax/financial formulas ('use the dedicated tools'). That is both a when-not and an alternative pointer, so nothing is left to inference.

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?

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), but the description adds real behavior: numeric fields yield delta_vs_baseline, non-numeric fields yield null, and scenarios are capped at 50 with unique-name constraints. That is substantive context beyond the 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?

The core comparison mechanic is front-loaded, then field semantics, then the 50-scenario cap. It is dense but every sentence adds information; no filler.

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-value shape is covered elsewhere, and the description still explains delta_vs_baseline and null-for-non-numeric semantics. Given nested scenario objects and four required parameters, the definition is nearly complete, with only the per-scenario object structure 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 description coverage is 0%, so the description has to carry parameter meaning, and it does: tool is a read-only tool, base_arguments is the baseline run, scenarios are per-run overrides (max 50, unique names), and fields is a list of result paths with a concrete example (tax, breakdown.0.rate). The internal shape of each scenario object remains undocumented, keeping it from a 5.

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 (compare) and mechanism: it runs a read-only tool once with base_arguments as the baseline and again per scenario with overridden arguments. That is clearly distinguishable from sibling compute tools like core.add or core.calc, which return single values.

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 tells the agent this only applies to 'read-only' tools and frames the use case as scenario comparison, which implicitly excludes mutations. It does not name an explicit alternative or a when-not condition, so it stops short of a 5.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the b=0 error path, the 50-significant-digit precision ceiling, and the truncation (not rounding) behavior when the division is not exact. Missing is anything about output shape or the role of trace_level, but the core behavioral risks are covered.

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?

Four tight sentences, front-loaded with the operation and then the input-format constraint, error condition, and precision limit in order of importance. Every sentence adds information; only the final rounding note is slightly tangential but still useful.

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?

With an output schema present, the description need not explain return values, and it supplies the precision semantics an agent needs to interpret the result. The unaddressed trace_level parameter is the one real gap for a three-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 description coverage is 0%, so the description carries the full burden. It compensates well for a and b (numeric strings, no commas/units/spaces), but the third parameter trace_level is never mentioned anywhere, leaving one parameter completely undocumented.

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 ('Decimal 정밀 나눗셈 a / b') and immediately scopes it as arbitrary-precision division rather than the integer/normal arithmetic done by siblings like core.add or core.mul. An agent can tell exactly what operation this performs without opening the schema.

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?

Provides clear operational context: the inputs must be bare numeric strings, and if an integer quotient or won-unit truncation is wanted the result must be rounded separately. It does not name sibling tools such as core.calc or core.mul or state explicit exclusions, so it falls short of a 5.

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?

Annotations already declare readOnly/idempotent/closed-world, and the description still adds meaningful behavior: numbers are passed through verbatim, the prose only narrates the trace, and long values are truncated at 300 characters with the original preserved in `result`. It omits failure behavior (invalid tool name, non-read-only tool rejected) and any cost/latency expectations.

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?

Four sentences, front-loaded with the mode and the operation, then output shape, then fidelity guarantee, then truncation. Slight redundancy between the fidelity sentence and the truncation sentence, but nothing is padding.

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, yet the description still usefully enumerates the returned fields, and it discloses the read-only restriction and truncation rule an agent needs to interpret results. Missing only edge-case handling (invalid/nested tool, error surfacing) for a meta-tool with a free-form nested `arguments` object.

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 load and largely does: `tool` is the read-only tool to run, `arguments` is that tool's argument object, and `lang` selects ko or en for the prose. It does not clarify the tool-name format (dotted identifiers like accounting.balance) or whether `arguments` must match the target tool's 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?

States a specific action: execute a read-only tool with `arguments` and return a plain-text narration of the formula, inputs, steps, result, applied policy, and statutory basis. The 'explanation mode' framing makes it distinguishable from plain calculation, but it never names the obvious sibling (core.calc) as the non-explaining alternative.

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 does constrain usage to read-only tools, which is a real when-not-to-use signal for mutating siblings. However there is no explicit guidance on when an agent should prefer core.explain over core.calc or over calling the target tool directly, so the routing decision is left to inference.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, closed-world), so the description adds genuine value by disclosing the precision contract: products beyond 50 significant digits are rounded to that many digits and no other rounding occurs. This is exactly the kind of numeric-semantics detail annotations cannot express. It stops short of saying anything about failure behavior for malformed input.

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?

Four short sentences, each carrying distinct information: purpose, input format, precision policy, and exclusion. Purpose is front-loaded and nothing is redundant.

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?

With an output schema present, the description need not detail return values, and it still notes the result is returned as a string. Input format and rounding policy are fully covered. The only gap is the unexplained trace_level parameter, which is minor for an optional diagnostic field.

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 carries the full burden and does well on the required 'operands' parameter, spelling out that it is a list of numeric strings with no commas, units, or spaces. The optional 'trace_level' parameter is never mentioned, leaving one of two parameters entirely undocumented in both schema and description.

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 operation on a specific resource ('Decimal 정밀 곱셈') and names the return type, making it trivially distinguishable from core.add, core.sub, and core.div. An agent can tell what this tool does without opening the schema.

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 explicitly routes the agent away from this tool for tax and interest calculations ('세금이나 이자 계산에는 전용 도구를 쓴다'), which is a real exclusion against siblings like accounting.vat_add or finance.*. It does not, however, state when to prefer this over core.calc or the other core arithmetic tools, so routing among the core.* family is left to inference.

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?

Goes well beyond the annotations: hard limits (최대 50단계, 깊이 10), failure propagation semantics ('실패한 단계의 하류는 skipped'), and the resume mechanism are all disclosed, none of which readOnlyHint/idempotentHint convey. It does not, however, explain how the two timeout parameters interact or what the response contains on a partial failure, so it stops short of full behavioral coverage.

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?

Four dense sentences, each adding distinct information: purpose, step schema and limits, reference syntax, failure/resume behavior, then the sibling hand-off. The differentiating constraint and the alternative are both front-loaded with no filler.

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 nested-DAG orchestrator with a published output schema, the description covers the mechanics, limits, failure semantics, and the alternative tool, so an agent can construct a valid call. The omission of the timeout parameters' semantics is the remaining gap, but it is bounded since both have sane schema defaults.

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 load — and it does for the only required parameter, spelling out the {id, tool, args} shape and the ${단계id.result.필드} interpolation syntax that the schema does not express at all. step_timeout_s and pipeline_timeout_s (defaults 2/30) are never mentioned, leaving two of three parameters documented only by a bare title.

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 ('의존 관계(DAG)를 가진 도구 호출을 순서대로 실행') and immediately scopes it against the sibling that does the opposite ('서로 독립인 호출은 core.batch 를 쓴다'). An agent can distinguish core.pipeline from core.batch, core.add, and core.pipeline_resume without opening any schema.

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 an explicit selection rule — use this tool when steps depend on each other, use core.batch when they are independent — and names the recovery path (pipeline_id 로 재개) that pairs with core.pipeline_resume. Both the when and the when-not are stated rather than inferred.

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?

Adds substantial behavior beyond the annotations: successful steps preceding from_step are reused rather than recomputed, execution records expire after roughly 10 minutes and then error out, which explains the idempotentHint. The readOnlyHint is consistent since this is a pure computation pipeline with no mutation of user data described.

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?

Four short, front-loaded sentences with no filler, leading with the action and scope before the caveats. Slight room to tighten, but every sentence carries 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?

Covers lifetime/expiry, reuse semantics, and the alternative path; an output schema exists so return shape needn't be described. The remaining gap is the format and validation of from_step for a two-required-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 0% (only bare titles), so the description must carry the burden. It gives the meaning of both parameters (pipeline_id = identifier of a prior run, from_step = restart boundary) but never specifies the expected format of from_step as a string, such as a step name versus an index, nor valid values.

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 and resource: re-executes a previous core.pipeline run identified by pipeline_id, beginning at from_step. It also distinguishes itself from the sibling core.pipeline by explaining that a fresh call is how you recompute with new inputs.

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 tells the agent when to use it (resuming an existing execution) and when not to (use core.pipeline instead when inputs change), naming the alternative tool directly. No inference is required to route between the two.

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?

Beyond the annotations, the description discloses the bisection/Decimal method, the sign-change requirement, nearest-solution and residual return behavior, convergence tolerance defaults, and the max_iter cap of 200. It does not describe what happens when the sign condition fails, but most behavioral traits are covered.

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, front-loads the core purpose, then adds an example, preconditions, and convergence details without filler. Every sentence contributes useful 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?

For a complex 10-parameter tool with a nested arguments object, the description covers the main workflow and convergence behavior well enough to start, and the output schema covers return values. It remains incomplete because the arguments object, integer flag, and error behavior are not described.

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, the description must carry parameter meaning, and it does explain tool, variable, target_field, target, lower/upper, tolerance, and max_iter. It leaves important parameters like arguments and integer unexplained, so it is only partially compensating for the schema gap.

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 inverse-solving purpose: find a numeric-string variable via Decimal bisection so that another read-only tool's target_field equals target. It is clear and concrete, with an example, but it does not explicitly distinguish itself from nearby alternatives such as symbolic.solve or core.calc.

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 when to use it through the inverse-calculation framing and the gross-from-net salary example, and it states key preconditions such as the target tool being read-only and the interval endpoints needing opposite signs. However, it does not explicitly name alternatives or say when not to use this tool.

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?

Goes beyond the annotations by disclosing the 50-significant-digit working precision, the absence of rounding, and the input-string normalization requirement — real behavioral constraints an agent cannot infer from readOnlyHint/idempotentHint. It does not describe error behavior (e.g., what happens on malformed input), which keeps it short of a 5.

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?

Four short sentences, purpose front-loaded, with the operand-order caveat placed last where it is most actionable. The clause noting the return is a 'result' string is largely redundant given an output schema exists.

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?

Annotations cover the safety profile and an output schema covers the return value, so the description only needs to add precision, rounding, and input-format constraints — which it does. The only real gap is the undocumented trace_level parameter.

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 carries the burden; it explains a and b substantively (digit strings without commas/units/spaces) and clarifies directionality (a minus b). The third parameter, trace_level, is never mentioned, leaving one parameter undocumented in both schema and description.

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 and resource ('Decimal 정밀 뺄셈 a - b') and pins the operand order, which cleanly separates it from siblings core.add, core.mul and core.div. An agent can identify the operation without opening the schema.

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?

Offers operational guidance in the form of input-format rules (no commas, units, or spaces) and an explicit warning about operand order. However, it never names an alternative (e.g., core.add, core.calc) or states when not to use this tool, so routing guidance is only implied.

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?

Annotations already declare a safe, idempotent, closed-world read, so the description focuses on value-adds: the hard input ceiling, the failure mode above it, and the method (trial division) that explains the performance bound. It does not mention cost or response format beyond the key names, keeping it just below full marks.

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?

Four compact sentences ordered from purpose to input constraint to return keys to the sibling distinction, with no filler. Slightly dense but every sentence contributes information an agent needs.

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?

Even though an output schema exists, the description still names the result keys, and it covers the domain limit and error condition that the schema cannot express. Nothing essential is missing for a correct call, though a note on expected failure behavior for non-numeric input would round it out.

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% for the single parameter, so the description carries the burden and does so: it specifies that n is a string (not a number), the inclusive bounds 1 to 10^14, and the algorithmic reason for that bound. Only minor detail, such as handling of leading zeros or whitespace, is left unspecified.

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 computation with its formula (λ(n) = lcm(λ(p^k))), so there is no ambiguity about the resource involved. It also explicitly distinguishes itself from the nearest sibling, crypto.euler_totient, by noting that λ(n) divides φ(n) and that the two must not be confused.

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 concrete applicability constraints — n must be an integer string in [1, 10^14] and is factored by trial division — and warns that exceeding the range is an error. The φ-vs-λ warning functions as a when-not-to-use note, though it stops short of naming the alternative tool by name.

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?

The annotations already establish readOnly, idempotent, closed-world behavior, so the transparency bar is lower. The description adds meaningful behavioral detail beyond them: inputs must be equal-length string lists, moduli must be positive and pairwise coprime, non-coprime inputs are rejected, and the result is normalized into [0, modulus). That is a solid failure-mode disclosure, though it does not say how the rejection is surfaced.

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?

Four sentences, each carrying information: the operation, the input constraints, the output range, and the rejection rule. The purpose statement comes first, so the definition is front-loaded. Minor redundancy between the coprime precondition and the rejection sentence keeps it from a 5.

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 the description need not explain return values, yet it still specifies the normalization range of x, which is exactly the detail an agent needs to interpret the result. Combined with the coprime requirement and the rejection rule, everything required to invoke the tool correctly is present.

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 0%, so the description must carry the parameter semantics and largely does: it explains that residues and moduli are equal-length integer string lists, that moduli must be positive and pairwise coprime, and that the returned x lies between 0 and the product of the moduli. The only gap is the absence of format examples or bounds guidance for very large integers.

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 mathematical object ("중국인의 나머지 정리로 연립합동식 x ≡ r_i (mod m_i) 의 해 x 를 구한다") and pins down exactly what is computed. It is clearly distinguishable from siblings such as crypto.modinv, crypto.egcd, and crypto.modpow, which handle different number-theoretic operations.

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 gives clear preconditions and an explicit exclusion: moduli must be pairwise coprime, and non-coprime moduli are rejected even when a solution exists. That tells an agent when this tool applies and when it will fail. It stops short of naming an alternative for the non-coprime case, so it is not a full 5.

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?

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely non-obvious behavior: inputs are constrained to 2048-digit integer strings, the returned gcd is normalized to non-negative, and the Bezout coefficient pair is explicitly non-unique ('계수 쌍은 유일하지 않으며 이 알고리즘이 내는 한 쌍이다'). That non-uniqueness caveat is important for interpreting or comparing results, though the failure mode for inputs exceeding the digit limit is not described.

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?

Four short sentences, front-loaded with what is computed, then constraints, then the non-uniqueness caveat, then the sibling routing. Every sentence carries information the agent cannot get from the schema or annotations.

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 structure needn't be explained; the description instead covers what matters and isn't in the schema: input format/limits, output normalization (gcd ≥ 0), non-uniqueness of coefficients, and the alternative tool. For a 2-parameter pure function with full annotations, nothing an agent needs to call it correctly is missing.

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 0% (bare titles 'A'/'B'), so the description must compensate — and it does, stating both parameters are integer strings with a 2048-digit cap. It does not clarify sign handling (e.g. whether negative operands are accepted or how the gcd normalizes for them), leaving a small gap given zero schema help.

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 and resource ('확장 유클리드 알고리즘으로 gcd(a, b) = a*x + b*y 를 만족하는 gcd 와 Bezout 계수 x, y 를 구한다') and names the identity it satisfies, which lets an agent distinguish it from crypto.gcd and crypto.lcm without opening the schema. The output is named explicitly (gcd plus the Bezout pair), so the purpose is unambiguous.

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 routes the agent to crypto.modinv when a modular inverse is the goal ('모듈러 역원이 목적이면 modinv 가 직접적이다'), which is the main competing sibling. It does not state when to prefer this over plain crypto.gcd (i.e. when only the gcd is needed), so the routing is clear but not exhaustive.

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?

Annotations already carry readOnly, idempotent and closed-world hints, yet the description adds real behavioral context: trial-division factoring, an error when n exceeds the limit, and the shape of the result. The note that it is unusable at RSA scale is exactly the kind of non-obvious caveat annotations cannot express.

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?

Four dense sentences: the formula and purpose first, then input constraint, then output shape, then the practical limitation. No filler and the most decision-relevant 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 single-parameter read-only math tool, the description covers purpose, valid input domain, failure mode, return structure and a practical limitation. The output schema exists, but the extra explanation of phi and the factorization map costs nothing and adds clarity.

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% – the schema only says 'n: string'. The description fully compensates by specifying that n is an integer string, its inclusive bounds 1 to 10^14, and that out-of-range input is an error.

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 ('오일러 토션트 φ(n) = n * Π(1 - 1/p) 를 구한다'), giving the exact function and its formula. It does not explicitly differentiate itself from its closest sibling, crypto.carmichael_lambda, but the formula itself makes the distinction unambiguous.

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 a hard input domain (1 ≤ n ≤ 10^14) and an explicit exclusion ('RSA 크기의 수에는 쓸 수 없다'), which effectively tells the agent when not to call it. It stops short of naming an alternative tool for the large-number case, so the routing is implied rather than complete.

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?

Annotations already declare readOnly/idempotent/closed-world, and the description adds real behavioral detail beyond them: sign is ignored, a 2048-digit limit applies, both-zero returns 0, and decimal points or commas are rejected. It leaves minor behavior implicit, such as whether the result is always non-negative.

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 dense sentences with no filler, and the core operation plus input contract are front-loaded ahead of edge cases and chaining advice. The final sentence bundles two ideas (rejection rules and multi-number chaining) but stays compact.

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 two-parameter arithmetic tool with an output schema already documenting the return, the description covers everything an agent needs: input encoding, limits, rejection rules, the degenerate zero case, and how to extend beyond two operands.

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, the description carries the full burden and does so: it explains that a and b are integer-encoded strings, that signs are dropped, that the digit limit is 2048, and what input shapes are rejected. Only the exact output encoding of edge cases beyond both-zero is unspecified.

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 and resource ('두 정수의 최대공약수(GCD)를 구한다') so the operation is unambiguous. It does not distinguish itself from nearby siblings such as crypto.lcm or crypto.egcd, so an agent must infer the boundary from names alone.

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 concrete usage direction: exactly two operands, and for three or more numbers the caller must chain by re-feeding the result. It does not state when to prefer crypto.egcd or crypto.lcm, so it is clear context without explicit exclusions.

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?

Annotations already cover safety (readOnly, idempotent, closed-world), and the description adds genuinely new behavior: the encoding applied to input, the exact hex casing of output, the blake2b 64-byte output length, and the security limitation of unsalted/uniterated hashing. It does not state error behavior for unsupported algorithm values, which keeps it from a 5.

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, front-loaded with output format, then algorithm options, then the usage caveat. No filler or restatement of the tool name.

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 details need not be restated, and the description nevertheless pins down the hex format. Only edge cases (e.g., unsupported algorithm names, empty input) are unaddressed.

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 0%, so the description must carry the parameter burden, and it does: algorithm's allowed values, its default (sha256), its case-insensitivity, and the differing output size for blake2b. The data parameter gets only an implied meaning (string, UTF-8 encoded) rather than an explicit statement.

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 (hash) and resource (a UTF-8 string) plus the exact output form (lowercase hex). It is trivially distinguishable from the neighboring crypto tools, which are number-theoretic (gcd, modinv, modpow) or certificate-related (crypto.crt).

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 frames the tool as an integrity-fingerprint function and explicitly excludes password storage ("솔트와 반복이 없어 비밀번호 저장에는 쓰지 않는다"), which is strong when/when-not guidance. It does not name an alternative to use for password hashing, but no sibling offers one, so the gap is minor.

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?

Annotations already declare readOnlyHint/idempotentHint, and the description adds substantial behavior beyond them: the determinism threshold, the probabilistic tail with witness count, the 2048-digit input ceiling, edge-case handling (n < 2 and negatives return False), and the explicit caveat that True is not a primality proof.

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?

A single dense paragraph with zero filler — algorithm, input format, edge cases, determinism threshold, and caveats in that order. Every clause carries information an agent needs.

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 two-parameter read-only predicate with an output schema, nothing is missing: input format, limits, edge cases, and the interpretation of a True result are all covered, so the agent can call it and read the boolean correctly.

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 load and it does: n is specified as an integer string with a digit limit and defined behavior for values below 2 and negatives; k is given a default (20), a valid range (1–256), and a meaning (random witness count). That fully compensates for the undocumented 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?

States a specific verb+resource (판정한다 / 소수 여부 is_prime(bool)) plus the algorithm (Miller-Rabin), and explicitly excludes a neighboring capability with '소인수분해는 하지 않는다', so an agent can separate it from a factorization tool without opening the schema.

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?

Explains precisely when the result is trustworthy: deterministic below ~3.8e18 via fixed witnesses, probabilistic above that with k random witnesses, and that True is not a proof of primality. It doesn't name an alternative sibling tool, which keeps it from a 5.

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?

Annotations cover the safety profile (readOnly, idempotent, closed-world), and the description adds behavior those annotations cannot express: sign is ignored, inputs are capped at 2048 digits, big integers are computed exactly, and either operand being 0 yields 0. What's missing is any note on error behavior for malformed or over-limit input.

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?

Four short sentences with the core operation front-loaded, then constraints, then the zero edge case, then the use case. Dense and waste-free, though the fraction-reduction sentence is slightly tangential relative to the core definition.

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?

With an output schema present, return-format explanation is optional (the description mentions the integer-string result anyway), and the input contract, size limit and zero case are all stated. Only failure modes for invalid input are left unspecified.

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% (only bare 'A'/'B' titles), so the description must carry the load — and it does, stating both a and b are integer strings, that signs are ignored, and the 2048-digit limit. It doesn't say whether leading zeros or whitespace are tolerated, keeping it just below a 5.

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?

Names a specific verb+resource ('두 정수의 최소공배수(LCM)를 구한다') and pins down input/output types. It is clearly distinct from crypto.gcd / crypto.crt in practice, but never explicitly contrasts with those siblings, so an agent must infer the boundary.

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 concrete usage context (fraction common denominators via the LCM of denominators) and one explicit exclusion ('소수 입력은 받지 않는다'). It does not name an alternative tool to use when the LCM is not what's wanted, so it stops short of full when/when-not routing.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral details beyond annotations: the 2048-digit limit, m >= 2 requirement, result range 0 <= result < m, and specific error conditions when gcd(a,m) != 1 or a is 0.

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 short and front-loads the core operation before constraints and error behavior. The final sentence partially restates the gcd condition already covered earlier, which is a minor redundancy but not harmful.

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 and annotations cover the safety profile, so the description need not explain return values or read-only behavior. It provides the key input constraints, error conditions, and result bounds needed to call the tool correctly, with only sibling-routing guidance missing.

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 0%, so the description must carry parameter meaning, and it does: both a and m are integer strings with a 2048-digit limit, and m must be at least 2. It also clarifies the result range and the gcd precondition that governs whether a has an inverse, though edge cases such as negative a are not explicitly addressed.

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 and mathematical resource: it computes the modular inverse a^-1 mod m. This is clear and distinct from siblings such as crypto.modpow or crypto.egcd, though it does not explicitly name alternatives to reinforce the distinction.

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 gives mathematical preconditions (m >= 2, gcd(a,m)=1) but does not explain when to choose this tool over related siblings like crypto.modpow or crypto.egcd. There is no explicit when-to-use or when-not-to-use guidance beyond the validity conditions.

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?

The annotations already establish that the operation is a read-only, idempotent, non-open-world function, so the safety profile is covered. The description adds constraints beyond the annotations: a 2048-digit limit per argument, modulus >= 1, exponent >= 0, and a guaranteed result range of [0, modulus). This is meaningful context, but it does not describe error behavior when the digit limit or the domain constraints are violated.

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 four sentences, ordered from purpose to input format, output range, and alternative. Every sentence adds new information with no restatement of the tool name or title.

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, and the description still usefully gives the result domain; the input format and limits fully cover a 3-required-parameter tool. It is nearly complete and lacks only error or failure behavior for out-of-range inputs, which is minor.

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 0%, so the description must carry the burden, and it does: it declares that all three arguments are integer strings, imposes a 2048-digit limit, and gives per-argument domain constraints (modulus >= 1, exponent >= 0). It does not separately explain what base or exponent means beyond their names, which are self-describing, so a 4 rather than a 5 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 names a precise mathematical operation and spells out the exact formula (base^exponent mod modulus), so the agent knows exactly what is computed without opening the schema. It also distinguishes itself from crypto.modinv by assigning negative-exponent inverse operations to that sibling.

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 final sentence gives an explicit exclusion plus the alternative tool ('for inverse with negative exponent, use modinv'), which directly disambiguates it from the closest sibling. It does not discuss broader routing versus other modular-arithmetic siblings such as crypto.crt or crypto.egcd, but that absence is minor for a pure function.

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?

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, and the description still adds meaningful behavior: weekend and holiday skipping, KR default country, exclusion of the start date from the count, the absolute-value cap of 100000, and the special days=0 return. It does not discuss invalid country codes or error behavior, but its disclosure of behavior is well above the annotation baseline.

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 dense sentences front-loaded with the return value and its format, then the skip rules, then the edge cases. Every sentence carries substantive information, though the enumeration of rules in the middle sentence is somewhat hard to parse.

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?

With an output schema present, the description need not explain return values, yet it still names the output field and format. All four parameters and the key edge cases are covered, so the description is close to complete; it does not state what happens when the inputs are invalid.

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 0%, so the description must carry the full burden of explaining parameters; it does explain all four: start_date as the base date, days as a signed integer with a 100000 cap and defined 0-behavior, country as the holidays-package country code defaulting to KR, and extra_holidays as additional dates to skip. The remaining gap is that it never states the expected string format for start_date, extra_holidays, or country codes.

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 and resource: it adds signed business days to start_date and returns end_date in YYYY-MM-DD format. The business-day and holiday-skipping semantics make it clearly distinct from datetime.diff or datetime.count_business_days, but no sibling is named explicitly, so the definition does not achieve the highest level of differentiation.

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 does not explicitly state when to use this tool versus alternatives such as datetime.diff or datetime.count_business_days, and it names no exclusions. The usage is strongly implied by the precise semantics, which is the minimum viable level.

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?

Annotations already declare readOnly/closed-world, and the description adds genuinely non-obvious behavior: omitting reference_date makes results depend on the server's execution date, the birthday boundary rule (age increments on the birthday itself), and the error condition. This is exactly the kind of context annotations cannot carry.

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?

Four sentences, each carrying distinct information (purpose, format/boundary rule, default behavior, error/scope exclusion), with purpose front-loaded. Dense but no filler; the 세는나이 exclusion could be framed more directly as guidance.

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?

Output schema exists, so return shape need not be described. Inputs, default, boundary rule, and error case are all covered; the only real gap is the timezone behind the server-default date.

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 compensate, and it does: it specifies the YYYY-MM-DD format for both dates, that reference_date is optional and defaults to the server's today, and the invalid-ordering error. It stops short of stating the server timezone, which matters for the default.

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 computation (Korean legal age in years/months/days as integers) and scopes it against the obvious confusable concept by declaring 세는나이 is not computed. An agent can tell this apart from datetime.diff or datetime.day_count without opening any schema.

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 clear operating context: reference_date may be omitted (server today is used), and a reference date earlier than the birth date is an error. It does not explicitly name a sibling alternative for the counting-age case, only excluding it, so it stops short of full when/when-not routing.

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?

Annotations only declare readOnly/idempotent/openWorld=false; the description adds genuinely new behavioral facts: both endpoints are inclusive, Saturday/Sunday plus the holidays package's country calendar (default KR) are excluded, and two concrete error conditions (reversed range, range over 100000 days). It also discloses a limitation — there is no input to add ad-hoc temporary holidays — which prevents a wrong call.

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, front-loaded with the action and return type, then the exclusion rules, then the error/limitation clause. No filler, though the final clause packs error conditions and the missing-holiday-input note into one dense sentence.

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 3-param, read-only, idempotent computation with an output schema, the description covers everything an agent needs: input format, inclusivity, holiday policy and default, error guards, and the absence of a custom-holiday parameter. Return shape is handled by the output schema, so nothing material is missing.

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 0%, so the description must carry parameter meaning, and it does: start/end are YYYY-MM-DD and inclusive, and country selects the holidays-package calendar with a stated default of KR. All three parameters get semantics the schema alone does not provide.

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 ('영업일 수 count 를 정수로 센다') with the exact scope: between start and end, inclusive of both endpoints, excluding weekends and country holidays. This clearly separates it from datetime.add_business_days (which shifts a date) and datetime.day_count (which counts calendar days) without needing to open any schema.

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 defines the operating rules (inclusive endpoints, weekend/holiday exclusion, default KR) and error boundaries (end before start, span > 100000 days), which implicitly tells the agent when this tool fails. However, it never explicitly routes the agent away from sibling alternatives like datetime.day_count or datetime.add_business_days, nor states when to prefer another tool.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description adds substantial behavior: output precision capped at 50 significant digits with no rounding, output types (integer vs Decimal string), and the exact 30/360 variant (31st end-of-month adjustment only, no February rule) plus per-year-boundary leap denominators for ACT/ACT. These are real implementation details an agent could not infer. Minor gap: no error/edge behavior for equal or reversed dates beyond 'end must be after start'.

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, front-loaded with what is returned, followed by the convention taxonomy and the date constraint. Dense but every clause is load-bearing; the parenthetical convention qualifiers are exactly the disambiguation needed.

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 3-required-param calculation tool with an output schema (so return structure needn't be explained, though types are still noted), the description supplies output meaning, convention semantics, date format, and input constraint. An agent can call it correctly without opening anything else.

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 0% and the convention parameter has no enum, so the description carries the full burden — and it does: all four convention values are enumerated with their distinguishing semantics, the date format YYYY-MM-DD is given for start/end, and the start<end ordering is stated. Nothing about the three required parameters is left undocumented.

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 and result set: computes interest-accrual day count (integer days) and annualized year_fraction (Decimal string), which is far more precise than a generic 'date difference'. It never names a sibling such as datetime.diff to draw the boundary, so it falls short of the top mark.

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 domain anchor ('이자 계산용', for interest calculation) implies the intended use case, and the ordering constraint that end must follow start is stated. However, there is no explicit guidance on when to choose this over datetime.diff or the business-day tools, and no exclusions.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds real computational semantics beyond them: weeks floors by 7, months/years count only complete periods, and the sign flips when end precedes start. It does not mention error behavior for malformed dates or unsupported units.

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?

Four dense sentences, front-loaded with the return contract and followed by unit semantics and the sign rule. No filler, though the unit definitions and the date format are stated in separate sentences that could be tightened.

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, and the description already states the return is an integer string, so return-value explanation is not required. Combined with annotations covering safety and the description covering all three parameters, the definition is nearly complete; only invalid-input behavior is unaddressed.

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% and no parameter has an enum, so the description carries the full burden — and it does so well, fixing the YYYY-MM-DD format for start/end and enumerating the unit domain (days | weeks | months | years) with per-unit computation rules. It stops short of naming each parameter's role explicitly (start vs end other than via the negative-case remark).

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 (difference between two dates) and enumerates the four output units, so the agent knows exactly what is computed. It does not differentiate from close siblings such as datetime.day_count or datetime.age, which likely overlap, so an agent must infer which to pick.

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?

Usage is only implied by the unit semantics; there is no explicit statement of when to choose datetime.diff over datetime.day_count or datetime.age, nor any note on invalid inputs. Adequate but leaves routing to inference.

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?

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds real behavioral rules beyond that: quarters are cut in 3-month steps from each country's fiscal-year start, the start day-of-month is preserved, and UK quarters begin on the 6th. It does not disclose edge-case handling (e.g. day-of-month overflow such as a 31st start), which for a date-arithmetic tool is the remaining risk.

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 dense sentences with no filler: output definition, computation rule, then the exclusion. The returned value is front-loaded and the caveat is placed last where it belongs.

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 the description needn't spell out the return shape, and the country/as_of semantics are fully covered. The one gap is that per-country fiscal-year start dates (KR Jan 1, US Oct 1, JP Apr 1, UK Apr 6) are referenced but never listed, leaving the agent to rely on the implementation for the actual anchors.

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 0%, so the description carries the full load and does so: as_of is defined as a YYYY-MM-DD reference date, and country is enumerated inline (KR | US | JP | UK) with a stated default of KR — information the schema's bare string types do not provide.

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 (구한다) and resource (회계분기), plus exactly what is returned: quarter number 1~4 and start/end dates. Naming '분기' versus the sibling datetime.fiscal_year makes the scope boundary legible without opening either schema.

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 clear applicability context via the country parameter (fiscal-year start per jurisdiction, default KR) and an explicit exclusion: statutory filing deadlines such as VAT reporting are not computed. It stops short of naming the alternative tool (e.g. datetime.tax_period_kr) that would handle those deadlines, so the 'use instead' half of the guidance is only implied.

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the actual country calendars (KR/US 1/1~12/31, JP 4/1~3/31, UK 4/6~4/5) and the labeling convention (label = year containing the start date), plus a real limitation about company-specific fiscal year ends. That is meaningful behavioral context; only the default-country behavior is left implicit in the schema.

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, front-loaded with the core action and result, then the country rules, then the exclusion. Dense but every clause carries information (period boundaries, label rule, limitation); only the inline country list makes it slightly run-on.

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 not be explained, yet the description still names the returned label and start/end dates. Combined with the calendar rules, label convention, and scope caveat, an agent has everything needed to call it correctly.

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 0% and the schema declares no enums, so the description carries the full burden — and it does: it gives the as_of format (YYYY-MM-DD) and enumerates the accepted country values with their exact period boundaries. This adds information the schema does not contain at all, not a restatement of it.

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 and resource ('as_of가 속한 회계연도의 라벨 fiscal_year 와 시작·종료일을 구한다') and names the returned fields, so it is immediately distinguishable from datetime.fiscal_quarter and the rest of the datetime family. No ambiguity about whether it returns a date, a label, or both.

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 bounds applicability with '기업별 결산기는 반영하지 않으므로 고정 국가 기준 연도 판정에만 쓴다', telling the agent when this tool is the wrong choice. It does not, however, name the sibling alternative (e.g. datetime.fiscal_quarter or datetime.tax_period_kr) that an agent should reach for in the excluded case.

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?

Annotations already establish readOnly, idempotent and closed-world, so the bar is low; the description still adds real behavioral context by bounding the year range to 2020~2030, stating leap months are unsupported, and warning that substitute holidays and holiday spans are not computed. Those are exactly the surprises an agent would otherwise hit.

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?

Two dense sentences with zero filler, and the core conversion purpose is front-loaded before constraints. Slightly run-on for a reader, but every clause (enum list, year range, leap-month exclusion, no-substitute-holidays) 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?

An output schema exists, so return values need not be explained, and the description covers the parameters, range limit, and known exclusions. The only residual gap is behavior on invalid names or out-of-range years, which is not stated but is likely enforced by the server.

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 0% and there are no enums, so the description carries the entire burden: it lists all seven valid name values with Korean glosses and defines year as the lunar year with its range. It also explains the non-obvious edge case that seotdal_geumum returns a solar date in the following January/February.

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 and resource ('음력 명절을 양력 solar_date 로 환산한다') and is clearly narrower than the generic datetime.lunar_to_solar / solar_to_lunar siblings, since it operates on a fixed set of named holidays. It never explicitly names those siblings, but the enumerated holiday list makes the scope unambiguous.

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?

Usage is only implied through the enumerated names and the 2020~2030 range; there is no explicit 'use this when X, use lunar_to_solar when Y' routing. The exclusion of 윤달 and 연휴/대체공휴일 implicitly says when not to reach for this tool, but it is never framed as guidance.

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