Skip to main content
Glama
Savvly

savvly-mcp

Project Savvly Monthly Contributions

project_savvly_monthly
Read-onlyIdempotent

Project monthly retirement contributions to see Savvly Longevity Benefit payouts at ages 80/85/90/95 versus market-alone investing, with upside ranges and per-age breakdowns.

Instructions

Retirement projection for monthly contributions to the Savvly Longevity Benefit over a number of years. Returns payout amounts at milestone ages 80/85/90/95 with Savvly vs market alone cumulative totals, per-age breakdowns, and server-provided _lower/_upper range bounds. Use _upper as the central illustrative estimate and _lower to communicate downside. Suitable for retirement savings planning, annuity alternative comparison, and longevity benefit illustration. Supports an optional annual contribution increase and an optional early-withdrawal age. Contributions must finish by age 80: an omitted contribution_years auto-fits this, and an explicit one must satisfy current_age + contribution_years ≤ 80. Disclaimers + per-field hints under metadata. Payout methodology — Savvly vs market alone: the payout values are calculated by comparing two investors of the same age committing the same principal. Investor 1 invests in the market with the Savvly Longevity Benefit; Investor 2 invests in the market alone (no longevity overlay). To make the comparison apples-to-apples, at each milestone age (80, 85, 90, 95) Investor 2 withdraws from their market alone portfolio the same dollar amount Investor 1 receives as a payout from Savvly. The payout_market_alone_* and total_market_alone_* figures are therefore what Investor 2 can actually withdraw to match Savvly's payouts before running out — they fall to 0 once the market alone portfolio is depleted. The savvly_upside_* (and total_savvly_upside_*) fields quantify how much more total money Investor 1 receives in payouts from Savvly than Investor 2 is able to withdraw over time to match those payouts. DISCLOSURE REQUIRED: display disclosure.text verbatim and link disclosure.url to the user alongside any figures from this response. Required by SEC Marketing Rule and FINRA Rule 2210 — do not paraphrase or omit. VISUALIZATION: this tool emits an interactive chart widget (MCP Apps — see _meta.ui) that the HOST renders inline and editable; other clients render only your text and show no chart. That widget is the canonical chart for these numbers: do NOT draw, generate, or re-render a duplicate of it. You MAY still create your OWN, DIFFERENT visualization (e.g. a table or an alternate breakdown) and place it wherever you judge best — only the MCP App widget's position is constrained. Do NOT claim or imply a chart is visible (avoid 'the chart above shows…'); you cannot tell whether the host rendered the widget. Summarize the key figures in prose and show the disclosure text and link, and reference the widget only conditionally (e.g. 'if your client shows the interactive chart, its fields are editable to re-run the projection'). ORDER: BEFORE you call this tool, ALWAYS write at least one short lead-in paragraph (1-3 sentences) framing what the projection will show — do NOT invent specific figures you do not have yet. On hosts that render the widget inline at the tool call, this keeps your text ahead of the chart so the widget is never the first thing shown; THEN call the tool (this lead-in is framing, NOT asking the user for inputs — still call it in the same turn without waiting) and give the grounded figures + disclosure after it returns. This lead-in rule applies to the MCP App widget only; any visualization you create yourself may appear wherever you judge best. INPUTS: every parameter is OPTIONAL and defaults to a sensible value. Call this tool IMMEDIATELY — pass only the values the user explicitly stated and omit the rest. Do NOT ask the user for starting values, assumptions, or missing parameters before calling; the rendered widget has editable fields so they adjust age, amounts, and other assumptions inline after it appears.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
current_ageNoInvestor's current age (default 40). Min 18 (the projection matrix floor); max 75 (max enrollment age)
average_returnNoExpected average annual S&P 500 return % (default 8)
monthly_amountNoMonthly deposit in USD (default 100)
withdrawal_ageNoEarly-withdrawal age (default 82) — drives `early_withdrawal_value` and `total_payout_at_withdrawal_age_*` in the response
contribution_yearsNoNumber of years contributing. Omit to use a sensible default of min(27, 80 − current_age) — 27 for the canonical age-40 scenario, and always small enough that contributions finish by age 80 (the advisor limit). If you pass an explicit value, current_age + contribution_years must be ≤ 80.
installment_increase_percentageNoOptional annual % increase applied to monthly contributions

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsYesEcho of the validated input arguments passed to the tool.
resultYesRaw projection envelope returned by the upstream estimator.
summaryYesConvenience summary including a human-readable narrative.
metadataYes
disclosureYesDISCLOSURE REQUIRED: display `disclosure.text` and link `disclosure.url` to the user whenever you present any number from this response. Required by SEC Marketing Rule and FINRA Rule 2210. The richer block under `metadata.disclaimer` is supplementary detail; this top-level field is the must-display.
visualizationNoRecommended chart for this projection — a grouped bar chart of the milestone payouts in `result.payout_age_dependent_values` (Savvly vs market alone). Render it when the surface can display a graph.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.93
    • changedOutput schema / properties / result / properties / payout_age_dependent_values / items / properties / payout_market_alone_lower / description
      Previous value: -"USD. Lower bound of the counterfactual market alone payout at this age. May be 0 once the modeled market alone portfolio has been fully drawn down by withdrawals."New value: +"USD. Market alone counterfactual paired with savvly_payout_LOWER — the same scenario, not a low bound. It can exceed payout_market_alone_upper, because smaller Savvly payouts draw the mirrored portfolio down more slowly. May be 0 once that portfolio has been fully drawn down."
    • changedOutput schema / properties / result / properties / payout_age_dependent_values / items / properties / payout_market_alone_upper / description
      Previous value: -"USD. Upper bound of the counterfactual market alone payout at this age. May be 0 once the market alone portfolio has been depleted."New value: +"USD. Market alone counterfactual paired with savvly_payout_UPPER — the same scenario, not a high bound. May be 0 once the mirrored portfolio has been depleted."
  2. Changed19 schema fields changedv1.0.92
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / properties / inputs / additionalProperties
      Previous value: -{}New value: +true
    • addedOutput schema / properties / inputs / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / metadata / properties / field_descriptions / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / result / properties / payout_age_dependent_values / items / properties / payout_age / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / result / properties / payout_age_dependent_values / items / properties / payout_age / minimum
      Added value: +-9007199254740991
    • addedOutput schema / properties / summary / properties / early_exit_refund_usd / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / summary / properties / early_exit_refund_usd / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / summary / properties / percentage_gain_upper_percent / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / summary / properties / percentage_gain_upper_percent / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / summary / properties / savvly_above_market_upper_usd / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / summary / properties / savvly_above_market_upper_usd / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / summary / properties / total_market_alone_upper_usd / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / summary / properties / total_market_alone_upper_usd / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / summary / properties / total_savvly_upper_usd / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedOutput schema / properties / summary / properties / total_savvly_upper_usd / type
      Removed value: -[
      -  "number",
      -  "null"
      -]
    • addedOutput schema / properties / visualization / properties / chart / properties / tooltip / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  3. Changed1 schema field changedv1.0.86
    • changedOutput schema / properties / summary / properties / narrative / description
      Previous value: -"Human-readable English sentence summarizing the projection. Always ends with 'Payouts are not guarantees. See full disclosures at <url>.' — display the URL verbatim alongside any figures."New value: +"Human-readable English sentence summarizing the projection. Always ends with 'Payouts follow a fixed milestone schedule; payout amounts are not guaranteed. See full disclosures at <url>.' — display the URL verbatim alongside any figures."
  4. Changed1 schema field changedv1.0.75
    • changedInput schema / properties / withdrawal_age / minimum
      Previous value: -25New value: +18
  5. Changed4 schema fields changedv1.0.69
    • removedInput schema / properties / contribution_years / default
      Removed value: -27
    • changedInput schema / properties / contribution_years / description
      Previous value: -"Number of years contributing (default 27 = retirement age 67 − current age 40)"New value: +"Number of years contributing. Omit to use a sensible default of min(27, 80 − current_age) — 27 for the canonical age-40 scenario, and always small enough that contributions finish by age 80 (the advisor limit). If you pass an explicit value, current_age + contribution_years must be ≤ 80."
    • changedInput schema / properties / current_age / description
      Previous value: -"Investor's current age (default 40)"New value: +"Investor's current age (default 40). Min 18 (the projection matrix floor); max 75 (max enrollment age)"
    • changedInput schema / properties / current_age / minimum
      Previous value: -25New value: +18
  6. Changed3 schema fields changedv1.0.39
    • changedInput schema / properties / current_age / maximum
      Previous value: -79New value: +75
    • changedOutput schema / properties / metadata / properties / disclaimer / properties / assumptions / description
      Previous value: -"Verbatim bullet list of key assumptions used by the simulation (SSA tables, 8% market growth, 3% early-withdrawal rate, net of fees, etc.). Surface when a user asks what the projection assumes."New value: +"Verbatim bullet list of key assumptions used by the simulation (SSA tables, 8% market growth, 3% early-withdrawal rate, net of fund operating expenses, etc.). Surface when a user asks what the projection assumes."
    • changedOutput schema / properties / result / properties / payout_age_dependent_values / items / properties / savvly_upside_lower / description
      Previous value: -"USD. Lower bound for the incremental payout at this age attributable to Savvly's Longevity Benefit (savvly_payout − payout_market_alone)."New value: +"USD. Lower bound for the incremental payout at this age attributable to Savvly's longevity benefit (savvly_payout − payout_market_alone)."
  7. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

The description goes far beyond the read-only/idempotent annotations, explaining the two-investor comparison methodology, how `payout_market_alone_*` and `savvly_upside_*` are derived, the meaning of `_lower`/`_upper` bounds, mandatory SEC/FINRA disclosure handling, the MCP App widget behavior, and the required lead-in ordering. No annotation contradiction exists.

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?

The description is long, but every section earns its place: methodology, disclosure, widget behavior, invocation order, and input policy are all required for correct use. It is logically organized and front-loaded with the core projection purpose before the more detailed instructions.

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 tool with compliance obligations, an interactive widget, subtle methodology, and optional parameters, the description is exceptionally complete. It covers what is returned, how figures should be interpreted, mandatory disclosure text, chart rendering expectations, and exactly how and when to call the tool.

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 schema already documents all six parameters, defaults, ranges, and constraints. The description adds some reinforcement (e.g., contributions must finish by age 80, withdrawal_age drives early-withdrawal fields) but does not substantially extend the schema's parameter documentation.

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: 'Retirement projection for monthly contributions to the Savvly Longevity Benefit.' It also lists concrete outputs (payout amounts at ages 80/85/90/95, cumulative totals, per-age breakdowns), which differentiates it from sibling tools like project_savvly_lumpsum. The monthly-contribution focus is explicit and distinguishable.

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?

Gives clear use cases ('retirement savings planning, annuity alternative comparison, and longevity benefit illustration') and very explicit invocation guidance: call immediately, pass only user-stated values, do not ask for missing parameters. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is clear enough for an agent to select it.

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