Compound Mint Money Calculator

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so safety is covered. The description does add real behavior beyond that: what gets returned (understood inputs, explanation, assumptions, source_page, related_reading) and the need_more_info status with the exact follow-up question. However the 5-point scale is meant to reward richer disclosure, and it stops short of saying what happens when the question is ambiguous or matches multiple calculators, or how a need_more_info response should be relayed.

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 routing instruction is front-loaded and the return-value sentence is efficient. The six inline examples are somewhat repetitive and lengthen the definition, but they do double duty illustrating both the input style and the calculator coverage, so they mostly earn their 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 no output schema, the description carries the full burden of explaining return values and does so: answer plus understood inputs, explanation, assumptions, citation fields, and the need_more_info branch with a ready-to-ask question. Nothing an agent needs to call it or interpret 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?

Only one parameter with 100% schema coverage, so the baseline is 3–4 and the schema already carries the definition. The description adds useful meaning by explaining that amounts, rates, ages and years are parsed out of the free-text question, which tells the agent to pack those numbers into the string rather than send a bare topic.

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 ("answer a money question") and immediately distinguishes itself from the calculate_* siblings by acting as the natural-language front door that picks and runs the matching calculator. The six worked examples make the intended input domain unmistakable.

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

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

"Use first when a user asks a money math question in plain words" is an explicit routing rule that names the triggering condition and implies the alternative (call a specific calculate_* tool directly when the type is already known). It also enumerates the calculator families it will dispatch to, so the agent can tell when to bypass 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 already establish readOnly/idempotent/non-destructive/closed-world, so safety needs no restating; the description instead adds real behavioral context: which 2026 IRS limits are applied ($24,500 employee, catch-up at 50+ and 60–63, $72,000 overall, $360,000 pay cap) and that a two-tier formula is supported. It doesn't say what happens when contribution exceeds the cap or how unclaimed-match is derived, 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?

Trigger conditions are front-loaded and every clause carries information, but the second sentence is a verbless fragment listing outputs and the first is long; tightening and adding the missing verb would improve readability without losing content.

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

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

For a 9-parameter, no-output-schema tool this covers the essentials: triggers, applied limits, formula shape, defaults, and the returned figures. A brief note on cap/limit edge cases (contribution above the $24,500 deferral limit) would close the remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the tiered formula ('100% up to 3% then 50% of the next 2%'), which is the only way an agent will correctly map match_percent/match_up_to_percent/tier2_* to a real plan, and by tying age to catch-up limits and years/annual_return to projection.

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 (calculate the 401(k) employer match) and enumerates concrete user phrasings it answers, which cleanly separates it from siblings like calculate_compound_interest or calculate_savings_goal. An agent can distinguish its job without reading 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 three explicit trigger questions ('am I getting my full match?', 'how much is my employer match worth?', 'what percent should I put in?'), so when-to-use is unambiguous. It stops short of naming alternatives or exclusion conditions (e.g., don't use for pure growth projections — use calculate_compound_interest), 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?

The annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond that: it explains the real after-inflation return assumption, the 7% default, and that current savings and monthly contributions are used to show the gap and Coast FIRE age.

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 usage condition and examples, then moves efficiently into the calculation concept and assumptions. Every sentence contributes to selecting or correctly interpreting the calculator.

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

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

For an 8-parameter calculator with full schema coverage and no output schema, the description is complete enough: it explains the key outputs (gap and age reaching Coast FIRE), the return assumption, and the relationship between spending, withdrawal rate, and FIRE number. Remaining details such as parameter bounds and defaults are already covered by the schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining the relationship between annual spending, withdrawal rate, and the FIRE number, and by clarifying that current savings and monthly contributions drive the gap and age calculation.

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 calculation and resource: it computes the FIRE number, Coast FIRE number, gap, and the age Coast FIRE is reached. It distinguishes Coast FIRE from ordinary FIRE by defining it as 'what you need invested now so growth alone reaches your FIRE number by retirement age,' so an agent can tell what this tool uniquely does.

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 clear triggering guidance with example user questions such as 'what is my Coast FIRE number at 30?' and 'can I stop saving for retirement and let it grow?'. It does not explicitly route plain FIRE-number questions to the sibling calculate_fire_number tool, so the alternative-selection guidance is not fully complete.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is pre-cleared. The description adds genuinely new context: monthly compounding default with four alternatives on request, and that the return includes a plain-English explanation, stated assumptions, and a matching calculator page URL. It just doesn't say anything about the boundaries that produced the worked example's assumptions.

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 trigger condition and examples are front-loaded, then the computation is defined, then the return shape — a sensible order with no filler sentences. The worked example at the end ($10,000 at 7% for 10 years = $19,671.51) is defensible as a verification anchor but is the one piece that could be trimmed without loss.

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

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

For a 7-parameter, annotation-covered, no-output-schema calculator, the description covers what is computed, the default compounding assumption, the return contents, and a sanity-check value — enough to call it correctly. Minor gaps: it never mentions the begin/end deposit timing or the year-by-year table option, leaving those purely to the schema.

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

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

Schema coverage is 100% with per-field descriptions, defaults, ranges, and examples, so the baseline of 3 applies. The description's parameter-adjacent text ('starting amount plus optional monthly contributions at a yearly rate', 'monthly by default... on request') largely restates the schema rather than adding semantics; contribution_timing and show_yearly are never touched in prose.

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 computation and its exact scope: future value of a starting amount plus optional monthly contributions at a yearly rate, with total contributed and total interest. The three paraphrased user questions make the resource boundary concrete, so an agent can distinguish it from siblings like rule_of_72 or calculate_savings_goal 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 opens with an explicit 'Use when a user asks...' trigger and three representative phrasings, which is strong positive guidance. It stops short of any exclusion or sibling routing (e.g., when to prefer rule_of_72 for doubling time or calculate_savings_goal for a target), so the alternative-selection half of the guidance is missing.

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, and closed-world behavior. The description adds useful behavioral context by explaining what it computes in each mode (months to payoff, total interest, required payment), though it does not note assumptions like fixed APR or no new charges.

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 triggering scenario, followed by compact examples and then mode-specific behavior. Every sentence contributes to selection or invocation, with no filler.

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

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

For a 7-parameter calculator with no output schema, the description covers both operating modes and explains the single-debt return values. The multi-debt output is described only as a comparison of avalanche and snowball, leaving the exact return shape less explicit.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds meaningful mode-level semantics: which parameters apply to one debt versus several, and that monthly_payment and target_months are alternatives. It does not explain every parameter beyond the schema, so a 5 is not warranted.

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 with concrete triggers and examples, and clearly separates single-debt from multi-debt operation. It does not explicitly compare itself to any sibling calculator, so the sibling-differentiation bar for a 5 is unmet.

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?

Opens with explicit 'Use when' conditions and gives user-phrased examples that map directly to the tool. It lacks explicit when-not guidance or named alternatives, but the usage context is otherwise 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 establish read-only, idempotent, non-destructive behavior, so the description is free to add the substantive details: returns are based on a real (after-inflation) return of 7% by default, and the math matches a named external calculator. It doesn't cover edge cases (zero savings, unreachable targets) but adds genuine context beyond the annotation set.

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 user-question triggers, then the return shape, then the modeling assumption. Three dense sentences, no filler, and each one 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?

Seven all-optional parameters and no output schema could easily leave an agent guessing, but the description explains what comes back (FIRE number, months/years, age) and which inputs are alternatives. Minor gap: it doesn't state what happens if neither annual_spending nor fire_number is supplied.

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

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

With 100% schema coverage the baseline is 3, and the description earns more by explaining the relationship between inputs: annual_spending vs. fire_number are alternates, and current_savings plus monthly_contribution drive the time-to-goal calculation. It also clarifies that current_age only affects the reported age, which is more than the schema's terse "Optional age now" conveys.

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 resource (FIRE number) and exactly what it computes: the target nest egg, the months/years to reach it, and the resulting age. It also gives the formula (yearly spending / withdrawal rate, 25x at 4%), so the agent knows the output precisely. It does not, however, distinguish itself from the close sibling calculate_coast_fire, which an agent may easily confuse with this tool.

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

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

"Use when a user asks when they can retire or how much they need to retire" plus three quoted example phrasings give a concrete trigger condition. No when-not guidance or named alternative (e.g., coast FIRE vs. full FIRE) is provided, so the sibling-routing burden remains on the agent.

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 description spends its space on what the annotations cannot say: the three budget-derivation routes (total_budget, income x percent, saved + savings x months), the split fallbacks, and the returned fields including card interest. It stops short of describing precision/rounding, currency assumptions beyond USD examples, or the exact default 3/6/12-month interest table output.

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

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

Front-loaded with the usage trigger and examples, then budget routes, then outputs, then the sibling disclaimer — a sensible order. It is dense and long-ish, with the four quoted example phrases bordering on redundant given the schema's own examples, but every sentence still carries routing or output information.

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

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

For a 12-parameter tool with no output schema, the description covers the trigger conditions, all three budget sources, all three split modes, the optional card-interest branch, the returned values, and the sibling boundary. 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 baseline is 3, but the description adds genuinely new semantics: the precedence among the mutually exclusive budget routes and the split-mode inference (percent if percents present, amount if amounts, else equal). It does not explain interactions like what happens if total_budget and monthly_income are both supplied.

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

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

The description states a specific computation (splitting a holiday gift budget across people, optionally costing card interest) and anchors it to recognizable user phrasings. It explicitly carves out scope from the sibling calculate_holiday_budget, which handles travel/food/decor.

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?

Opens with an explicit 'Use when...' trigger plus four realistic utterance examples, and names the alternative tool and the condition that selects it. An agent can route between this and calculate_holiday_budget without opening either schema.

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 and closed-world, so the safety profile is covered. The description adds genuine context beyond that: the output set (total, share of take-home pay, weeks of saving, cash by holidays, spend limit, per-person budget), the provenance ('Same math as the compoundmint.com holiday budget calculator') and the educational disclaimer. Without an output schema, this narrative of the return values is the main value add.

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 a clear trigger and examples, then a compact result enumeration. Slightly long due to three quoted examples and a run-on output list, but every clause is informative rather than 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 9-parameter read-only calculator with no output schema, the description covers trigger, inputs contributing to the total, and the shape of the results, which is enough to invoke it confidently. It does not explain how optional inputs like monthly_income or weekly_savings change the output, but the schema defaults make that low-risk.

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 all 9 parameters including their units and defaults are already documented in the schema. The description confirms the semantic intent of two of them ('people x budget per person') and the derivation of weeks_left, but adds little else beyond what the schema states. 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 trigger scenario and quotes three real phrasings, and the second states exactly what the tool computes (gifts + travel + food + decor) and what it returns. It is clearly distinguished from siblings like calculate_savings_goal or calculate_debt_payoff by naming the holiday domain and the exact output set.

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

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

The description opens with an explicit 'Use when...' trigger, gives example user utterances, and notes the negative scope ('Educational only, not financial advice'), which is the key boundary for a finance tool. The only small gap is that it does not name a specific sibling as the alternative for a non-holiday budgeting question.

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 openWorldHint=false, so safety is covered. The description adds real behavioral context the annotations cannot: the calculation includes money already saved, growth is applied at a yearly rate, and a worked example ('$1,000,000 in 30 years at 8% needs about $671 a month') gives the agent a sanity check on output magnitude. Return shape and rounding are still unstated, 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?

Front-loaded with the usage trigger, then the computation, then a concrete example — a sensible order. The two user-phrasing examples and the numeric example overlap slightly, so one of them is arguably redundant, but nothing is padded or vague.

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 no output schema, the description carries the burden of signalling the return value, and the '$671 a month' example does exactly that. Required vs optional inputs are handled by the schema, and the only notable omission (rounding/currency formatting) is minor for a deterministic 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% and each parameter already carries a description and example, so the baseline of 3 applies. The description adds only light reinforcement — 'counting money already saved' maps to current_savings and 'yearly rate' to annual_rate — without new format, unit, or edge-case guidance (e.g. what a 0% rate or sub-year horizon yields).

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 — the monthly amount to save to reach a target over N years at a given rate, including existing savings. That computation is clearly distinct from siblings like calculate_compound_interest or calculate_fire_number, so an agent can route 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?

Opens with an explicit trigger ('Use when a user asks how much to save each month for a goal') and reinforces it with two natural-language user phrasings. It does not name a competing sibling or state when not to use it, which keeps it short of a 5.

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

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

The description specifies the nature of the return data ('the text'), adding behavioral context that the annotations (readOnlyHint: true) do not cover. It confirms this is a retrieval operation, not a modification.

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 concise, front-loaded, and uses only one sentence to communicate its entire function and acceptable input formats, ensuring maximum information density.

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

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

For a simple, read-only tool with a single parameter and no complex output schema, the description provides all necessary information for an agent to understand its scope, inputs, and fundamental purpose.

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?

While schema coverage is 100%, the description is crucial here as it defines the semantic meaning of the 'id' parameter—that it accepts either a system-generated search ID or a raw external URL. This distinction is critical for correct invocation.

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 title and description clearly state the tool retrieves content ('Returns the text') specifically from 'Compound Mint,' which distinguishes it clearly from the surrounding calculation and search tools.

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

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

The description provides context on the permissible inputs, specifying that the ID can come from a search result or be a URL. This implies a usage pattern, though it doesn't explicitly mandate a pre-call to the `search` 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the shape of what comes back (inputs, example, REST endpoint) — important since no output schema exists — but says nothing about size or ordering of the list.

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

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

A single sentence with no wasted words, and the resource is front-loaded before the returned contents. Nothing to trim.

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 no-argument read-only listing tool with no output schema, the description covers purpose and return contents adequately. A brief note on how to use the returned REST endpoint or that this is the discovery step before calculate_* calls would make it complete.

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

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

The tool takes zero parameters, so the baseline of 4 applies. Nothing about argument semantics needs explaining, and the description correctly implies it needs no input.

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 ('Lists') and resource ('every calculator tool'), and clarifies the payload: inputs, example, REST endpoint. That distinguishes it from the calculate_* siblings, which perform computations rather than enumerate them, though it never names an alternative 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 is implied by 'every calculator tool' — an agent would infer this is the discovery entry point before calling a calculate_* tool. However, there is no explicit when-to-use statement, no mention of when not to use it, and no alternative named.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description contributes beyond them by disclosing the return content — both the Rule of 72 estimate and the exact figure — which matters since no 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?

Front-loaded with the triggering question and closed with a concrete example, which is good structure. The second sentence largely restates the two modes from the first, though it does earn its place by adding the parameter mapping.

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

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

For a two-parameter, fully documented, read-only calculator with no output schema, the description covers the trigger, both modes, and the returned values. The one gap is unspecified behavior when neither optional parameter is provided.

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 real value by mapping each input to a mode ("send annual_rate" vs "send years") and stating both parameters are optional alternatives. It does not specify behavior if both or neither are supplied.

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 computation (Rule of 72 doubling time / required rate) and frames it as the answer to two concrete user questions. It is unmistakable against siblings like calculate_compound_interest or calculate_fire_number, which address different financial questions.

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

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

"Use when a user asks how long it takes to double money... or what return doubles it in a number of years" gives explicit trigger conditions for both modes. It stops short of saying when a sibling calculator (e.g. calculate_compound_interest) is the better choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are partly covered. The description adds useful behavioral context by stating the return fields (id, title, url) and the follow-up fetch step, though it omits result count, ranking, and pagination behavior.

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

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

The description is two tightly written sentences. The purpose is front-loaded and the return/follow-up information is included without unnecessary repetition or verbosity.

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

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

For a simple read-only search tool with a fully described single parameter and annotation coverage, the description is nearly complete: it explains what is searched, what is returned, and how to read a result. It could be stronger if it explicitly routed the agent relative to list_money_calculators or answer_money_question.

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% for the single query parameter, and the schema itself provides examples such as 'coast fire' and '401k match'. The description does not add query syntax or formatting semantics beyond what the schema already supplies, so the baseline score 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: it searches Compound Mint calculators and personal finance guides. This is clear enough for an agent to understand the tool's purpose, but it does not explicitly differentiate itself from siblings like list_money_calculators or answer_money_question.

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

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

The description implies query-based lookup and tells the agent to read a result with fetch. However, it does not state when to use search instead of list_money_calculators or answer_money_question, and it gives no exclusions or alternative-selection guidance.

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