EveryCalc

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description needn't repeat safety traits. Beyond that, it discloses calculation behavior (annual compounding, a $24,500 employee contribution cap, employer match) and a critical output-handling requirement: the calculator_url must be shown as a clickable markdown link. It does not cover error handling or validation edge cases, which keeps it from a 5.

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

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

The description is three tight sentences plus a clearly marked IMPORTANT instruction. The purpose is front-loaded, the alternatives are named early, and the output instruction is separated for emphasis. Every sentence carries information needed to select or correctly use the tool.

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

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

Although an output schema exists, the description still highlights the calculator_url and how to present it, which is not captured in the output schema. It also covers calculation methodology, when to use the tool, and alternatives. For a 7-parameter financial calculator with rich annotations, this is complete enough for correct 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 description coverage is 100%, so the schema already documents all seven parameters, setting the baseline at 3. The description adds domain meaning beyond the schema: the $24,500 annual employee contribution cap, the presence of an employer match, and annual compounding. It does not explain how match_pct and match_cap_pct interact, but the extra cap rule justifies a 4.

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

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

The description states a specific verb and resource: projecting a 401k balance with employee contributions and an employer match, compounded annually. It explicitly differentiates from siblings by naming calculate_compound_interest for general investment projections and calculate_tsp for TSP. An agent can select this tool correctly without opening the schema.

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

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

It gives explicit when-to-use guidance ('Use when the user projects a 401k with contributions and an employer match') and concrete alternatives for when not to use it ('calculate_compound_interest', 'calculate_tsp'). The instruction to show the calculator_url is an additional output-handling guideline that further constrains proper usage.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: inputs are clamped to 1-36, the composite is the rounded average of the four sections, and the result's calculator_url must be surfaced as a clickable markdown link.

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

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

Three tight sentences, front-loaded with what is computed before the usage condition and the output-link instruction. Every sentence carries load, though the IMPORTANT-caps link directive is slightly verbose in phrasing.

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

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

An output schema exists, so return-value documentation is unnecessary. For a simple deterministic 4-input calculator with full annotation coverage, the description supplies everything needed to call it correctly, though it does not explain how STEM and ELA are derived (a minor omission).

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% and all four required section parameters are documented in the schema itself. The description restates the clamping/rounding rule, which marginally reinforces the schema but adds no format or range information beyond it. Baseline 3 applies when 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?

States a specific verb+resource: computes ACT composite, STEM, and ELA scores from the four section scores. This clearly separates it from adjacent siblings such as calculate_sat_score, calculate_psat_score, and calculate_ap_exam_score, which target different exams.

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?

"Use when the user has ACT section scores and wants the composite, STEM and ELA scores" gives a clear triggering condition. It does not name an alternative tool or state when-not to use it, but the condition is unambiguous enough that an agent won't misroute.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description is not burdened there. It adds real value by disclosing the 28/36 methodology and an output-handling requirement (surface calculator_url as a clickable markdown link), which is behavior the schema and annotations do not convey.

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

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

Three tight sentences, front-loaded with purpose then usage then the output directive. Every sentence earns its place, including the IMPORTANT callout which is a genuine invocation requirement.

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

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

With an output schema present, return values need no explanation, and the description covers purpose, trigger, sibling disambiguation, methodology, and output presentation. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so all seven parameters including ratio defaults are documented in the schema. The description adds no syntax, units, or format detail beyond what the schema provides; the 28/36 mention only indirectly maps to front_ratio_pct/back_ratio_pct. 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?

States a specific verb (calculate) and resource (max affordable home price) plus the methodology (28/36 rule), and explicitly distinguishes itself from calculate_mortgage. An agent can tell it apart from the large sibling list without opening any schema.

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

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

Gives an explicit trigger (user asks how much house they can afford on their income) and names the alternative (calculate_mortgage) with the condition that selects it (payment on a specific price). Nothing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds real domain behavior beyond them: sex-neutral combat scoring, the 350-total combat threshold, the 60-per-event minimum, and a mandatory output instruction to surface calculator_url as a clickable markdown link. It does not describe how invalid or out-of-range inputs are handled.

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

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

Four sentences, front-loaded with the scoring model and thresholds before the usage trigger and the output instruction. Dense but each sentence carries distinct information; the all-caps IMPORTANT block is slightly heavy but warranted since the link requirement is easy for an agent to drop.

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?

Inputs, scoring scale, pass/fail thresholds for both standards, and the required user-facing output link are all covered, and an output schema exists so return values need not be re-explained. An agent has everything needed to call it and present the result 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% and every parameter (sex, standard, push_ups, run_time, plank_time, deadlift_lbs, sprint_drag_carry_time) is already documented, including the m:ss-or-seconds alternative. The description clarifies that combat scoring is sex-neutral, which touches the sex and standard parameters, but that fact is essentially restated from the schema, so the baseline 3 is right.

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

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

States a precise verb and resource ('Scores all five AFT events... from 0 to 100 each... for a 500-point total') and enumerates the exact events scored, so it is unmistakable among dozens of sibling calculate_* tools. The scoring model (17-21 anchor tables) further pins down what the tool actually computes.

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

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

Gives a clear trigger: 'Use when a soldier provides Army Fitness Test event results and wants the scores and pass or fail.' No sibling tools overlap in domain, so an explicit 'do not use for X' clause is unnecessary, but the description stops short of stating what happens with partial or missing event data.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context beyond annotations: the specific outputs produced and a mandatory post-call action (surface calculator_url as a markdown link), which is behavioral guidance an agent could not infer from structured fields.

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

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

Front-loads purpose, then usage, then the alternative, then the URL instruction — a sensible order. Slightly marred by the redundant phrase 'interactive age calculator calculator' and a somewhat long trailing directive.

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

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

An output schema exists, so return values need not be re-explained; the description still summarizes them usefully. Combined with annotations, a named alternative, and the calculator_url rendering rule, an agent has everything needed to call and present the result 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%, so both birth_date and target_date semantics (format, default of today) are fully documented in the schema. The description adds no syntax or format detail beyond that, making the baseline 3 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?

States a specific verb (calculate) and resource (exact age from a birth date to a target date) and enumerates the output breakdown, which distinguishes it from the many other calculate_* siblings. The named sibling calculate_date_duration makes the boundary explicit.

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 says when to use it ('user asks an exact age from a birth date, or days lived') and names the alternative with its selecting condition ('For a plain span between two dates use calculate_date_duration'). Nothing is left to inference.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds real behavioral value by disclosing the composite weighting/banding logic and, importantly, that the result carries a calculator_url that must be surfaced as a clickable markdown link.

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

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

Front-loads the prediction, then methodology, then usage, then the IMPORTANT link instruction. Information-dense and each sentence serves a purpose, though the methodology sentence is heavy enough that it borders on crowding the core routing signal.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description still adds the crucial output-handling instruction about calculator_url. It is complete for calling and correctly rendering the tool, with only minor room for explicit sibling contrast.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the mc_weight_pct presets and defaults. The description reinforces the exam-split weighting concept but names no parameter explicitly, so 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?

States a specific verb and resource ('Predicted AP score from 1 to 5') and even names the resource ('AP exam') that separates it from sibling score calculators like calculate_sat_score and calculate_act_score. The banding methodology ('banded at 70, 55, 40, and 25 percent') further pins down what the tool computes.

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?

'Use when the user estimates an AP exam score from multiple choice and free response results' gives a clear triggering context. It stops short of explicitly naming alternatives or exclusions (e.g., use calculate_sat_score for the SAT), so it is strong but not fully routing.

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

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

Annotations already declare this a safe, idempotent, non-destructive read, and the description does not contradict them. On top of that it discloses a non-obvious output-behavioral requirement: the result contains a calculator_url that must be surfaced as a clickable markdown link, which the agent cannot learn from the schema alone. It stops short of describing return shape beyond the headline figures, but an output schema exists.

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

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

Three sentences, each doing distinct work: capability, routing to the alternative, and the mandatory link-output instruction. Front-loaded with the tool's scope and zero 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 read-only calculator with a full output schema, the description covers scope, the sibling alternative, and the one post-processing obligation (surfacing calculator_url). Nothing an agent needs in order to select and invoke it correctly is missing.

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

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

Schema description coverage is 100%, so all nine parameters (loan amount, fixed/ARM rates, caps, adjustment period, term) are already fully documented in the schema. The description adds no syntax or constraint detail beyond what the schema provides, so the 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 first sentence names a specific verb (simulation) and resource (worst-case ARM with rate caps vs. a fixed-rate loan) and enumerates the outputs: total interest, payments, breakeven year. It is immediately distinguishable from the generic calculate_mortgage sibling, which it explicitly names.

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

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

It states the triggering scenario (user compares an ARM with a fixed loan, including the worst case) and names the alternative tool (calculate_mortgage) for the standard fixed-payment case. Both the when-to-use and when-not-to-use conditions are 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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real behavioral value beyond that: it enumerates what the result contains and imposes a required downstream action (always render the calculator_url as a clickable markdown link). The only gap is that it never mentions the include_schedule parameter's effect on the response.

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?

Content is front-loaded: outputs first, then usage, then alternatives, then the mandatory URL instruction. The only waste is the duplicated phrase 'auto loan calculator calculator', which reads as an editing artifact in an otherwise tight description.

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

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

An output schema exists, so return values need not be documented, and the description still summarizes them for routing purposes. Combined with usage routing, sibling disambiguation, and the mandatory URL-presentation instruction, an agent has everything needed to call this tool and act on the result.

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 would be 3, but the description goes further by explaining how the optional inputs interact — down payment and trade-in are subtracted from the vehicle price to produce the amount financed. That clarifies the semantics of trade_in and down_payment beyond their bare 'value in USD' 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 names the exact outputs (monthly payment, amount financed, total interest, total cost) and the computation basis (price minus down payment and trade-in), which is far more specific than the tool name alone. It also explicitly distinguishes itself from two siblings, calculate_car_affordability and calculate_lease_vs_buy, so an agent can route correctly without opening any schema.

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

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

It states the triggering condition ('when the user is financing a car purchase and wants the payment and total interest') and names the two nearest alternatives with the conditions that select them (budget fit vs. leasing). This is explicit when-to-use plus when-to-use-something-else 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?

While annotations cover safety (readOnlyHint), the description provides vital behavioral constraints that structured fields cannot convey. Specifically, it clarifies that this is a 'single national baseline rate' and 'does not vary by duty station or ZIP code,' managing user expectation about data limitations.

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 structure is effective, moving from definition to scope, to usage guidance, and concluding with necessary warnings and operational instructions. It is slightly lengthy due to the operational instructions, but highly informative.

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 military financial calculations, the definition is extremely complete. It defines the inputs, clarifies the scope (national baseline), and instructs the agent on the expected output behavior (displaying the calculator_url as a markdown link).

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?

Since the input schema provides 100% coverage with detailed enums and descriptions, the description meets the baseline standard. It reiterates the context of the inputs (pay grade and dependency status) but does not provide unique semantic meaning beyond what the schema already defines.

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 is highly specific, stating the tool calculates the 'Monthly Basic Allowance for Housing from the 2026 RC/Transient baseline rate table.' Crucially, it distinguishes itself from the sibling tool, calculate_military_pay, by defining its narrow scope.

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 usage guidelines are explicit, directing the agent to use the tool only 'when the user needs a Basic Allowance for Housing baseline rate by pay grade and dependency status.' It also clearly states when an alternative should be used: 'For total monthly military pay use calculate_military_pay.'

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

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

Annotations already cover read-only, idempotent, and non-destructive status, so the safety profile is settled. The description adds real value by mandating that the calculator_url from the result be rendered as a clickable markdown link, which is behavior an agent cannot infer from the schema.

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

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

Three tight sentences, with the purpose front-loaded and the output directive clearly marked. The all-caps 'IMPORTANT' is slightly loud but the sentence earns its place.

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

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

Output schema exists, so return values need not be explained, and annotations cover safety. Purpose, usage trigger, and the required user-facing output handling are all present; only sibling differentiation is missing.

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

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

Schema coverage is 100% and all four parameters carry descriptions, including the default/zero-compute semantics for current_monthly_payment. The description adds no parameter-level meaning beyond the schema, so the 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?

States a specific computation: interest and time saved by paying half the monthly payment biweekly versus monthly. This is clearly distinct from a generic calculate_mortgage, though it never names that sibling explicitly.

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

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

Gives an explicit trigger ('Use when the user asks what paying half the mortgage every two weeks saves versus monthly payments'), which is enough to route the agent correctly. It does not state when to prefer calculate_mortgage or calculate_refinance instead.

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?

While annotations cover basic safety (read-only), the description adds crucial operational transparency regarding the output. Specifically, it instructs the agent to always display the `calculator_url` as a clickable markdown link, which is a critical execution detail.

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 definition is slightly verbose due to the comprehensive list of results and the detailed formatting instruction. However, every part of the description provides necessary value, preventing the definition from feeling wasteful.

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 definition is exceptionally complete. It covers what the tool does, when to use it, and even mandates specific output formatting (the link), making it easy for the AI agent to select and execute the function 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%, meaning all input parameters are thoroughly documented within the schema. The description focuses on the *results* of the calculation rather than providing semantic meaning to the inputs, thus meeting the baseline requirement.

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 lists the specific outputs calculated: Body Mass Index, basal metabolic rate, total daily energy expenditure, and calorie targets. This specialized focus immediately distinguishes it from the wealth of financial and academic calculation siblings.

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

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

It provides explicit usage triggers, stating the tool should be used when the user asks about 'BMI category, maintenance calories, or cut and bulk targets.' This leaves no room for ambiguity regarding when to invoke the tool.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, so the bar is lower. The description adds real value by disclosing scope limits (excludes TSP matching, continuation pay, COLA, taxes) and an output-handling requirement (surface calculator_url as a markdown link). It does not state precision/rounding assumptions, but the model's core limits are transparent.

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

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

Front-loaded with the comparison and formula rates, then scope limits, then usage trigger, then the important output instruction. Dense but each sentence contributes; the ALL-CAPS directive is slightly heavy-handed but serves a concrete purpose.

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

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

With an output schema present, return values need no explanation, and the description still summarizes the returned deltas (monthly, annual, 30-year lifetime). Purpose, scope exclusions, usage trigger, and the calculator_url handling requirement together cover everything an agent needs to call and present 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% and both parameters are documented, including the 20–40 year clamping behavior, so the schema carries the load. The description adds the conceptual meaning of high-3 average pay ('on the same high-3 average basic pay') but no format or unit guidance beyond what the schema states (USD).

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

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

States a specific comparison (High-3 2.5%/yr vs BRS 2.0%/yr on the same high-3 average) and the outputs produced (monthly, annual, 30-year lifetime differences). The 'pension-only' qualifier plus the exclusion list separates it from siblings like calculate_military_retirement_pension and calculate_tsp.

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

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

Gives an explicit trigger ('Use when a service member compares the legacy High-3 pension with the BRS pension') and the exclusions imply what it should not be used for (TSP matching, continuation pay → calculate_tsp). It stops short of naming the sibling tool to use instead, so it is clear context without explicit exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the long-term gains stacking logic and, notably, the instruction to surface calculator_url as a clickable markdown link, which is a genuine output-handling requirement.

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

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

Front-loaded with the calculation logic, then the usage condition, then the link directive. Three sentences that all carry weight; minor redundancy in the re-statement of "capital gains tax calculator" but nothing wasteful enough to penalize heavily.

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

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

An output schema exists, so return values need no elaboration, and the description correctly focuses on calculation semantics, usage trigger, and the one output-handling behavior it must convey (the calculator_url link). Adequate for a stateless calculator.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the filing_status enum. The description adds the stacking interpretation but no syntax or format detail beyond the schema, so 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?

States a specific verb+resource (calculate federal capital gains tax) and the exact mechanics: ordinary income and short-term gains at ordinary rates, long-term gains stacked at 0/15/20% thresholds by filing status. This clearly distinguishes it from the many sibling tax-adjacent tools such as calculate_income_tax_estimator and calculate_paycheck.

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?

"Use when the user sells or plans to sell investments and needs the federal tax on the gains" gives a clear triggering condition. It stops short of naming the closest alternative (e.g. calculate_income_tax_estimator) to disambiguate, so it doesn't reach the top tier.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: it specifies that running costs are supplied as annual amounts, and it imposes a required output-consumption action (surface calculator_url as a clickable markdown link). It does not describe anything the annotations misstate, but it stops short of discussing assumptions or precision of 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?

Three sentences, front-loaded with the output summary and routing rule, with the critical calculator_url instruction flagged as IMPORTANT. Slightly long but every sentence carries distinct value; no filler.

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

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

For a pure deterministic calculator with a rich annotation set and an output schema, the description covers purpose, routing, input units, and how to present the result. An agent has everything needed to call it and render the answer 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%, so every parameter including units (USD) and defaults is already documented in the schema. The description restates the annual-basis of insurance/fuel/maintenance but adds no syntax, defaults, or interaction detail beyond the schema. Baseline 3 applies when the schema carries the load.

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 first sentence names the concrete outputs (monthly loan payment, running costs, total interest, five-year cost) and the resource (a car). It explicitly gates off the sibling case: 'For loan figures on a specific car use calculate_auto_loan,' so an agent can route correctly without opening either schema.

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

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

It states the triggering user intent ('what car payment fits their budget including insurance, fuel and maintenance') and names the alternative tool plus the condition that selects it. No inference is required to choose between this and calculate_auto_loan.

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

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

Annotations already declare a safe, idempotent, read-only computation, so the bar is lower, yet the description adds real behavior: the tier base rates, GPA/test-band adjustment, 1–99% clamping, the Safety/Target/Reach/High reach labeling, and the SAT-else-ACT fallback priority. It also imposes a notable output obligation (always surface calculator_url as a markdown link), which is genuinely useful behavioral context beyond the annotations.

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

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

Front-loaded with the computation model before the usage cue and the output instruction, and every clause carries information. It is dense but not padded; the only mild redundancy is repeating tier values already in the schema.

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

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

An output schema exists, so return values need not be described, and the description still adds the one thing the schema cannot convey — that the calculator_url must be presented as a clickable link. Together with the algorithm summary and usage cue, an agent has enough to call and report correctly; only explicit sibling routing is absent.

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 four parameters are already documented, including the '0 to leave out' conventions and the tier base-rate values. The description's mention of the tier percentages and SAT-vs-ACT priority largely restates the schema rather than adding syntax or format detail, so baseline 3 applies.

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

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

The description states a specific verb and resource ('Rough acceptance chance' for a college selectivity tier) and details the exact computation model (base-rate tier adjusted by GPA/SAT/ACT and clamped to a labeled bucket). This clearly distinguishes it from near-neighbors like calculate_college_roi, calculate_sat_score, or calculate_fafsa_sai_estimator.

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 says when to use it: 'Use when the user wants a rough admission chance for a college selectivity tier.' No exclusions or named alternatives are given, and it does not say when to prefer sibling estimators (e.g. calculate_sat_score for raw scoring), so it falls short of a full 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the numbers derive from an approximate median early-career salary table per major, and it imposes a mandatory post-call action (surface calculator_url as a markdown link). That is meaningful beyond the structured fields.

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

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

Three sentences, front-loaded with the outputs, then usage, then the IMPORTANT directive. Every sentence carries content, though the middle sentence restates the ROI idea already implied by the first.

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

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

An output schema exists, so return fields need no explanation, and annotations cover the safety profile. Usage trigger, data source, and the required link-display behavior are all present, leaving only sibling discrimination as a gap for this low-complexity 3-parameter calculator.

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

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

Schema description coverage is 100%, so all three parameters are already documented, establishing a baseline of 3. The description adds only indirect provenance (the salary table the major enum comes from) and never clarifies career_years or the currency/units of degree_cost beyond what the schema states.

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?

Starts with a concrete list of computed outputs (payback years, lifetime earnings minus degree cost, salary-to-cost ratio) scoped to a single major, so the verb+resource is unambiguous. It does not, however, differentiate itself from the very similarly named sibling calculate_college_roi or calculate_graduate_school_roi, leaving the agent to infer that this one is major-level.

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?

"Use when the user compares a college major's cost against its earnings payback" gives a clear triggering scenario. There are no exclusions or named alternatives, so the agent isn't told when to prefer calculate_college_roi or calculate_graduate_school_roi instead.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context beyond that. It does so with a concrete output-handling obligation: always surface the calculator_url as a clickable markdown link. That is a real behavioral instruction an agent would otherwise miss, though nothing is said about input validation or edge cases.

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

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

It is compact and the usage condition follows immediately after the capability statement. The opening sentence is dense, stacking four separate computed values into one clause, and the enumerated outputs partly duplicate what the output schema already conveys; the critical calculator_url instruction is buried at the end rather than front-loaded.

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

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

With an output schema present, the description need not explain return values, and it correctly focuses on when to invoke the tool and what to do with the result. The remaining gap is the absence of disambiguation from the other ROI calculators in a 70-tool sibling set.

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%, and every parameter carries a descriptive string including defaults for years and annual_raise_pct. The description adds no parameter-level meaning beyond the schema, 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 names the specific outputs computed (earnings premium over a no-degree baseline, net gain after cost, break-even year, return multiple on cost), which is far more than a restatement of the tool name. It does not, however, distinguish itself from closely related siblings like calculate_college_major_roi or calculate_graduate_school_roi, which an agent could easily confuse it with.

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?

"Use when the user asks whether a degree pays off versus the no-degree baseline" gives a clear triggering condition tied to a user intent. It stops short of 5 because it offers no exclusions or named alternatives (e.g., when to prefer the major-level or graduate-school ROI calculators instead).

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

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

Annotations already declare a safe, read-only, idempotent operation, so the safety profile is covered. The description adds genuinely non-obvious behavioral guidance: the result carries a calculator_url that MUST be surfaced as a clickable markdown link, which is output-handling context not present in the schema. Return shape details are omitted, but the output schema covers those.

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

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

Front-loaded purpose, then usage trigger, then disambiguation, then the critical output instruction — four tight sentences with no redundancy. Every sentence earns its place.

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

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

With a full output schema present, the description need not explain return values, and it instead supplies the pieces an agent actually needs: purpose, when to invoke, sibling routing, and the mandatory calculator_url display behavior. Nothing material is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented and the baseline is 3. The description only echoes 'monthly contributions and monthly compounding' and adds no syntax, units, or default detail beyond what the schema already states.

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

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

States a specific verb+resource ('Future value of an investment with monthly contributions and monthly compounding'), which cleanly separates it from the many other calculate_* finance tools. It also explicitly names the two nearest siblings (calculate_401k, calculate_retirement_savings_planner) it should not be confused with.

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

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

Gives a concrete trigger ('when the user asks how savings or an investment grows over time with regular contributions') and routes two adjacent scenarios to their correct alternatives with the distinguishing condition (employer match → calculate_401k; retirement balance → calculate_retirement_savings_planner). Explicit when-to-use plus 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 the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the safety burden is lifted. The description adds real behavioral context beyond that: the degenerate case where a payment never clears the balance returns null months and interest, plus a required post-call action (surface calculator_url as a clickable markdown link). It does not describe rounding/currency assumptions, but the disclosed edge case is substantive.

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

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

Three sentences, purpose and comparison front-loaded, then usage routing, then the link instruction. The IMPORTANT clause is operational rather than semantic but it is short and directly actionable. No filler sentences.

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

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

An output schema exists, so return-field documentation is not owed by the description; the description nonetheless flags the one non-obvious return behavior (null months/interest on a never-clearing payment) and the one output the agent must act on (calculator_url). Combined with 100% schema coverage, an agent has everything needed to call and use this 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%, so all four parameters (balance, annual_rate_pct, monthly_payment, extra_payment) are already documented with units in the schema. The description adds only indirect framing — that monthly_payment is the base and extra_payment the optional add-on — without new syntax, defaults, or constraints. Baseline 3 applies when 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 states a specific verb+resource ('months and interest to clear a credit card balance') and the precise comparison it performs: fixed monthly payment vs. an added extra payment. It explicitly names the sibling it is not ('For several different debts use calculate_debt_payoff'), so an agent can disambiguate from the many other calculate_* tools without opening a schema.

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

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

It gives an explicit trigger ('Use when the user wants to clear a credit card balance and asks how long it takes or how much interest it costs') and an explicit alternative with its own condition (multiple debts → calculate_debt_payoff). Both the when and the when-not are stated.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds real behavioral context: counts are inclusive, holidays are limited to 2026 US federal holidays, and the result carries a calculator_url that must be surfaced as a markdown link. The garbled enumeration of "calendar weeks, weekend days, and holidays" is a minor clarity cost.

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 purpose sentence is overloaded and reads as a garbled list, and the closing instruction contains a duplicated phrase ("calculator calculator"). The routing guidance is front-loaded and the IMPORTANT callout is justified, but the prose needs editing to be 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?

With an output schema present, return values need not be explained, and the description still covers purpose, trigger, alternative, counting convention, and the required link-display behavior. Only the ambiguous trailing enumeration of returned figures keeps it short of full 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: inclusive endpoint counting, the 2026-only holiday scope, and that the page defaults to excluding weekends. Those details change how an agent interprets the boolean parameters' effect on results.

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

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

States a specific verb+resource (day/business-day count between two dates) and explicitly separates itself from the sibling calculate_age. The opening clause is a run-on that muddles what is returned versus what is excluded, but the core purpose is still 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?

"Use when the user needs the days or business days between two dates" gives the trigger condition, and "For age from a birth date use calculate_age" names the alternative and the condition that selects it. Routing guidance is explicit rather than implied.

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

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

Annotations already declare the operation safe, idempotent, and closed-world. The description adds valuable behavioral context: it simulates month-by-month with minimum plus extra payments, compares avalanche and snowball, reports months, interest, payoff order, and savings, and instructs the agent to render calculator_url as a clickable markdown link. It stops short of documenting calculation assumptions or edge cases, so not a 5.

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

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

The description is front-loaded with purpose, then usage, alternative, and a display instruction. It is mostly efficient, though the first sentence is dense and the final sentence repeats 'calculator calculator' unnecessarily. Still, every sentence serves a clear function.

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 annotations covering safety, a 100%-described input schema, and an output schema, the description supplies exactly what remains: the comparison logic, expected outputs, sibling routing, and the required URL display behavior. Nothing an agent needs to call and present the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema documents all five parameters including required arrays and the optional extra_payment. The description mentions a list of debts and extra monthly payment but adds no syntax, ordering rules, or constraints beyond the schema. Baseline 3 applies when 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?

States a specific verb 'Simulates' and resource 'paying off a list of debts', details the avalanche/snowball comparison and reported outputs, and explicitly names the sibling calculate_credit_card_payoff as the alternative for single cards. An agent can distinguish it from other payoff calculators without opening schemas.

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

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

Provides explicit when-to-use ('when the user has several debts and wants a payoff plan comparing snowball and avalanche') and a when-to-use-other ('For a single credit card use calculate_credit_card_payoff'). No ambiguity about the intended scenario or alternative.

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 it as a safe, idempotent, non-destructive read. The description adds behavior the annotations cannot: it discloses the computed outputs and imposes a presentation obligation (always render calculator_url as a clickable markdown link), which materially changes how an agent should respond.

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

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

Front-loads the purpose and formula, then usage context, then the output directive. The all-caps IMPORTANT sentence is long but its content is actionable, so only minor trimming is possible.

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 full output schema, the description needn't explain return values, yet it still summarizes them and adds the calculator_url presentation rule. Formula, trigger context, and output handling are all covered; only the sibling-differentiation guidance is missing.

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

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

Schema description coverage is 100%, so every parameter (including the months default of 12) is already documented in the schema. The description restates the formula inputs conceptually but adds no format, unit, or edge-case nuance beyond the schema, so the baseline 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?

States a specific verb (compares), the two resources (annual dorm cost vs. apartment), and the exact formula components feeding the comparison. It also specifies the return content (both totals, the difference, which is cheaper), so an agent can distinguish it from siblings like calculate_rent_vs_buy or calculate_affordability.

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 says to use it 'when a student compares annual dorm cost with renting an apartment,' which gives a clear triggering context. It does not name or exclude the nearest alternative (calculate_rent_vs_buy / calculate_lease_vs_buy), so the agent must infer the boundary itself.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a concrete behavioral requirement: always show the calculator_url from the result as a clickable markdown link, which is a post-processing action not captured in annotations and is valuable for correct invocation.

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

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

The description is three sentences: purpose and outputs first, then usage condition, then a critical instruction. Every sentence earns its place, and the important output-link requirement is front-loaded with 'IMPORTANT'.

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 rich annotations already present, the description only needs to cover purpose, usage, and any special handling. It does all three, including the essential instruction to surface the calculator_url, leaving no gap for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no syntax, format, or default details beyond what the schema already provides, 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 names a specific calculator (emergency fund) and enumerates the outputs it produces: target amount, remaining gap, percent funded, and months to fill. This clearly distinguishes it from siblings like calculate_net_worth or calculate_student_budget, which cover different financial concerns.

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 states when to use the tool: 'Use when the user asks how big an emergency fund should be, or how close they are to the target.' However, it does not name alternative tools or describe when not to use it, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: the exact calculation constants, the zero floor, and an imperative to surface the result's calculator_url as a clickable markdown link. That post-processing instruction is the kind of behavioral detail no structured field carries. Minor gap: no note on rounding, currency of the constants, or what happens to the result when inputs are 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?

Purpose is front-loaded and the imperative link instruction is clearly marked with IMPORTANT. The formula clause is long and run-on, but every phrase carries information the agent would otherwise have to guess; little could be cut without losing meaning.

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 pure computation tool with an output schema present, the description supplies everything needed: when to invoke it, the formula behind the result, and the required follow-up action with the returned calculator_url. Nothing an agent needs to call or present this tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining how each parameter enters the computation (parent income at 22%, parent assets at 12%, student income above the 11770 allowance at 50%, student assets at 20%). An agent now understands the relative sensitivity of the inputs, which the schema's one-line unit descriptions do not convey.

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

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

States a specific verb and resource ("Simplified Student Aid Index estimate") and immediately grounds it in the exact formula used, so an agent can distinguish it from adjacent college-finance siblings like calculate_college_roi or calculate_student_loan_payoff. The domain vocabulary (SAI, Pell Grant, income protection allowance) makes the scope unambiguous.

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

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

"Use when the user estimates their FAFSA Student Aid Index" gives a clear trigger condition tied to the user's intent. It stops short of naming exclusions or pointing at alternative tools, but among the siblings none overlap enough to create real ambiguity.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds beyond them by disclosing input clamping behavior and the requirement to surface the calculator_url as a markdown link, which annotations cannot convey.

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?

Purpose first, then trigger, then the emphasized output instruction. Slightly long, but every sentence (clamping, use case, link requirement) carries actionable 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?

An output schema exists, so return values need no explanation, yet the description still flags the critical UX requirement of rendering calculator_url as a clickable link and notes 'best and worst possible course grades.' Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds clamping ranges (grades 0-100, weight 1-100) that the schema descriptions omit, giving the agent real extra semantics for the three inputs.

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

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

States a specific computation: the final-exam score needed to hit a target course grade, plus best/worst possible grades. That framing distinguishes it cleanly from nearby siblings like calculate_gpa or calculate_gpa_planner.

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?

Explicit trigger is given: 'Use when the user asks what score they need on a final exam to reach a target course grade.' Clear context, but no named alternative or exclusion (e.g., vs. gpa_planner) is offered.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds a genuinely useful behavioral directive absent from structured fields: always render the calculator_url from the result as a clickable markdown link. That is real presentation-handling context beyond the schema.

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

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

Three tight sentences with no filler; the trigger condition is stated before the presentation directive. The opening noun phrase is dense but front-loads the domain and the key differentiator (entitlement).

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 needn't explain return values, yet the calculator_url handling instruction fills the one gap an agent would otherwise miss. Given rich annotations and 100% schema coverage, an agent has everything needed to call and present 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 description coverage is 100%, so the baseline is 3. The description references 'benefit tier and enrollment level' but omits months_used and adds no syntax, ranges, or format detail beyond what the schema and enum values already provide.

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

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

The description names a specific resource (Post-9/11 GI Bill entitlement) and enumerates the exact outputs (months remaining, tuition coverage percent, books stipend, MHA), which clearly separates it from siblings like calculate_military_pay or calculate_bah. The verb 'calculate' is only implied by the name rather than stated, but the domain 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?

It states an explicit trigger: 'Use when the user asks what the Post-9/11 GI Bill covers or how much entitlement remains.' That is clear context for invocation. No alternatives or exclusions are named, but the sibling set makes overlap unlikely.

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 this as a safe, idempotent read-only calculation, and the description adds critical behavioral detail beyond them: the full grade-point scale, positional matching of grades and credits, and the requirement to render calculator_url as a clickable markdown link. These additions meaningfully shape both the computation and the response 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 dense but front-loads the core calculation and grade scale before usage guidance, the alternative tool, and the output-link instruction. The grade scale is long but necessary because it cannot be inferred from the schema or annotations.

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

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

Given the simple two-parameter input, rich annotations, and an output schema, the description supplies everything extra the agent needs: the grading scale, positional matching rule, sibling-tool routing, and a mandatory output-handling instruction for calculator_url. No critical context is missing.

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

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

Schema coverage is 100%, so the schema already documents both arrays and their comma-separated format. The description adds useful semantic detail beyond the schema by supplying the exact letter-grade-to-point conversion table and clarifying that grades and credits are matched by position.

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

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

States a specific verb and resource ('Credit weighted GPA on the 4.0 scale') with the exact grade-point mapping, and explicitly distinguishes itself from calculate_gpa_planner. An agent can tell exactly what this tool computes without opening any schema.

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

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

Explicitly says to use it 'when the user computes a GPA from course grades and credits' and routes target-GPA planning to calculate_gpa_planner. This gives both a positive use condition and a named alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real value beyond them: it discloses that results use 'page thresholds' and, critically, mandates surfacing the calculator_url as a clickable markdown link in the answer, which no structured field conveys.

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

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

Front-loads the computed outputs, then the usage trigger, then the IMPORTANT output-handling instruction. Every sentence earns its place, though the opening clause is dense enough to require a second read.

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

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

An output schema exists, so return values need no explanation, and the description still flags the notable return field (calculator_url) and its required presentation. The only soft spot is the unexplained reference to 'page thresholds,' but it does not block correct 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 description coverage is 100% with four well-labeled numeric parameters, so the baseline is 3. The description implies how the inputs combine (current vs. planned credits, current vs. target GPA) but adds no syntax, ranges, or format constraints 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?

States a specific computation and enumerates the exact outputs: required term GPA, max reachable cumulative GPA, and the implied grade mix. This clearly separates it from the sibling calculate_gpa, which computes a current GPA rather than a forward-looking target plan.

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

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

Gives an explicit trigger: 'Use when the user asks what term GPA they need to reach a target cumulative GPA.' That is a clear context for selection, though it names no alternative tool or exclusion case (e.g. planning vs. simply computing an existing GPA).

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety burden is lifted. The description adds real operational context by disclosing that the result carries a calculator_url that must be surfaced as a clickable markdown link, and it names the computed outputs so the agent knows what comes back.

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

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

Three sentences, front-loaded with the output summary before the usage trigger and the link instruction. The 'IMPORTANT' clause is justified because it changes agent behavior, but the opening sentence is densely packed and repeats output details the output schema already carries.

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

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

An output schema exists, so return values need little explanation, and the description still covers the trigger condition plus the one post-processing requirement (link the calculator_url) that the schema cannot express. Nothing essential to a correct call is missing.

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

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

Schema coverage is 100% and every parameter (total_cost, career_years, current_salary, post_degree_salary) is documented in-schema with units and the career_years default. The description only gestures at 'the total cost' and 'the career years', adding no format or unit detail beyond what the schema already provides, so the 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 names a specific verb (calculate) plus the exact outputs produced: annual salary premium, break-even years on total cost, and lifetime net over career years. The 'graduate degree' scope clearly separates it from the undergrad-oriented calculate_college_roi and calculate_college_major_roi siblings.

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?

"Use when the user weighs graduate school cost against the salary premium it brings" gives a clear triggering context, which is uncommon among these calculator siblings. It does not, however, name a specific alternative tool or state when-not to use it.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, non-openWorld), and the description adds non-schema behavior: the clamping rule for the writing score and the mandatory post-processing instruction to surface calculator_url as a clickable markdown link. That output-handling requirement is genuinely new information beyond the annotations.

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

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

Front-loaded with the scoring formula, followed by the usage condition and a bolded IMPORTANT directive. Efficient, though the formula restatement is slightly dense; every sentence still carries actionable 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?

An output schema exists, so return-value explanation is unnecessary, and the description still covers the formula, defaults, usage context, and the required link behavior. Adequate for a 5-parameter estimator, with little meaningful gap remaining.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes further by explaining how verbal_correct/verbal_total map to the score (130 + fraction correct * 40 per section) and restating the 0-6 writing clamp. This adds interpretable meaning beyond the terse schema 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 a specific verb and resource ('Estimated GRE verbal and quant scores on the 130 to 170 scale') and even gives the mapping formula. It is clearly distinguishable from siblings like calculate_lsat_score_estimator, calculate_mcat_score_estimator, and calculate_sat_score by naming the GRE explicitly.

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

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

'Use when the user estimates GRE verbal and quant scores from practice results' gives a clear triggering context. It lacks explicit when-not or alternative-tool guidance, but the test-specific framing makes the intended use unambiguous.

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

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive), and the description goes beyond them by disclosing the computation rule (required minus earned, floored at zero) and the post-call obligation to surface calculator_url as a markdown link. It does not discuss edge cases like out-of-range credit values, but the added behavioral content is real.

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

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

Three sentences, front-loaded with the computation and result semantics, then the usage trigger, then the output-link instruction. The 'IMPORTANT' emphasis is slightly heavy-handed but the sentence earns its place as a hard output requirement.

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

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

An output schema exists, so return-value explanation is unnecessary; the description still usefully flags that calculator_url appears in the result. With the formula, state coverage, usage trigger, and output obligation all covered, an agent has what it needs to call this 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 the baseline is 3, but the description adds genuine value by expanding the enum codes into full state names (Texas, California, New York, Florida, Illinois), letting the agent map a user's spoken state to the right code without inspecting 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?

States a specific computation (remaining credits still needed) against a specific resource (per-state high school graduation requirement table), broken out by subject. An agent can distinguish this from calculate_gpa_planner or calculate_premed_course_planner purely from the description.

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

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

Explicitly names the triggering situation: when a user checks remaining high school graduation credits by subject and state. It gives no exclusions or named alternatives, but the use context is unambiguous and scoped to five states.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the calculation basis (pretax deductions and standard deduction) and a required output-handling instruction to show calculator_url as a clickable markdown link. It does not state tax-year assumptions or other limitations, but for a read-only estimator that is a minor gap.

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

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

The description is four tight sentences, front-loaded with the purpose, then usage, the alternative sibling, and a critical result-handling instruction. Every sentence contributes information the agent needs, with no padding.

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

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

An output schema exists, so return values need not be explained in the description. Annotations cover the safety profile, and the description supplies purpose, usage, sibling routing, and the required calculator_url handling. An agent has everything needed 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 description coverage is 100%, with all three parameters documented, including the filing_status enum values and the default for pretax_deductions. The description references pretax deductions and filing status as part of the computation, but adds no syntax, format, or constraint details beyond what the schema already provides. 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 states a specific verb and resource: calculate a federal income tax estimate, after pretax deductions and the standard deduction for a filing status. It gives the key outputs (AGI, taxable income, marginal rate, effective rate) and explicitly distinguishes itself from calculate_paycheck. An agent can identify what the tool computes without opening the schema.

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

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

It gives an explicit trigger: 'Use when the user wants a federal income tax estimate for a salary.' It also names the alternative and the condition that selects it: 'For per-paycheck take-home pay use calculate_paycheck.' This removes ambiguity about which sibling to choose.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-annotated behavior: the result carries a calculator_url that the agent is instructed to render as a clickable markdown link, which is an output-presentation obligation the schema cannot convey.

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

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

The core purpose and the routing rule are front-loaded in efficient sentences. The final IMPORTANT directive is worth its length, though the duplicated phrase 'interactive inflation calculator calculator' is a sloppy artifact that slightly undercuts the polish.

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 restate return values, yet it usefully previews them and adds the critical calculator_url presentation requirement. For a read-only, idempotent calculator with full schema coverage, this is close to complete; only explicit handling of edge inputs (e.g. zero or fractional years) is absent.

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 four parameters (years, amount, annual_rate_pct, include_schedule) are already documented with examples like 'e.g. 3'. The description only gestures at the inputs in prose without adding format, bounds, or default semantics beyond the schema, so the 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 names a specific verb-resource pair and enumerates the four concrete outputs (future purchasing power, future cost of today's basket, cumulative price increase percent, purchasing power lost). It also explicitly distinguishes itself from the sibling calculate_raise_vs_inflation, so an agent can disambiguate without opening the schema.

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

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

It states both directions of use ('what money will be worth in the future' and 'what a future amount costs in today's dollars') and routes the adjacent case ('whether a raise keeps up') to calculate_raise_vs_inflation by name. Nothing about when to pick this tool is left to inference.

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

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, non-destructive), so the description only needs to add context. It does: it discloses what the result contains (winning option, net cost difference, calculator_url) and an operational requirement to render that URL as a clickable markdown link in the reply. No permissions, limits, or failure modes are discussed, but those are minor for a pure calculator.

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

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

Three short sentences, front-loaded with what is computed, then when to use it, then the required follow-up action. Every sentence carries information, though the capitalized instruction is longer than strictly necessary and could be tightened without losing meaning.

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

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

An output schema exists, so return values need not be explained; the description still adds the key result fields and the URL-linking obligation. Combined with named alternatives and a clear trigger, an agent has enough to call this correctly, with only edge-case behavior (invalid inputs, which term drives the comparison) left implicit.

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

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

Schema description coverage is 100% and every one of the nine parameters carries its own description (MSRP, residual percent, money factor, down payments, terms), so the schema does the heavy lifting. The description restates the comparison framing (lease term versus buy at the same point) but adds no units, defaults, or syntax 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?

States a specific verb-and-resource pair with scope: lease outlay over the lease term versus buy outlay net of equity, plus the winning option and net cost difference. It also names the sibling it is not (calculate_auto_loan for loan-only figures), so an agent can separate it from the loan calculators without opening the schema.

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

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

The trigger is explicit ('Use when the user compares leasing a car against buying it') and the nearest alternative is named with the condition that selects it ('For loan-only figures use calculate_auto_loan'). The when-not case is covered by routing loan-only questions away.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: negative line items are treated as zero 'as on the page,' and it mandates surfacing the returned calculator_url as a markdown link. It does not cover rounding or how partial input is handled, keeping it just under a 5.

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

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

Three sentences, front-loaded with the computation, then the when-to-use cue, then the IMPORTANT output instruction last. No filler; each sentence carries distinct information.

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

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

An output schema exists, so return values need not be described, and annotations already cover the safety profile. The description supplies the remaining essentials: input aggregation semantics, the negative-value edge case, and the required handling of calculator_url, which is sufficient for an agent to call it correctly.

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

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

Schema coverage is 100% and each field is labeled, so the baseline is 3. The description adds value by grouping the ten fields into entitlement lines (base pay, BAH, BAS, other) versus deduction lines (federal tax, FICA, state tax, SGLI, TSP, other) and by disclosing that negative values are clamped to zero, which materially changes how inputs are interpreted.

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

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

States a specific verb+resource: it sums LES entitlement and deduction lines and returns net pay plus deductions as a percent of entitlements. This cleanly separates it from siblings like calculate_military_pay (pay from rank/service data) and calculate_paycheck, without needing to open any schema.

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

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

Explicitly says 'Use when the user has Leave and Earnings Statement lines and wants the net pay explained,' which gives a clear triggering context. It stops short of naming an alternative (e.g., calculate_military_pay or calculate_paycheck) or stating when NOT to use it, so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavioral context: the result contains a calculator_url and the agent is instructed to surface it as a clickable markdown link. It doesn't discuss precision, rounding, or edge cases, but the added output/presentation guidance is real value beyond the annotations.

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

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

Four sentences, all purposeful and front-loaded with the core capability before the routing guidance. The second sentence slightly restates the first ('payment, total interest or payoff schedule'), a minor redundancy that keeps it from a 5.

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

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

An output schema exists, so return values need no explanation; the description instead covers routing among ~60 siblings and the mandated link-presentation behavior. An agent has everything needed to select and invoke this 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%, so all four parameters are already documented in the schema (including the yearly amortization schedule). The description's mention of 'optional amortization schedule' merely echoes include_schedule and adds no syntax or format detail, so the 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?

Names a specific verb/resource (loan payment calculation) and enumerates outputs (monthly payment, total interest, optional amortization schedule). It explicitly distinguishes itself from the sibling loan calculators, so an agent can route without opening any schema.

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

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

States when to use it ('payment, total interest or payoff schedule for a generic loan') and names three concrete alternatives with their selecting conditions (calculate_auto_loan for cars, calculate_mortgage for homes, calculate_student_loan_payoff for student debt). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint true, openWorldHint/destructiveHint false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the scoring formula the tool applies, and a mandatory post-call behavior (always surface calculator_url as a clickable markdown link). It does not discuss rounding, precision or edge cases of the estimate.

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?

Definition and formula are front-loaded before the usage sentence and the trailing IMPORTANT instruction, and every sentence carries a distinct job. The formula sentence is dense (e.g. 'the page score band' is unexplained jargon), which costs a point.

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

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

An output schema exists, so return values need not be described, and the description still adds the scale, the formula, and the required downstream handling of calculator_url. Nothing an agent needs to invoke this correctly and present the result is missing.

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

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

Schema coverage is 100% with all six section_correct/section_total parameters individually documented, so the baseline is 3. The description earns above baseline by explaining how those inputs combine ('overall fraction correct across the three sections times 60'), giving the aggregation semantics the schema alone does not.

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

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

The description states a specific resource (LSAT scaled score on the 120–180 scale) and the exact computation ('120 plus the overall fraction correct across the three sections times 60'), which makes it unmistakable against the many sibling score estimators (calculate_act_score, calculate_sat_score, calculate_gre_score_estimator, calculate_mcat_score_estimator). An agent can tell what this tool produces without opening the schema.

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

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

'Use when the user estimates an LSAT scaled score from practice section results' gives a clear triggering condition, and the three-section input shape implicitly excludes single-score or curve-lookup tools. No explicit alternatives or when-not-to-use cases are named, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the disclosure of the exact scoring formula and the mandatory follow-up action: surface the returned calculator_url as a clickable markdown link. That output-handling requirement is real behavioral context not available from annotations or 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?

Front-loaded with the computation and the triggering condition, then the link-rendering requirement. Three sentences, each doing work. The IMPORTANT clause is slightly verbose but is a hard requirement, so it earns its space.

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

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

An output schema exists, so the description needn't explain return values, and it correctly focuses on the one output behavior that matters (showing calculator_url). For an eight-parameter, fully documented, annotation-covered calculator, this is complete; only the sibling-routing guidance is thin.

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 eight parameters are already documented (correct counts and totals per section). The description adds meaning beyond the schema by explaining what the inputs are used for – fraction correct scaled onto 118–132 per section – which tells the agent the counts must be internally consistent rather than arbitrary numbers.

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

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

The description names a specific verb+resource (estimate MCAT section scores) and even states the scoring model: 118 + fraction correct × 14 per section, plus the 472–528 total. This cleanly separates it from siblings like calculate_lsat_score_estimator and calculate_gre_score_estimator, which share the same 'estimate a test score' pattern.

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?

"Use when the user estimates MCAT section scores from practice results" gives a clear triggering context, and the four-section input shape implies it needs all four sections at once. It does not, however, explicitly rule out or route to the other score estimators (SAT, ACT, PSAT, LSAT, GRE) when a user's request is ambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real behavioral context: the E1B special first-4-months rate, the failure mode for unauthorized combinations (authorized=false with null pay), and an output-presentation requirement (always surface calculator_url as a clickable markdown link). These are non-obvious traits that annotations and schema do not convey.

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

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

Four sentences, front-loaded with the core purpose before edge cases and routing. The all-caps IMPORTANT instruction is a bit heavy and could be tightened, but each sentence carries distinct information.

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

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

An output schema exists so return values need no explanation, and the description nonetheless flags the key output fields (authorized, calculator_url) and the invalid-combination case. Nothing needed to call the tool correctly is missing.

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

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

Schema coverage is 100% and the enum already documents E1B as 'E-1 with under 4 months of service', so the description largely repeats the schema. It adds only marginal value by implying that some grade/YOS combinations are unauthorized, without enumerating them. Baseline 3 is appropriate when 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?

States a specific verb+resource (monthly basic pay from the 2026 pay table) plus the exact scope (pay grade and years of service, with annualized amount). It explicitly distinguishes itself from the sibling calculate_bah by naming it. An agent can select this tool without opening the schema.

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

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

Gives an explicit when-to-use condition ('when the user wants basic pay for a pay grade and years of service from the 2026 table') and names the alternative for a different need ('For housing allowance use calculate_bah'). Routing is unambiguous.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond those: the estimate is before taxes, includes annual and 20-year lifetime amounts, and requires showing calculator_url as a clickable markdown link. That last instruction is operationally important and not covered by annotations or 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 front-loaded with the core calculation and purpose, then adds usage guidance, the alternative sibling, and the required link-display instruction. Every sentence earns its place, with no redundant or filler 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?

With an output schema present, the description need not explain return values. It still covers the calculation, when to use it, the alternative, and a critical user-facing output instruction about the calculator_url link. Nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by tying the parameters to the calculation formula and explaining the system enum multipliers (2.0% BRS, 2.5% High-3) in the context of the full monthly pay formula, going beyond the schema's own 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 gives a specific verb and resource — it estimates monthly military retired pay — and even states the formula (years of service × system multiplier × high-3 average monthly basic pay). It clearly distinguishes this tool from calculate_brs_vs_high3 by naming that sibling for comparison use.

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 says when to use it: 'Use when the user estimates monthly military retired pay.' It also names the alternative tool for BRS versus High-3 comparisons, so the agent can route correctly without inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavioral context beyond the annotations: the result contains a calculator_url that MUST be surfaced as a clickable markdown link in the answer, which is an output-contract instruction an agent could not infer from schema or 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?

Front-loaded with the purpose in the first clause, then usage, then siblings, then a clearly flagged 'IMPORTANT' output requirement. Four sentences, each carrying distinct information with 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 10-parameter, fully schema-documented calculator with an output schema, the description supplies everything the structured fields do not: component scope, routing rules to the two nearest siblings, and the required presentation of the result URL. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so every parameter (including defaults for term_years, down_payment_pct, pmi_rate_pct and the down_payment_usd precedence rule) is already documented in the schema. The description only restates the cost components at a high level and adds no format or precedence detail beyond the schema, so the 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?

States a specific verb and resource ('Monthly mortgage payment breakdown') and enumerates the exact cost components computed: principal/interest via amortization, property tax, insurance, PMI, and HOA. It also explicitly distinguishes itself from calculate_loan and calculate_affordability by name, so an agent can route without opening any schema.

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

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

Gives a concrete use condition ('when the user is buying a home and wants the full monthly payment including tax, insurance, PMI and HOA') and names two alternatives with the conditions that select them ('plain loan without housing costs' → calculate_loan; 'the most they can afford' → calculate_affordability).

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