Skip to main content
Glama
Savvly

savvly-mcp

Project Savvly Lump-Sum Investment

project_savvly_lumpsum
Read-onlyIdempotent

Project lump-sum investment payouts at ages 80–95, comparing Savvly Longevity Benefit totals with market-alone withdrawals for retirement income planning.

Instructions

Retirement projection for a lump-sum investment in the Savvly Longevity Benefit. Returns payout amounts at each milestone age (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 income planning, annuity alternative analysis, and longevity benefit illustration. Response embeds SEC-style disclaimers and per-field interpretation 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)
funding_amountNoLump sum investment in USD (default 10000)
withdrawal_ageNoEarly-withdrawal age (default 82) — drives `early_withdrawal_value` and `total_payout_at_withdrawal_age_*` in the response

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. Changed2 schema fields changedv1.0.69
    • 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.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description adds substantial behavioral detail: the exact apples-to-apples payout methodology, why market-alone values fall to zero, the meaning of `_lower`/`_upper`, mandatory SEC/FINRA disclosure requirements, the widget rendering behavior, and the instruction not to claim a chart is visible. There is no contradiction with 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 long but well-structured into labeled sections (methodology, disclosure, visualization, order, inputs). Every section carries operational guidance needed for correct use, especially around compliance and widget handling. It is not maximally concise, but the length is justified by the complexity of the tool's behavior.

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?

Combined with a full output schema and annotations, the description covers invocation timing, default handling, payout methodology, disclosure compliance, widget rendering, host variations, and caveats about claiming chart visibility. Nothing an agent needs to call the tool correctly and communicate results responsibly is missing.

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 coverage is 100%, so the baseline is 3 because the schema already explains all four parameters with ranges and defaults. The description adds meaningful invocation-level semantics—every parameter is optional, defaults to a sensible value, and only explicitly user-stated values should be passed—which clarifies agent behavior beyond the schema itself.

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 description clearly states a specific verb and resource: it produces a retirement projection for a lump-sum investment in the Savvly Longevity Benefit. It also enumerates concrete outputs—milestone-age payout amounts, Savvly vs market-alone totals, per-age breakdowns, and range bounds—making it immediately distinguishable from a generic projection or the monthly-investment sibling.

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 strong invocation guidance: call immediately, pass only user-stated parameters, omit the rest, never ask for missing inputs, and write a lead-in paragraph before calling. It states suitable use cases (retirement income planning, annuity alternative analysis, longevity benefit illustration) but does not explicitly name sibling alternatives or conditions for choosing project_savvly_monthly over this tool, so exclusion guidance is slightly less explicit.

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