nestegg-calculators

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

Annotations already disclose read-only and idempotent behavior. The description adds the formula (annual coupon pro-rated by days elapsed over day-count basis), which clarifies the calculation logic. However, it does not disclose edge cases or return format, though the output schema partially covers that. The added value is moderate beyond 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?

The description is a single, dense sentence that front-loads the purpose and immediately gives the calculation formula. There is no wasted wording, and it is easily scannable.

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

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

Given the tool's moderate complexity (4 parameters, output schema, annotations), the description is sufficiently complete. It explains the core calculation and is supported by schema and annotations. Minor gaps like explicit usage guidance are not critical here.

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

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

Schema description coverage is 100%, so all parameters have descriptions. The description adds the relationship between parameters (days elapsed, day-count basis, coupon rate) but does not provide new parameter-level details. Baseline 3 applies per the rubric.

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

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

The description clearly states the tool's purpose: calculating accrued interest since the last coupon. It provides a specific verb (pro-rated) and resource (annual coupon), and explains the calculation methodology. This distinguishes it from sibling tools like bond-price or current-yield by focusing on the accrued interest component.

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 usage for accrued interest calculations but does not explicitly state when to use it over alternatives or provide exclusions. Sibling tools include other bond-related calculators, but no cross-referencing or guidance is offered. Usage is implied rather than explicit.

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 declare read-only and idempotent. The description adds that inputs and outputs are percentages, clarifying unit convention. The formula is simple but no additional behavioral details such as rounding or edge cases are disclosed.

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?

Single sentence, front-loaded, and every word earns its place. Efficiently communicates the formula and unit expectations with no waste.

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

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

For a simple two-parameter calculator with full schema coverage, read-only annotations, and an output schema present, the description is adequate. Could mention the inverse relationship to tax-equivalent-yield, but that is not required for basic operation.

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 already documents both parameters with percentages. Description explicitly states 'yield reduced by tax rate,' clarifying the mathematical relationship between yieldPct and taxRatePct beyond field-level descriptions.

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

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

Description clearly identifies the tool as computing after-tax yield via tax-rate reduction, distinguishing it from related yield tools. Uses a noun phrase rather than an explicit verb, but 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?

No when-to-use guidance, no mention of alternatives like tax-equivalent-yield, and no context for when this calculation applies. Merely states what it does without exclusions or prerequisite context.

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 and idempotentHint, so the description doesn't need to restate safety. It adds value by disclosing the default output behavior ('summary' returns totals plus per-year breakdown), the need to paginate with offset/limit for 'monthly', and the non-advisory nature ('no advice'). This goes beyond the structured metadata and helps set expectations for the tool's output.

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, each with distinct value: purpose, features, output behavior, and output type/disclaimer. It is front-loaded with the core purpose, avoids redundancy, and does not waste words. The only minor omission is not explicitly naming the 'yearly' enum value, but the description still conveys that summary includes yearly breakdown.

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

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

Given the tool's complexity (12 parameters, nested optional arrays), the description provides a good high-level map: core function, key optional inputs, output modes, and pagination. The schema covers parameter details and an output schema exists, so the description doesn't need to explain return structures. It could mention the 'yearly' detail option or clarify 'rate-fixed period' more, but these are minor gaps given the rich schema.

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

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

Schema description coverage is 100%, with each parameter clearly documented (e.g., rate 'in percent', mode semantics, offset/limit purpose). The description mostly restates what the schema already provides, such as detail options and pagination, without adding new parameter-level insights. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 resource: 'Monthly loan amortization schedule and summary.' It clearly distinguishes the tool from more general financial calculators by focusing on amortization with monthly detail and summary output. The scope (loan amortization) and key features (extra principal payments, rate-fixed period) are immediately evident.

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 usage by explaining output options ('detail controls output size') and capabilities ('Supports dated extra principal payments and a rate-fixed period'), but it does not explicitly state when to choose this over sibling tools like loan-payoff or biweekly-payoff. There are no explicit alternatives or exclusion conditions, leaving the agent to infer applicability from the tool's name and features.

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 and idempotentHint=true, so the safety profile is clear. The description adds the per-period rate clarification, but does not disclose edge-case behavior or return details. This is adequate given 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?

The description is a single concise sentence, front-loaded with the core purpose. No redundant words or filler. It 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?

For a simple financial calculator with full schema annotations and an output schema, the description is largely complete. It clearly defines the annuity type and rate unit. It could mention intended use cases or exclusions, but the tool's simplicity makes this acceptable.

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

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

Schema description coverage is 100%, with each parameter fully described. The description simply restates the rate parameter semantics ('rate is the per-period rate in percent') without adding new meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool computes the future value of an ordinary annuity, using a specific verb and resource. It distinguishes itself from sibling tools like annuity-pv and annuity-payment by explicitly mentioning 'future value' and 'ordinary annuity'.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention exclusions or when to prefer this over future-value or annuity-payment. The only hint is the 'ordinary annuity' qualifier, but no explicit usage context is given.

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, openWorldHint false, and idempotentHint, covering the safety and repeatability profile. The description adds useful behavioral context by emphasizing that the rate is per period and that the payment is level (fully amortizing), which goes beyond the schema. No contradiction with 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?

A single, straightforward sentence with no wasted words. It front-loads the core purpose and includes a helpful clarification about the rate.

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 has a full schema, output schema, and annotations, so the description does not need to explain return values or safety. It adequately covers the calculation purpose and rate semantics, making it sufficiently complete for a simple financial formula 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 100%, so the baseline is 3. The description's note that 'rate is per period' reinforces the schema's 'Rate per period in percent' but does not add new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the tool computes the level payment that amortizes a present value over n periods, using the loan-payment formula. This specific verb and resource distinguish it from sibling tools like annuity-fv and annuity-pv, which calculate future/present value rather than the payment.

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 context: it is the loan-payment formula with a per-period rate, implying when to use it. However, it does not explicitly name alternative tools or provide exclusion criteria, 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?

The annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate that. It adds the behavioral constraint that this is an ordinary annuity with payments at period end, and clarifies that the rate is per-period in percent, which prevents misuse. No contradiction with 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?

The description is a single concise sentence that front-loads the core purpose and includes the key nuance about payment timing. Every word 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?

Given the simplicity of the tool, the combination of the description, full schema descriptions, and annotations is sufficient. The description covers the main concept and the rate unit, leaving no obvious gaps for a straightforward financial calculation. It doesn't explain the formula, but that's not required.

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

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

The input schema already provides descriptions for all three parameters (payment, periods, ratePct), and the description reinforces that ratePct is per-period and in percent. However, it adds little beyond the schema's existing parameter descriptions, so the added semantic value is marginal.

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 explicitly states the tool calculates the present value of an ordinary annuity, with a parenthetical clarifying level payments at period end. This clearly distinguishes it from sibling tools like annuity-fv or annuity-payment.

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 the tool by defining the scenario (ordinary annuity, period-end payments), but it does not explicitly name alternatives or state when not to use it. It doesn't mention that annuity-fv handles future value or that present-value may handle general cash flows. Guidance is implied rather than direct.

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 and idempotentHint=true, so the safety profile is covered. The description adds transparent behavioral context by explaining the calculation mechanism: payment is based on the amortization period, and the balloon equals the balance remaining after the balloon term. This goes beyond the annotations but stops short of discussing edge cases or error handling.

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

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

The description is a single, focused sentence that leads with the term 'Balloon loan' and immediately explains the core concept. Every word earns its place with no fluff or repetition.

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. The description captures the essential relationship between the amortization period and the balloon term, making it nearly complete for a simple financial calculator. However, it does not mention how the parameters interplay in edge cases (e.g., balloonMonths > amortMonths), leaving a slight gap.

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

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

Schema coverage is 100%, with each parameter (amount, ratePct, balloonMonths, amortMonths) having a clear description. The tool description does not add parameter-specific syntax or additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly defines a balloon loan as 'payment based on a long amortization' with the balloon being the remaining balance due after the shorter term. It explicitly names the resource (balloon loan) and the computation logic, distinguishing it from siblings like amortization or interest-only-payment.

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 usage for balloon loan calculations but does not provide explicit guidance on when to use this tool versus alternatives such as amortization or loan-payoff. No when-not-to-use or alternative references are given, leaving the agent to infer applicability from the financial context.

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 and idempotentHint, and the description adds the behavioral formula: the portfolio funds the remainder after part-time income at the safe withdrawal rate. This goes beyond the annotations by explaining the calculation logic, though edge cases are not 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?

A single, well-front-loaded sentence that defines the tool's purpose without redundant words. Every part of the description 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?

Given a simple three-parameter calculator with an output schema, the description sufficiently conveys the core calculation and result. It does not explicitly formulaize (annualSpend - partTimeIncome) / withdrawalRatePct, but the concept is clear enough for a simple tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that annualSpend and partTimeIncome are combined (the remainder is funded) and that withdrawalRatePct is the divisor, which goes beyond the schema's simple 'Yearly spending' descriptions.

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

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

The description clearly states the tool computes the nest egg needed when part-time income covers part of spending, defining the calculation concept. It is distinct from generic fire-number and coast-fire siblings, though it lacks an explicit verb like 'calculate'.

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 usage when part-time income partially covers spending, but it does not explicitly mention when not to use it or compare it with alternatives like coast-fire or fire-number. The condition is present but not framed as guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds the calculation method ('paying half the monthly payment every two weeks') and the return values, which is transparent for a read-only calculator. No contradictions with 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?

The description is two sentences, front-loaded with the core concept, and contains no redundant information. Every word 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?

Given the tool's simplicity (3 required params, no nested objects, output schema present), the description adequately conveys the operation, return values, and basic context. It is complete enough for an agent to select and invoke 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?

The input schema covers all three parameters with descriptions (amount, ratePct, termMonths), providing 100% coverage. The description does not add further parameter nuance beyond the biweekly payment concept, so the baseline 3 is appropriate.

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

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

The description clearly identifies a biweekly mortgage acceleration calculator and specifies its outputs: 'Returns the biweekly payment and the months and interest saved.' It distinguishes this from sibling tools like amortization or loan-payoff by focusing on the biweekly payment strategy.

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 states the scenario ('Biweekly mortgage acceleration') but does not explicitly discuss when to use this tool versus alternatives or any exclusions. Usage is implied from the tool's specific purpose rather than clearly delineated.

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 and idempotentHint annotations, safety is already disclosed. The description adds valuable behavioral context: volatility and rates are in percent (not decimals), and the output includes d1/d2. It also specifies European-only scope, a key limitation. No contradictions with 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?

The description is a single, compact sentence that front-loads the core purpose. Every clause contributes essential information: European scope, call/put, d1/d2, percent units, and optional dividend yield. There is no fluff.

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 7-parameter pricing model with a rich schema and output schema present. The description covers the key model context and unit conventions. Minor details like per-share pricing are inferable or already documented in structured fields.

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

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

Schema coverage is 100%, with each parameter having a description. The description only reiterates the optional dividend yield and percent convention already present in the schema, adding no new parameter-specific meaning.

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

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

The description clearly states the tool computes the Black-Scholes price of European call/put options plus d1/d2. This specific verb+resource combination with the European scope distinguishes it from sibling tools like option-greeks and option-breakeven.

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

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

The description implies the applicable context: European options, Black-Scholes model, and inclusion of d1/d2. It does not explicitly exclude other option types or list alternatives, but the clear scope provides sufficient context for correct tool selection.

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 and idempotentHint=true, which fully covers the safety profile of this pure calculation tool. The description adds semantic context by defining the output metrics, but it does not disclose any behavioral assumptions (e.g., continuous compounding, default periodsPerYear=2) that could affect 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?

The description is a single, tightly packed sentence that defines both output metrics without redundancy. Every clause contributes to the understanding of what the tool computes, making it an exemplar of concise and effective communication.

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 clear annotations, the description sufficiently covers the core functionality. It explains the meaning of the two duration measures and implies the input parameters from context. However, it omits subtle behaviors like the default compounding frequency or edge cases for zero-coupon bonds, which would benefit a finance user.

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

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

The input schema has 100% parameter coverage with descriptions for all five parameters, so the schema already explains each field. The description adds no additional parameter-level detail beyond what the schema provides, making this a baseline score with no extra semantic value.

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 identifies the tool as providing Macaulay duration and modified duration, specifying their formulas and meaning. It distinguishes between the two metrics and sets it apart from sibling tools like convexity or bond-price, though it lacks an explicit action verb such as 'calculate' or 'compute'.

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 no guidance on when to use this tool versus alternatives like convexity or yield-to-maturity. It does not state any preconditions, such as needing fixed-cashflow bonds, nor does it mention when modified duration is preferred over Macaulay duration.

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 read-only, idempotent, and closed-world behavior. The description adds the calculation logic (PV of coupons + face), which is useful context beyond the annotations. No contradictions.

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

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

The description is a single, well-structured sentence that conveys purpose and method without redundancy. Every word 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?

Given the simple deterministic nature, full parameter documentation, annotations, and output schema, the description provides sufficient context. It clearly explains the core calculation without requiring further elaboration.

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

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

Schema description coverage is 100%, so parameters are fully documented. The description mentions coupon and face but does not add new meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool computes the price of a coupon bond given a yield, using present value of coupons plus face value. This distinguishes it from siblings like bond-duration or yield-to-maturity, which answer different questions.

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 'given a yield' implies the tool is used when you have a yield and want to find the price, but it does not explicitly mention alternatives or when not to use it. No clear exclusionary guidance is provided.

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 and idempotentHint, so the safety profile is clear. The description adds value by detailing the exact calculation and the additional revenue output, which goes beyond the annotations but does not contradict them.

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, focused sentence that conveys the formula and the additional output without unnecessary words or repetition.

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

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

For a simple calculator with full schema coverage and an output schema, the description covers the essential behavior. However, it does not mention edge cases like the undefined scenario when price equals variable cost, which could be relevant in some contexts.

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

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

Schema coverage is 100% with simple field descriptions. The description enriches these by defining the mathematical relationship among the parameters (price minus variable cost, divided into fixed costs), giving the agent a clear understanding of how inputs are used.

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 explicitly states the break-even volume formula (fixed costs divided by per-unit contribution) and notes it also computes revenue at that volume. This clearly distinguishes it from other break-even tools like option-breakeven or refi-breakeven, which have different contexts.

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 use for unit-level break-even analysis, but the description provides no explicit when-to-use or alternative comparisons. There is no stated exclusion, but the guidance is only implicit.

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 and idempotentHint, so the safety profile is covered. The description adds no extra behavioral traits such as rounding, assumptions, or output details, but it does not contradict 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?

The description is a single, front-loaded sentence that conveys the core purpose with no unnecessary words. It is appropriately sized for a simple calculator.

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

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

Given the tool's simplicity (one input, output schema present, clear annotations), the description is complete enough. The output schema handles the return value explanation, so the description only needs to state the tool's function.

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

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

The schema fully describes the only parameter, monthlyIncome, as 'Monthly take-home income.' Since schema coverage is 100%, the description does not need to add more, and it does not provide any additional semantics beyond the schema.

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

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

The description clearly states the purpose: splitting monthly income into needs, wants, and savings according to the 50/30/20 rule. It is specific about the resource (monthly income) and the action (split), and it distinguishes itself from sibling financial calculators.

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 guidance is provided on when to use this tool or when to choose an alternative. There is no mention of budgeting scenarios, prerequisites, or comparisons with similar tools like savings-rate.

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 description explains the output format as a decimal (e.g., 0.07 = 7%), which is valuable behavioral context beyond the annotations that declare read-only and idempotent behavior. It does not cover edge cases or side effects, but for a simple calculation this adds sufficient transparency.

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

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

The description is a single sentence that defines the tool and includes the return format. It is front-loaded and contains no waste, perfectly balancing brevity and informativeness.

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

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

For a simple calculation tool with annotations and an output schema, the description is complete enough. It states the purpose and the output format, though it does not address potential edge cases (e.g., zero starting value) or parameter constraints, leaving a minor gap.

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

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

The input schema already provides descriptions for all three parameters (begin, end, years) with 100% coverage. The description adds no new parameter-specific meaning beyond 'between two values... over a number of years', which is a restatement rather than additional semantic detail.

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 defines the tool as computing the compound annual growth rate between two values over a number of years. This includes the specific verb 'growth rate' and the resources/parameters involved, distinguishing it from other financial calculators.

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 the tool (when a CAGR calculation is needed) but does not provide explicit guidance on alternatives or exclusions. It lacks a 'when not to use' statement or references to sibling tools, so it only meets the implied usage 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?

With annotations declaring readOnly and idempotent behavior, the description adds the exact operational formula (NOI as a percent of property value), which clarifies the calculation beyond the structured metadata. It does not address edge cases like zero property value, but the output schema and simple nature reduce the need.

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

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

The description is a single, front-loaded sentence that defines the concept and formula without any filler or redundancy. Every word 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?

For a two-parameter calculator with an output schema and read-only annotations, the description plus schema fully specifies the calculation. It lacks explicit usage scenarios or edge-case handling, but these are not critical for such a self-contained formula 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?

The schema already provides 100% description coverage for both parameters. The description adds the relationship between them—'net operating income as a percent of property value'—clarifies the numerator and denominator roles, and indicates the output is a percentage, which goes beyond the schema's simple field labels.

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 defines what the tool computes: capitalization rate as net operating income divided by property value. Though it lacks an explicit verb like 'calculate', the formula makes the tool's function unambiguous and distinct from siblings like gross-rent-multiplier or noi.

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

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

The description implies the tool is used to compute cap rate but provides no explicit guidance on when to choose it over alternatives or any exclusions. For a simple formula calculator, this implied usage is acceptable, but it does not meet the standard for a 4.

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 and idempotentHint=true, covering safety and determinism. The description adds the formula and explicitly states the result is expressed as a percentage, which is useful behavioral context beyond the annotations. No contradiction.

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 sentence of 14 words that is front-loaded with the metric name and delivers the formula efficiently. Every word contributes value, with no repetition or 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?

The tool is a simple calculation with two fully described parameters, an output schema present, and annotations covering safety. The description provides the formula and result format, making it complete for the agent to invoke 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 100% with both parameters described ('Annual pre-tax cash flow' and 'Cash invested'). The tool description essentially restates these definitions, adding only the relationship that cash flow is divided by cash invested. Per the rubric, baseline is 3 when schema coverage is high.

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 precisely defines cash-on-cash return as 'annual pre-tax cash flow as a percent of the cash invested,' which is a specific formula. This clearly distinguishes the tool from sibling metrics like ROI or cap-rate by stating the exact calculation.

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 tool name and definition: an agent would select this when asked to compute cash-on-cash return. However, it gives no guidance on choosing between related metrics (e.g., ROI, cap-rate) or when not to use it, so it only reaches the 'implied usage' 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 readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds context about the return values (target, projected balance, coasting status, shortfall) and the deterministic nature of the projection, which goes beyond the annotations without contradicting them.

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

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

The description is a single, well-structured sentence that front-loads the concept and then lists the return values. Every word earns its place, with no unnecessary fluff or repetition.

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

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

The description is complete for this tool: it explains the concept, lists return values, and is supplemented by a full schema, output schema, and clear annotations. There is no hidden complexity or missing information that would leave an AI agent uncertain about invocation.

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

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

Schema coverage is 100%, with each parameter having a clear description (e.g., 'Amount invested today', 'Expected annual growth in percent'). The tool description adds minimal parameter-specific meaning, but the schema already carries the load, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: evaluating whether a current nest egg left untouched reaches the FIRE target at retirement. It specifies the resource ('current nest egg') and the action ('whether it coasts'), and distinguishes it from sibling FIRE calculators like fire-number or barista-fire by the unique coast FIRE concept.

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

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

The description implies the usage context (checking coast FIRE status) but does not explicitly state when to choose this over alternatives like barista-fire or fire-number. There is no mention of exclusions or alternative tools, so the guidance is implied rather than explicit.

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 and idempotentHint=true, so the agent knows it is a safe, repeatable read. The description adds valuable behavioral detail that contributions are paid at period end, which affects timing of calculations. This exceeds 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?

Two sentences, zero filler. The first sentence states the core function and the second positions it relative to siblings. Every word 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?

Given the five parameters and the presence of an output schema, the description covers the core behavior, contribution timing, and generalization to sibling tools. No necessary context is missing for a mathematical calculator tool.

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

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

Schema covers all parameters with descriptions, so baseline is 3. The description adds useful semantic context by explaining that periodsPerYear=1 corresponds to future-value and periodsPerYear=12 corresponds to contributions, clarifying defaults and typical usage beyond the schema.

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

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

The description clearly states the tool computes compound growth at any frequency with optional periodic contributions, and explicitly distinguishes it from sibling tools by noting it generalizes future-value and contributions. The purpose is unmistakable.

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 names sibling tools future-value and contributions, explaining how periodsPerYear=1 maps to future-value and periodsPerYear=12 maps to contributions. This provides concrete guidance on when to use this general tool versus those alternatives.

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 and idempotentHint=true, covering safety. The description adds that output includes both unit margin and percent of price, but says nothing about edge cases (e.g., zero price) or the underlying formula. This adds some context beyond annotations, so 3.

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?

Description is one short sentence with no filler or redundancy. It front-loads the core purpose and avoids repeating parameter names. Perfectly concise.

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

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

For a simple two-parameter calculator with an output schema, this description is mostly complete for an agent to understand return dimensions. However, it omits contextual cues about when this metric is useful or how it relates to sibling tools, and it does not explicitly state the formula. Still, given the simplicity and annotations, it is adequate, scoring 4.

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?

Both parameters have full descriptions in the schema (selling price per unit, variable cost per unit), so schema coverage is 100%. The tool description does not add any additional parameter semantics beyond what the schema already provides. Baseline 3 applies.

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

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

The description clearly states the tool computes contribution margin per unit and as a percent of price, distinguishing output forms. Though it lacks an explicit verb like 'calculate', the noun phrase is specific and unambiguous. Given sibling tools like break-even-units and margin-markup, the description narrows the scope but does not explicitly differentiate from them, so 4.

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 guidance is provided on when to use this tool versus alternatives like margin-markup or break-even-units. The description merely states what it computes, leaving the agent to infer from the name. This is a clear gap for a financial calculator with many siblings.

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

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

Annotations already establish readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is covered. The description adds the 'stepping up each year' behavior, but it omits details like compounding frequency or whether contributions are made at the beginning or end of each month, which are relevant for a financial 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?

The description is a single, concise sentence that is front-loaded with the core calculation ('Future value') and quickly covers the key nuance ('stepping up each year'). No unnecessary words are present.

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

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

The description is adequate for a straightforward calculator, but it leaves out crucial assumptions such as compounding frequency and contribution timing. While an output schema exists, it is not visible here, and the description alone is somewhat under-specified for a formula with multiple plausible interpretations.

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

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

Schema description coverage is 100%, with all four parameters already documented. The description simply echoes 'fixed monthly contribution' and 'stepping up,' providing no additional parameter semantics beyond what the schema already gives.

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 'Future value of a fixed monthly contribution, optionally stepping up each year,' which clearly specifies the tool's purpose. It distinguishes itself from siblings like 'future-value' and 'annuity-fv' by highlighting the step-up feature.

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 this tool—whenever a future value of periodic contributions with possible annual increases is needed—but it does not explicitly contrast with alternatives or state exclusions. This provides only implicit guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe calculation. The description adds the unit (years^2) and context of curvature, but does not disclose formula assumptions (e.g., compounding frequency) or edge cases. This adds modest value beyond 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?

The description is a single tightly written sentence that front-loads the metric name and unit, then defines the concept. Every word contributes to understanding, 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?

The tool is a simple calculator with an output schema and annotations. The description explains what convexity is, but lacks decision guidance on when to use it versus other bond metrics (e.g., bond-duration or bond-price). This is a gap for an AI agent selecting among siblings, though the low complexity mitigates it.

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

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

The input schema provides descriptions for all 5 parameters (100% coverage), so the description does not need to explain parameters. It adds no additional meaning about how faceValue, couponRatePct, etc., relate to convexity, leaving the schema to carry the weight. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as calculating bond convexity, defines it as 'the curvature of price with respect to yield,' and notes it is 'used alongside duration,' which distinguishes it from the sibling bond-duration tool. The unit (years^2) is also specified.

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 'used alongside duration' implies complementary use with duration, but it does not explicitly state when to choose this tool over alternatives or provide criteria such as 'use when assessing non-linear price risk.' No exclusions are given.

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 annotation readOnlyHint=true and idempotentHint=true already establish the safe, read-only nature. The description adds a crucial behavioral detail: 'Null when the payment can't cover the first month's interest.' This goes beyond the annotations by disclosing a failure condition and the output's null state, which helps the agent interpret results correctly. No contradiction with 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?

The description is a single, front-loaded sentence that efficiently states the core calculation, the interest component, and the null condition. Every clause earns its place with no filler, making it easily scannable for an agent.

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

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

For a simple calculator with only three parameters and an output schema (not shown), the description covers the essential semantics: the primary output (months to clear, interest paid) and a key edge case (null when payment insufficient). It does not explicitly state compounding assumptions or formula details, but these are not necessary for selection/invocation. The output schema likely provides return structure, so the description adequately supports correct use.

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

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

Schema description coverage is 100% (balance, aprPct, monthlyPayment all have descriptions). The description does not add any parameter-specific semantics beyond what the schema already provides. For example, the schema says 'Fixed monthly payment,' and the description repeats 'fixed monthly payment,' but does not elaborate on units, ranges, or edge cases. Baseline 3 is appropriate when the schema carries the parameter documentation.

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

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

The description clearly states the primary function: 'Months to clear a credit-card balance at a fixed monthly payment, plus interest paid.' This identifies the specific computation and the credit-card context, distinguishing it from sibling tools like loan-payoff or debt-payoff. The verb 'clear' combined with the resource 'credit-card balance' leaves no ambiguity about the tool's purpose.

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 offers no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, preconditions, or a preferred context. While the credit-card focus is implicit, there is no direct comparison to similar tools like loan-payoff or biweekly-payoff, leaving the agent to infer usage without clear direction.

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 and idempotentHint, so the safety profile is covered. The description adds the mathematical relationship but does not disclose edge-case behavior (e.g., zero liabilities) or return format. This is sufficient for a simple pure function.

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

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

The description is a single, compact sentence that states the metric and formula. No wasted words; it is immediately parseable.

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

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

For a simple ratio calculator with full schema descriptions, annotations, and an output schema, the description is adequate. However, it does not mention the use case (liquidity analysis) or distinguish from quick-ratio, which slightly reduces completeness.

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

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

The input schema describes both parameters as numbers with basic descriptions (100% coverage). The description adds the key relationship that currentAssets is divided by currentLiabilities, which is crucial semantic meaning beyond the schema.

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

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

The description clearly states the current ratio as current assets over current liabilities, making the calculation explicit. However, it lacks an explicit verb like 'calculates' and does not differentiate from the sibling 'quick-ratio' 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?

No guidance is provided regarding when to use this tool versus alternatives like quick-ratio or other liquidity ratios. The description is purely a formula, leaving the agent to infer context.

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 and idempotentHint=true, so the description need not repeat those. It adds the mathematical relationship (coupon as a percentage of current price), which is useful behavioral context beyond the annotations, though it does not discuss edge cases like zero price.

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

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

The description is a single, front-loaded sentence that directly states the calculation. Every word earns its place, with no filler or redundancy.

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

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

Given the tool's simplicity, full schema coverage, and presence of an output schema and readOnly/idempotent annotations, the description adequately defines the calculation. No additional behavioral or return-value context is necessary.

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

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

Schema coverage is 100% with all three parameters described. The description reinforces that couponRatePct is an annual rate and price is the current price, but it does not add new parameter-level details beyond the schema.

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

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

The description clearly defines the tool's purpose: 'Current yield: the annual coupon as a percent of the bond's current price.' This specific formula-based definition distinguishes it from sibling tools like yield-to-maturity and bond-price.

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

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

The description implies the tool is for calculating current yield but provides no explicit guidance on when to use it versus alternatives such as yield-to-maturity or bond-duration. There are no stated exclusions or comparative context.

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 description details the calculation components (25% rate above allowance, 5.5% Soli, no Freigrenze, church tax reduced rate), going well beyond the annotation hints (readOnly, idempotent). This provides a clear behavioral model of how the tax is computed, including the treatment of church tax.

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 at two sentences, front-loading the tax type and scope before diving into rates. Every sentence contributes substantive tax rule information without redundancy or 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?

Given the complexity of German capital gains tax and the presence of a full output schema and annotations, the description provides sufficient context on the tax rules, rates, allowance, and church tax effects. It explains the core calculation intent without needing to describe return values.

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?

All five parameters are already fully described in the input schema (100% coverage), so the description adds little parameter-specific meaning. The mention of the Sparerpauschbetrag and church tax rates aligns with parameters, but the schema already carries this information.

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 identifies the tool as computing Germany's flat tax on capital income (Abgeltungsteuer), citing the legal provision (§32d EStG) and specifying the applicable tax years (2023-2026) and the built-in Sparerpauschbetrag. This distinguishes it from other German tax tools like de-net-salary or tax-from-brackets.

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 use for German capital gains tax calculations but does not explicitly state when to use this tool versus alternatives like de-net-salary or tax-from-brackets. It only constrains applicability to tax years 2023-2026, leaving usage guidance implicit.

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 readOnly and idempotent. The description adds behavior context: it returns months, total interest, payoff order, and flags insolvent budgets, plus explains the effects of each method ('avalanche minimizes interest, snowball clears accounts soonest'). No contradiction with 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?

The description is two sentences, front-loads the core purpose and includes only essential details about methods and output. Every clause adds value; no redundant 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?

Given the output schema exists and annotations cover safety, the description provides sufficient behavioral details (return values, insolvency flag, method effects). It could mention that insolvency occurs when budget falls below minimum payments, but that's inferable.

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 descriptions cover all 3 parameters (100%). The tool description adds meaning to the 'method' parameter by explaining the strategic trade-off (avalanche vs snowball) and clarifies the role of the fixed monthly budget, going beyond the enum and schema text.

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

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

The description clearly states the tool's purpose: creating a multi-debt payoff plan under a fixed monthly budget, with methods and outputs. It distinguishes from siblings like credit-card-payoff by focusing on multi-debt scenarios and named strategies.

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 phrase 'multi-debt payoff plan' – it's for tackling more than one debt. However, it doesn't explicitly note when not to use it or point to alternatives such as credit-card-payoff or loan-payoff for single-debt cases.

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 and idempotentHint, so the safety profile is covered. The description adds the output details (depreciation and remaining book value) and the 'for a given year' scope, but does not disclose edge cases or assumptions. No contradiction.

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 concise sentences front-load the method and output without any filler. Every phrase adds value.

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

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

For a simple calculator tool with well-documented schema and an output schema, the description is sufficient. It specifies the method, the year scope, and the return values. Missing explicit edge-case handling but not required.

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

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

The input schema provides complete descriptions for all three parameters (value, ratePct, year) at 100% coverage. The description adds the conceptual context of 'fixed percent of reducing book value' but no additional syntax or format specifics.

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

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

The description clearly states the tool computes declining-balance depreciation using a fixed percentage of reducing book value for a specified year and returns both that year's depreciation and remaining book value. This specific method definition distinguishes it from sibling tools like straight-line or double-declining.

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 usage by defining the method, but does not explicitly state when to choose this over alternatives such as straight-line-depreciation or double-declining-depreciation. It lacks explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: income tax and Soli are amounts, church tax is a percent of income tax, and social rates/ceilings are explicit inputs. It also clarifies the manual model. No contradiction with 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?

The description is only two sentences. The first sentence states the purpose, and the second covers the manual-input requirement, the input types, and unit consistency. Every word earns its place, with no redundancy.

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

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

For a 10-parameter tool, the description adequately explains the external figures needed, the relationships among inputs, and the unit consistency requirement. The output schema covers the return structure, so the description doesn't need to detail outputs. It could mention calculation order or edge cases, but the provided context is sufficient for an agent to select and invoke the tool 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 100%, so each parameter is already described. The description adds meaning by grouping 'the four employee social rates and the two contribution ceilings' and clarifying the type relationships (e.g., church tax as percent of income tax, income tax as amount). This goes beyond the individual parameter descriptions.

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

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

The description states 'German net (Netto) salary from gross (Brutto)' with a specific verb and resource, and the title adds 'manual figures,' which distinguishes it from the sibling 'de-net-salary.' The purpose is explicit and 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?

The description gives clear when-to-use context: 'No tax tables are baked in: look up the current year's statutory figures and pass them in.' It also advises 'Use consistent units.' However, it stops short of explicitly naming an alternative tool like 'de-net-salary,' so it earns a 4 rather than 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?

The annotations (readOnlyHint, idempotentHint) already establish a safe read operation, and the description adds meaningful context by explaining that the amount is a flat monthly rate per child (uniform since 2023) and that outputs include monthly and annual totals. This goes beyond the annotations without contradicting them.

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

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

The description is a single, front-loaded sentence that conveys the tool's purpose and key scope without redundancy. Every word earns its place, making it highly concise and well-structured.

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

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

For a simple two-parameter calculator with a known output schema, the description is complete enough. It covers the essential input range (2023-2026), per-child applicability, and output measures (monthly and annual totals), though it does not delve into potential edge cases or output formatting details, which are handled by the schema.

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

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

The schema provides descriptions for both year and children, covering 100% of parameters. The description adds value by clarifying that the benefit is per child and specifying the output structure (monthly and annual totals), which enriches the interpretation of the children parameter and the tool's behavior.

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 identifies the tool as providing German child benefit (Kindergeld) amounts for 2023-2026, specifying per-child monthly and annual totals. It distinguishes itself from sibling financial calculators by focusing on this specific benefit and noting the uniform rate since 2023.

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 guidance or alternative tools are mentioned. However, the description implies its usage context by clearly naming the Kindergeld calculator and its parameters, making it distinguishable by domain. The absence of explicit exclusions or alternatives leaves room for improvement.

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 indicate readOnly and idempotent hints. The description adds value by revealing the classification logic (Minijob/Midijob/regular), use of year-specific thresholds and Faktor F, and the employee/employer split—without contradicting the annotations. It does not go into every nuance (e.g., age/child effects), but those are visible in the schema, so no contradiction or major omission.

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

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

The description is a single dense sentence that packs the subject, scope, core actions, and legal reference without fluff. Every phrase contributes: the tool name is not merely restated, and the sentence front-loads the key concept 'Midijob/Uebergangsbereich' before detailing computation. This is concise and well-structured.

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 German payroll tool with 7 params and an output schema, the description is complete enough: it explains the classification and computation behaviors, and the schema covers parameter meanings and return structure. It does not explicitly mention edge cases (e.g., age-related surcharge) but those are in the schema. Slightly less than perfect because it could briefly note that results depend on optional parameters, but core context 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 100%, so the baseline is 3. The description does not add detailed parameter-specific semantics beyond mentioning 'year's rates' and 'Faktor F'; individual params like age, children, bundesland are only explained in the schema. Thus, it neither hurts nor significantly improves parameter understanding beyond the structured schema.

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

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

The description clearly states a specific verb+resource: it classifies monthly pay as Minijob/Midijob/regular and computes contribution bases and splits. It references the legal basis (§20 Abs. 2a SGB IV) and explicitly covers 2023-2026, distinguishing it from generic calculators like 'contributions' or 'de-net-salary'.

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 context: it is for German Midijob/Uebergangsbereich calculations for 2023-2026, including classification against thresholds and computing Faktor F. It implies when to use it (when pay falls in the transition band) but does not explicitly name alternatives or exclusions among sibling tools. This matches 'clear context, 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 mark the tool as read-only and idempotent. The description adds valuable behavioral details beyond annotations: the official BMF Programmablaufplan, 2024 retroactive tariff spec, church tax base, social insurance ceilings, and the Zusatzbeitrag default. It also notes rejection of earlier years. This goes beyond the annotation basics, though it doesn't detail output structure (covered by output 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?

The description is a single dense sentence with a follow-up sentence for the alternative tool. It front-loads the main purpose and packs in crucial details without waste. It's slightly longer than ideal but every clause carries information, earning a 4.

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

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

Given the tool's complexity (11 parameters, nested object, output schema), the description covers the essential context: tax year range, official method, regional/status defaults, and the rejection of out-of-range years. The output schema covers return values, so the description needn't explain those. It could mention a few more edge cases, but overall it's complete enough.

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 91%, so the schema already documents most parameters thoroughly. The description mentions one parameter default (KV Zusatzbeitrag average) which is already in the schema, but does not add significant extra meaning beyond schema. Baseline 3 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 states the tool computes exact German net salary from annual gross for tax years 2023-2026, using specific official methods. It clearly distinguishes from the sibling de-gross-to-net by noting that earlier years are rejected and directing users to that tool with self-supplied figures.

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 when to use (for exact official calculations in 2023-2026) and explicitly names the alternative (de-gross-to-net) for rejected years. This provides clear when-to-use and when-not-to-use guidance.

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

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

The description explains the behavioral trait of compounding (down or up) at a yearly rate, which goes beyond the annotations that only indicate read-only and idempotent. It clarifies that the tool can both depreciate and appreciate based on the 'up' parameter, adding useful context. There is no contradiction with the annotations, and the description enriches the safety profile with method details.

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

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

The description is two sentences long and front-loaded with the core behavior. Every word contributes: the first sentence states the calculation and the second gives application context. No redundancy or fluff, making it highly concise and well-structured.

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 simple read-only calculation with a complete output schema, and the description explains the core method and typical use case (long-term assets). It does not need to explain return values since the output schema exists. It could mention edge cases (e.g., negative rates) but given the simplicity and available schema, it is sufficiently complete.

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

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

The input schema already documents all parameters with clear descriptions, achieving 100% coverage. The description does not add new individual parameter meaning beyond the schema, but it does provide a high-level formula context (compounding down/up over years). Since the schema handles the heavy lifting, the baseline of 3 is appropriate.

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

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

The description clearly states what the tool computes: "Value after compounding down (or up) at a yearly percentage rate over a number of years." It identifies the resource (a financial value) and the method (compounding), and distinguishes it from other depreciation methods (e.g., straight-line, declining-balance) by mentioning the ability to appreciate. However, it lacks an explicit verb like 'calculates' or 'computes,' which prevents a top score.

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

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

The description provides some usage context with "This is the method the app uses for long-term assets," implying when to use it. However, it does not explicitly compare to alternatives or state exclusions (e.g., when not to use it or which sibling to use instead). The guidance is implied rather than explicit, so it earns a middle score.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: the contribution ceiling cap and the fact that the aktueller Rentenwert can differ for the two halves of the year. It also clarifies that an optional total points input projects the gross monthly pension, which is not evident from annotations alone.

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

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

The description is a single, dense sentence that packs the legal reference, year range, calculation logic, and optional function. It is front-loaded with the core purpose and avoids redundant filler. However, it includes several technical German terms (Entgeltpunkte, Durchschnittsentgelt, aktueller Rentenwert) that may add cognitive load, keeping it just below 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?

The tool is a straightforward calculator with 4 parameters and an output schema, so the description does not need to explain return values. It covers the key calculation aspects (ceiling cap, half-year Rentenwert) and the optional projection mode. It is complete enough for a typical agent to use correctly, though it could mention edge cases like invalid years, but the schema already constrains valid years.

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

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

The input schema already covers all parameters with clear descriptions (100% coverage). The description adds formula-level context (e.g., contribution ceiling, Durchschnittsentgelt) that helps interpret grossAnnual and year, but it does not significantly expand on parameter semantics beyond what the schema provides. This aligns with the baseline score of 3.

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 identifies the tool as a calculator for German pension points (Entgeltpunkte) across 2023-2026, specifying the formula inputs (gross salary, Durchschnittsentgelt, contribution ceiling, aktueller Rentenwert). It is specific about the resource and scope, but lacks an explicit verb like 'calculate' or 'compute', which slightly lowers the score.

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 usage through the year range and the optional totalPoints parameter for pension projection, but it does not explicitly contrast with alternative tools or state when to use this tool versus others (e.g., de-net-salary). The legal reference and German-specific terminology strongly imply a niche use case, but no exclusions or alternative guidance is given.

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 and idempotentHint=true, covering the safety profile. The description adds the concrete output details (amount off and final price), which are not revealed by annotations or schema alone, giving useful behavioral transparency 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?

The description is a single, front-loaded sentence that conveys the tool's purpose and outputs without any wasted words. Every phrase contributes meaning, achieving excellent conciseness.

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

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

For a simple two-parameter financial calculator, the description covers the essential purpose and outputs. The presence of an output schema (though not shown) reduces the need to detail return values. It misses edge-case handling (e.g., percent as fraction vs. whole), but this is not a critical gap for such a tool.

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

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

Schema coverage is 100% (price and discountPct both have descriptions). The description does not add any further parameter-specific meaning, but since the schema fully documents the parameters, a baseline of 3 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 explicitly states the tool computes a single percentage discount and reports both the amount off and the final price. The word 'single' distinguishes it from the sibling tool 'successive-discounts', making its purpose 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?

The description clearly implies use for one discount rather than multiple/layered discounts. It does not explicitly name an alternative tool (e.g., successive-discounts), but the 'single' qualifier provides contextual guidance without excluding edge cases.

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 and idempotentHint=true, so the safety profile is clear. The description adds the key behavioral detail that each cashflow is discounted at the per-period rate, which is not covered by annotations or schema. This goes beyond the basic structure, though it does not elaborate on return behavior, which is acceptable given the output 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?

The description is a single sentence that immediately names the tool's purpose and its key differentiator from a sibling. It is concise, front-loaded, and contains no redundant or unnecessary content.

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 straightforward calculation tool with a complete input schema, an output schema, and annotations covering read-only and idempotent behavior, the description provides sufficient context. It also names the alternative tool. No critical gaps remain.

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

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

Schema description coverage is 100% with clear descriptions for ratePct, cashflows, and initialCost. The tool description does not add significant parameter-level meaning beyond the schema, but it indirectly aligns 'ratePct' with the 'per-period rate' mentioned. Baseline 3 is appropriate given the high schema coverage.

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 that the tool calculates the discounted payback period and explicitly distinguishes it from the sibling tool 'payback-period' by noting that each cashflow is discounted at a per-period rate. This provides a specific verb, resource, and key differentiator.

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 'like payback-period but...' directly references an alternative tool and specifies the difference, telling the user when to choose this tool (when discounting is needed) versus payback-period. This is explicit usage guidance with an alternative named.

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 and idempotentHint, so the description does not need to repeat those safety traits. It adds value by specifying the return values (units accumulated, total invested, average cost, final value), which goes beyond the bare schema. No contradictions with 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?

The description is two short sentences, front-loaded with the core concept and followed by the outputs. No unnecessary words or repetition.

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

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

For a simple two-parameter tool with full schema coverage and an output schema available, the description is sufficient. It states the input pattern and the calculated results, making the tool's behavior clear. The presence of an output schema means return value details do not need to be exhaustively repeated.

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 descriptions cover both parameters fully (price at each period and fixed investment amount). The description does not add additional parameter-level detail beyond restating the concept, so the baseline score of 3 applies given the 100% schema coverage.

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 that the tool calculates dollar-cost averaging by buying a fixed amount each period at the given prices, and lists the computed outputs (units accumulated, total invested, average cost, final value). This specific verb+resource distinguishes it from the many other financial calculators in the sibling list.

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 explains the concept of dollar-cost averaging but does not explicitly state when to use this tool over alternatives such as future-value or compound-interest. It implies usage for DCA calculations but lacks explicit exclusions or alternative suggestions.

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 provide readOnlyHint and idempotentHint, so safety is covered. The description adds behavioral details beyond annotations by explaining the calculation algorithm and the salvage floor, which is essential for understanding how depreciation stops.

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

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

The description is a single sentence that efficiently communicates the method, formula, and constraint without any redundant words. It is front-loaded with the method 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?

Given the output schema and complete parameter descriptions, the description is sufficient. It explains the algorithm and the salvage floor. Minor ambiguity about year semantics is resolved by the schema, making the tool well-specified.

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

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

The schema already documents all parameters, but the description adds meaning by showing how value, usefulYears, and salvage are used in the formula. However, 'year' is not explicitly tied to the formula in the description, though the schema clarifies it is 1-based.

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 it computes double-declining-balance depreciation with a specific formula (2/usefulYears of book value) and a salvage floor. This directly distinguishes it from sibling depreciation calculators like straight-line or sum-of-years-digits.

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 tool name and description make it obvious when to use this tool: for double-declining-balance depreciation calculations. It does not explicitly mention alternatives or exclusions, but the method is well-defined and the context is clear.

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=true and idempotentHint=true, so the safety profile is clear. The description adds the computational behavior (division), but does not disclose edge-case handling such as division by zero when annualDebtService is zero.

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

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

The description is a single, compact sentence that defines the ratio and the calculation. Every word contributes meaning, with no redundancy or unnecessary detail.

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

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

For a simple, deterministic financial calculation, the description fully conveys the purpose and computation. The presence of an output schema covers return values, and the two parameters are clearly defined, so no additional context is necessary.

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

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

The schema descriptions fully cover both parameters, providing baseline clarity. The tool description adds value by specifying the relationship between the parameters (NOI divided by annual debt service), making the numerator/denominator roles explicit beyond the individual parameter descriptions.

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

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

The description clearly defines the tool as the debt service coverage ratio and explicitly states the formula (net operating income divided by annual debt service). This distinguishes it from sibling tools like 'noi' and 'cap-rate' by specifying the exact computation and 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 description provides no guidance on when to use this tool versus alternatives. There is no mention of typical use cases (e.g., evaluating loan risk) or exclusions, leaving the agent to infer context from the formula 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?

The formula itself is a strong behavioral disclosure: it tells the agent exactly how the calculation is performed. Combined with the annotations (readOnlyHint=true, idempotentHint=true), this gives a complete safety profile. The only missing piece is edge-case handling (e.g., zero income), but the explicit formula covers the core behavior beyond what annotations provide.

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

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

The description is a single, succinct line that states the output unit and the formula. No filler words, no redundant content. It is immediately readable and front-loaded with the core concept.

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

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

For a simple calculation tool, the description provides the essential purpose, formula, and output unit. The output schema exists, so return values are documented elsewhere. It lacks usage context (covered in dimension 2), but overall it gives enough information for basic selection and invocation.

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 already provides 100% coverage with clear descriptions for monthlyDebt and grossMonthlyIncome. The description adds relational meaning by showing how the parameters interact (numerator and denominator) in the ratio, which goes beyond the individual schema descriptions and clarifies their purpose.

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 explicitly defines the debt-to-income ratio as a percentage with the exact formula (monthly debt / gross monthly income). This is specific, unambiguous, and clearly distinguishes it from sibling financial ratio tools like LTV, DSCR, and cap-rate.

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 usage guidance is provided. The description does not indicate when to use this tool (e.g., loan qualification assessments) or how it compares to alternatives such as mortgage-affordability or debt-payoff. The agent is left without context for selecting it over similar calculators.

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 and idempotentHint=true, covering safety and idempotency. The description adds behavioral context by explaining the compounding-frequency dependency and the toNominal flag, making the transformation logic transparent. No contradictions or hidden side effects.

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

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

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys both conversion directions and key parameter roles, earning its place without waste.

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 two required parameters, the description covers the primary use cases and the reverse operation. No missing information that an agent would need to select and invoke this tool 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 100%, so parameters are well-documented. The description adds meaning by explaining that ratePct is interpreted as nominal or effective depending on toNominal, and that periodsPerYear is the compounding frequency. This exceeds the baseline for high schema coverage.

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

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

The description clearly states the tool converts a nominal annual rate to the effective annual rate (APY) for a compounding frequency, and also supports the reverse with toNominal. It uses a specific verb ('Convert') and resource, distinguishing it from sibling tools like compound-interest or after-tax-yield.

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

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

The description provides clear context for when to use the tool (nominal-to-effective or effective-to-nominal conversion) but does not explicitly exclude alternatives or name sibling tools. The dual-mode explanation gives strong guidance without being as explicit as a full when/when-not 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 declare readOnlyHint and idempotentHint, and the description adds the precise arithmetic operation without contradicting those hints. It does not disclose edge-case behavior (e.g., zero monthly expenses), but for a pure calculator, the formula plus annotations are sufficient.

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

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

The description is a single front-loaded sentence with no filler or redundant detail. It efficiently states the output concept and the formula.

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-number calculator with both inputs fully documented, an output schema present, and read-only/idempotent annotations, the description fully conveys the calculation and result semantics. No significant missing information.

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

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

Schema coverage is 100% with both parameters described, so the baseline is 3. The description goes beyond the schema by explaining the relationship between the parameters (division) and the output interpretation ('months of runway'), adding meaningful semantic value.

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 explicitly explains that the tool computes 'months of runway' as liquid savings divided by monthly expenses. This makes the function unmistakable and distinct from sibling financial calculators.

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 guidance or alternative references are provided; the use case is implied only through the formula. There is no mention of scenarios where this metric is appropriate or when to prefer other tools.

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 the tool as read-only and idempotent. The description adds context about the computational approach (comparing gross vs net balances and the fee loss), which is valuable. No contradiction exists, and the description does not omit any major safety or behavioral caveats.

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

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

The description is a single, well-structured sentence that leads with the core purpose ('Effect of an annual fee') and efficiently explains the outputs. Every word contributes meaning; there is no redundancy or 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?

Given the tool's simplicity, a fully documented schema, and the presence of an output schema, the description is sufficiently complete. It conveys the essential outcome without needing to elaborate on return formats or assumptions.

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

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

The input schema provides 100% coverage with clear descriptions for all four parameters (principal, grossAnnualPct, feePct, years). The description does not add parameter-specific details beyond what the schema already contains, so it does not exceed the baseline for high schema coverage.

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

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

The description clearly states the tool's function: it calculates the effect of an annual fee on a compounded balance, comparing gross vs net growth and quantifying the amount lost to fees. This specific verb-resource combination distinguishes it from siblings like compound-interest or cagr.

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

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

The description implies the use case (when you want to see the impact of annual fees on investment growth) but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Sibling tools like compound-interest are not mentioned, so the guidance is only implicit.

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 indicate read-only and idempotent behavior. The description adds the 'No advice' disclaimer and explains the computational outputs (gap and years to reach), providing useful context beyond what annotations convey. It does not discuss error handling or edge cases, but the safety profile is well-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 a single, well-structured sentence that captures the tool's purpose, key inputs, default, and outputs, followed by a concise disclaimer. Every word earns its place, with no redundancy or excessive detail.

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 a complete schema, annotations, and an output schema present, the description adequately covers the tool's purpose and core outputs. It could mention limitations or assumptions beyond the default 4% rule, but the provided information is sufficient for an agent to use the tool correctly in most scenarios.

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 descriptions cover 100% of parameters, providing a solid baseline. The description adds meaning by synthesizing how parameters interact: 'gap from today' implies comparison with currentNestEgg, and 'years to reach it' uses annualContribution and growth. This goes beyond individual property descriptions to clarify the calculation flow.

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

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

The description clearly states the tool calculates a FIRE target nest egg from annual spend and safe withdrawal rate, plus the gap from today and years to reach it. This specific verb+resource with default rate distinguishes it from sibling calculators like barista-fire and coast-fire.

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

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

The description provides clear context for when to use the tool (standard FIRE calculation) by specifying inputs and outputs. It does not explicitly exclude alternatives or mention sibling tools, but the unique combination of nest egg, gap, and years-to-target gives enough guidance for an agent to select it over similar calculators.

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 and idempotentHint=true, so safety is known. The description adds key behavioral context by specifying 'compounded annually' and 'single lump sum', which define the calculation scope beyond the annotations. It does not detail edge cases, but the output schema exists to cover return format.

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

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

The description is a single sentence, extremely concise, and directly front-loaded with the key concept. Every word is meaningful, and there is no redundancy or 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 simple financial calculator with full schema coverage, a complete output schema, and annotations indicating safety, the description adequately captures the tool's purpose. It does not explain return values, but the output schema handles that, and the annual compounding detail is sufficient for the intended use.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds contextual meaning by clarifying that principal is a one-time lump sum and compounding occurs annually, which complements the parameter descriptions without adding syntax or format details. No additional parameter-level information is provided.

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 indicates the tool computes the future value of a single lump sum with annual compounding, distinguishing it from annuity or present-value calculators. However, it lacks an explicit action verb such as 'calculate' or 'compute', relying on the noun phrase 'Future value of a single lump sum'.

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 usage for a single lump sum with annual compounding, but it does not explicitly state when to use this tool over alternatives like annuity-fv or present-value. No exclusions or alternative tool references are provided, leaving the guidance implicit rather than direct.

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 and idempotentHint=true, but the description adds valuable behavioral context by stating that the rate is supplied by the caller and that no rate lookup is performed. This goes beyond the annotations to clarify the tool's pure calculation nature.

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

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

The description is two concise sentences with no redundant wording. It is front-loaded with the action ('Convert an amount') and efficiently communicates the key scope constraint ('No rate is ever looked up').

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 simple with only two parameters, both fully documented in the schema, and an output schema is present. The description, combined with annotations and schema, provides complete context for correct usage. No additional details like rounding or edge cases are necessary for this straightforward 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?

The schema already provides 100% parameter description coverage, so the baseline is 3. The description restates the rate unit meaning ('units of target currency per unit of source') which is already in the schema's rate description, adding no new semantic information beyond what the schema provides.

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

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

The description clearly states the tool converts an amount using a caller-supplied rate, which is a specific verb+resource. It distinguishes itself from siblings by emphasizing that no rate lookup occurs, which is unique among the financial calculation tools.

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

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

The description clearly implies when to use this tool: when you have a rate and want to convert. The phrase 'No rate is ever looked up' provides an exclusionary guideline, signaling that this tool is not for rate retrieval. However, it does not explicitly name alternatives or provide explicit when-not-to-use 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe, non-mutating operation. The description adds the exact computation behavior, which is the core of this tool. It does not mention edge cases like zero rent, but the annotation coverage lowers the burden.

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

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

The description is a single sentence, 'Gross rent multiplier: price divided by gross annual rent.' It is front-loaded, contains no filler, and every word 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?

Given the tool's simplicity (two numeric inputs, one formula), the description, combined with the rich schema, annotations, and output schema, provides complete context. No additional guidance is necessary for correct use.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds the relationship between them ('price divided by gross annual rent'), clarifying the role of each parameter in the calculation beyond simple type definitions.

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 the formula 'price divided by gross annual rent', which is a specific calculation and clearly differentiates the tool from siblings. It is concise and unambiguous, though it does not explicitly name alternative tools.

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

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

No guidance is provided on when to use this tool vs. alternatives like cap-rate or cash-on-cash. The description only gives the formula, with no context about appropriate use cases.

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 and idempotentHint=true. The description adds the exact formula and output unit ('in percent'), which is valuable behavioral context beyond the annotations. It does not contradict 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?

The description is a single sentence with a compact formula. No wasted words, information is front-loaded, and it is immediately actionable.

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 and 100% parameter coverage, the description is mostly sufficient. However, the formula references 'capital gain' without explicitly stating it equals endValue - beginValue, leaving a minor ambiguity in how inputs map to the calculation. Also, no mention of edge cases (e.g., zero starting value) is made.

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