Skip to main content
Glama

QuantCalc Retirement Engine

by app.quantcalc
OverviewDiscussionsAdmin

Run a retirement projection

run_retirement_projection
Read-only

Runs a Monte Carlo retirement projection on the QuantCalc engine and returns the success rate, the ending-portfolio distribution, and the assumptions that produced them. The result states the return model that ran, the number of paths, and the income assumptions it used, including when there are none. Income tax is not modelled by this tool; run_tax_aware_projection models it.

Input Schema

NameRequiredDescriptionDefault
pensionNoYearly pension income. Default 0.
allocationsNoPercentages summing to 100: [US stocks, international stocks, bonds, real estate, cash]. Default [60,10,25,5,0].
current_ageYesCurrent age of the primary person.
bucket_yearsNoOnly with withdrawal_strategy bucket: years of spending held in the cash bucket, 1-10.
return_modelNoHow returns are generated. parametric (default): the forward-looking published assumptions. bootstrap: stationary block bootstrap of historical months. historical: replays real months from 1926 in order. The last two need a PRO licence; without one the engine runs parametric and the result says so.
ss_start_ageNoAge Social Security starts. Default 67.
inflation_rateNoAnnual inflation as a percent, e.g. 2.5. Default 2.5.
retirement_ageNoAge work income stops. Defaults to current age.
returns_sourceNoWhich published return set to use (see list_return_assumption_sources). Default jpmorgan.
annual_spendingYesPlanned yearly spending in today's dollars, before income tax (this tool runs the standard engine, which does not model tax).
current_savingsYesTotal invested portfolio today, in dollars.
life_expectancyNoAge the plan must last until. Default 92.
social_securityNoYearly Social Security in today's dollars. Default 0 — and 0 is reported as an explicit assumption, not hidden.
pension_start_ageNoAge the pension starts. Default 65.
withdrawal_strategyNoSpending rule. fixed (default): the planned amount, inflation-adjusted, every year. guyton-klinger: guardrails that cut or raise spending as the portfolio moves. vpw: variable percentage withdrawal. bucket: a cash reserve of bucket_years of spending.
monthly_contributionNoMonthly savings until retirement. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / bucket_years
      Added value: +{
+  "description": "Only with withdrawal_strategy bucket: years of spending held in the cash bucket, 1-10.",
+  "type": "integer"
+}
    • addedInput schema / properties / return_model
      Added value: +{
+  "description": "How returns are generated. parametric (default): the forward-looking published assumptions. bootstrap: stationary block bootstrap of historical months. historical: replays real months from 1926 in order. The last two need a PRO licence; without one the engine runs parametric and the result says so.",
+  "enum": [
+    "parametric",
+    "bootstrap",
+    "historical"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / withdrawal_strategy
      Added value: +{
+  "description": "Spending rule. fixed (default): the planned amount, inflation-adjusted, every year. guyton-klinger: guardrails that cut or raise spending as the portfolio moves. vpw: variable percentage withdrawal. bucket: a cash reserve of bucket_years of spending.",
+  "enum": [
+    "fixed",
+    "guyton-klinger",
+    "vpw",
+    "bucket"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / annual_spending / description
      Previous value: -"Planned yearly spending in today's dollars."New value: +"Planned yearly spending in today's dollars, before income tax (this tool runs the standard engine, which does not model tax)."
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the PRO-licence requirement for bootstrap and historical return models, the silent fallback to parametric without one, and the fact that the result self-reports the return model, path count, and income assumptions including the zero case. This is exactly the kind of behavioural context annotations cannot carry.

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

Conciseness4/5

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

Two sentences, front-loaded with the verb and outputs, then the routing and output-content detail. No filler. Slightly dense phrasing ('including when there are none') costs a point but nothing is wasted.

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

Completeness5/5

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

With no output schema, the description compensates by enumerating the return payload (success rate, distribution, assumptions, return model, path count) and the licence-dependent behaviour of two of the three return models. For a 16-parameter simulation tool, an agent has what it needs to call it and interpret the result.

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% across all 16 parameters, including enums and defaults, so the schema does the heavy lifting. The description reinforces the tax caveat on annual_spending but adds no syntax, format, or interaction detail beyond what the schema already documents. Baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Runs a Monte Carlo retirement projection') plus the engine it runs on and the three outputs it produces (success rate, ending-portfolio distribution, assumptions). It also names the sibling it is not, run_tax_aware_projection, so an agent can separate the two 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.

Usage Guidelines4/5

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

Explicitly states the exclusion condition ('Income tax is not modelled by this tool') and routes to the alternative that does model it. It does not address the other plausible siblings (optimize_social_security_claiming, list_return_assumption_sources, compare_return_assumptions), so the routing is clear but partial.

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

All QuantCalc Retirement Engine toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources