Skip to main content
Glama

Project a savings plan

project_savings_plan
Read-onlyIdempotent

What "X up front and Y a month for Z years" grows to, and how much of it is growth.

Handles the plan arithmetic that a lump-sum calculation gets wrong: only the
opening amount is invested for the whole span. The house conventions for timing
and compounding are fixed here.

Returns the central figure at the supplied rate and ``total_contributed``. No
range is returned: the outlook's band is stated at the model's horizon and does
not transfer to a plan's shorter dispersion horizon. ``dispersion_horizon_years``
under about ten means the figure is arithmetic at an assumed rate rather than an
expectation. No client profile is read.

``per_annum_by_year`` replaces ``per_annum`` with one rate per year, such as the
glide path rates ``describe_portfolio_outlook`` returns for a strategy with a
target date; ``per_annum`` in the result is then the constant rate that ends this
plan at the same value.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "years": "<years>"
    },
    "name": "project_savings_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearsYes
cadenceNomonthly
per_annumNoWhat the money is assumed to earn each year, as a fraction — 0.06 for 6%. An assumption the caller supplies, not a forecast this tool makes. describe_portfolio_outlook gives it for a particular strategy; pass the unrounded `expected_return` from its figures (before fees, as its text says) rather than the one-decimal text, which moves a twenty-year end value by around 1%. Give this or per_annum_by_year.
contributionNoPaid in each period, at the cadence below.
initial_amountNo
per_annum_by_yearNo

Output Schema

NameRequiredDescriptionDefault
yearsYes
growthYesterminal_value minus total_contributed.
cadenceYes
currencyYes
depositsYesHow many recurring deposits actually land. Full periods only, so thirteen months of a quarterly plan is four deposits and not four and a third.
per_annumYesThe rate this was measured at. Not a forecast.
contributionYesPer period, at the cadence given.
initial_amountYes
terminal_valueYesProjected value at the end, at the central rate.
per_annum_by_yearNoThe yearly rates given, when there were any; per_annum is then the constant rate that ends this plan at the same value, which depends on the plan's own timing of money.
total_contributedYesWhat the client actually pays in. Their own money, and the figure to put beside the projection — the difference between the two is the only part that is modelled.
rate_duration_yearsYesHow much the end value moves when the rate does: a persistent 1pp on the rate is worth about this many percent on the terminal value.
dispersion_horizon_yearsYesThe horizon a RANGE around this figure would have to be built at — not the span, and not the average holding period. Reported because no range is given: see the module docstring. Below about ten years the return model has essentially no predictive power, so a plan whose figure here is under that is not a basis for a decision.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only, idempotent annotations, the description discloses what is returned (central figure and `total_contributed`), why no range is returned, the short-horizon arithmetic caveat, that no client profile is read, and that `per_annum` in the result is the constant-rate equivalent of a yearly path. This is substantial context an agent could not infer from 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.

Conciseness4/5

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

The description is front-loaded with what the tool computes, then layers caveats and parameter guidance in an ordered way. It is dense but nearly every sentence carries useful information; it is slightly longer than strictly necessary but not padded.

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?

For a calculation tool with an output schema, it explains the core arithmetic, the return shape, the short-horizon interpretation caveat, and the rate-input pathways. An agent has enough to call it correctly and interpret the result without opening the output schema.

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

Parameters4/5

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

Schema description coverage is only 33%, so the description must compensate, and it does for the rate parameters: it explains `per_annum_by_year` replaces `per_annum` and how the reported `per_annum` is derived. It also frames the initial/contribution/years semantics, though it leaves `cadence` and the `years` parameter less explicitly explained than the rate options.

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?

The opening sentence gives a specific verb and resource: what an initial amount plus monthly contributions grows to, and the growth portion. It explicitly distinguishes the plan arithmetic from a lump-sum calculation and from `describe_portfolio_outlook`, so an agent can tell what this tool is for.

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?

It gives clear guidance on when to use `per_annum_by_year` versus `per_annum` (glide-path rates from `describe_portfolio_outlook`) and on interpretation when `dispersion_horizon_years` is under ten. It does not explicitly contrast this tool with the `solve_savings_plan` sibling, leaving one likely confusion unresolved.

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.

Resources