Skip to main content
Glama

Retirement calculator

calc_retirement
Read-onlyIdempotent

Read-only educational calculator. Projects retirement savings from age, contributions, return assumptions, and income target, returns the year-by-year balance at each age, then estimates the gap using a 4% withdrawal assumption. Returns a result from caller-supplied public inputs without changing page or account state, accessing BetterOff customer data, or providing personalized financial advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
currentAgeNoCurrent age
displayModeNoProjection modenominal
annualFeePctNoAnnual investment fees (%) — Deducted from the assumed annual return.
retirementAgeNoRetirement age
currentSavingsNoCurrent retirement savings
annualReturnPctNoExpected annual return (%) — Nominal annual return before inflation.
inflationRatePctNoInflation rate (%)
withdrawalRatePctNoWithdrawal-rate assumption (%) — Planning assumption only; it is not guaranteed to be safe.
otherMonthlyIncomeNoOther monthly retirement income — Expected Social Security, pension, or other income that reduces the amount the portfolio must provide.
monthlyContributionNoMonthly contribution
desiredMonthlyIncomeNoDesired retirement income — Monthly income target in retirement.
annualContributionGrowthPctNoAnnual contribution growth (%) — Increase applied to monthly contributions after each projection year.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds useful context beyond that: it will not change page or account state, will not access BetterOff customer data, and will not provide personalized financial advice. It also discloses the projection outputs, which strengthens transparency.

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

Conciseness5/5

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

Two sentences carry all essential information with no wasted words. The core purpose and output are front-loaded, and the safety/educational caveat is appended cleanly.

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

Completeness4/5

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

With an output schema present and full parameter descriptions in the schema, the description adequately covers purpose, output behavior, and boundary conditions. It could go slightly further in explaining how the gap is derived or how displayMode affects results, but the available structured data fills those gaps.

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

Parameters3/5

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 mentions age, contributions, return assumptions, and income target, but it does not add parameter-level detail; the schema already documents every parameter, so the description is not required to compensate.

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

Purpose4/5

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

The description clearly identifies a specific verb and resource: it projects retirement savings, returns year-by-year balances, and estimates a gap with a 4% withdrawal assumption. It does not explicitly contrast itself with sibling tools like calc_fire or calc_savings_goal, so it is clear but not fully differentiated from alternatives.

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

Usage Guidelines4/5

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

The description gives clear context by framing the calculator as 'read-only educational' and based on 'caller-supplied public inputs,' implying it is for illustrative projections rather than personalized advice. It does not explicitly name when not to use it or point to sibling alternatives, but the context is strong enough for an agent to infer appropriate use.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation2/5

The 14 calc_* tools are individually distinct, but run_public_calculator and compare_public_scenarios overlap with all of them, making it unclear when to use a specific calculator versus the generic runner. list_public_calculators and search_public_docs also have somewhat fuzzy boundaries.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (calc_*, list_*, get_*, search_*, compare_*, run_*), with no mixed casing or irregular verb styles.

Tool Count3/5

At 22 tools, the set is on the heavy side and falls in the borderline 16–25 range. While most calculators earn their place, the generic run_public_calculator and compare_public_scenarios duplicate functionality already covered by the calc_* tools, inflating the count.

Completeness5/5

The surface covers a broad personal-finance calculator domain plus discovery, contract introspection, running, comparing, docs, pricing, and feature details. For a read-only educational server, there are no obvious gaps or dead ends.

Resources