savvly
Server Details
Savvly MCP: query fund data, model projections, and compare against alternative retirement products.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Tools are mostly distinct: eligibility, comparison, FAQ, product info, three projection types, and content search. The three projection tools could cause some confusion but their names and descriptions clearly differentiate between full retirement simulation, lump sum, and monthly contributions.
All tools use snake_case with a consistent verb_noun pattern (check_, compare_, get_, project_, search_). No style mixing or ambiguous verbs.
With 8 tools, the set is well-scoped for a retirement product server. It covers eligibility, information, comparison, various projections, FAQs, and content search without being excessive or insufficient.
The tool surface covers core informational and illustrative needs: eligibility, product info, comparison, multiple projection scenarios, and Q&A. Minor gaps like account management or purchase tools exist but are outside the apparent informational scope.
Available Tools
8 toolscheck_savvly_eligibilityCheck Savvly EligibilityARead-onlyIdempotentInspect
Check if a person is eligible to invest in the Savvly Longevity Benefit. Eligibility is based on age (25–75), US residency, and distribution channel (individual, employer-sponsored, advisor-placed). Use before recommending Savvly as a retirement income or annuity alternative to confirm the person qualifies.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Person's current age | |
| channel | No | Distribution channel | individual |
| us_resident | No | Whether the person is a US resident |
Output Schema
| Name | Required | Description |
|---|---|---|
| channel | Yes | Distribution channel under consideration for this check. |
| message | Yes | Human-readable explanation of the eligibility outcome. |
| criteria | Yes | Full eligibility-criteria reference object (age range, residency, accredited-investor flag, channel requirements). |
| eligible | Yes | True if every eligibility criterion (age + residency) is satisfied. |
| age_eligible | Yes | True if age falls within the 25–75 minimum/maximum range. |
| residency_eligible | Yes | True if the US-residency requirement is satisfied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds the specific eligibility logic (age range 25-75, US residency, distribution channel), which is valuable context beyond annotations. No contradictions. Some minor behavioral details (e.g., error handling) are omitted, but acceptable given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states purpose and criteria, second gives usage guidance. Concise, front-loaded, no redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the input schema (100% coverage) and annotations (behavioral safety), the description covers purpose, criteria, usage context. An output schema exists to detail return values, so no need for that here. The description is complete for an eligibility check tool with low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting a baseline of 3. The description adds the age eligibility range (25-75) not present in the schema's age description, providing an important constraint. For channel and us_resident, it essentially reiterates the schema, but the age range addition merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks eligibility for the Savvly Longevity Benefit, listing criteria (age, US residency, channel). While it implies a role among siblings via 'use before recommending', it doesn't explicitly differentiate from tools like projection or comparison, but the purpose is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before recommending Savvly as a retirement income or annuity alternative', providing clear context for when to invoke this tool relative to sibling tools. No alternatives are named, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_savvly_vs_alternativeCompare Savvly vs Alternative ProductARead-onlyIdempotentInspect
Get a structured comparison between Savvly and another retirement product type. Use when the user is evaluating options for longevity risk, retirement income, or comparing Savvly to annuities, target-date funds, or other strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| alternative | Yes | The product type to compare against Savvly, or 'all' for the full matrix |
Output Schema
| Name | Required | Description |
|---|---|---|
| savvly | Yes | Savvly's profile across the comparison dimensions. |
| metadata | Yes | Comparison dimensions, definitions, and source notes. |
| comparison | No | The selected alternative product's profile. Present when `alternative` is a specific product type (i.e. not 'all'). |
| comparisons | No | Full comparison matrix — one entry per alternative product type. Present when `alternative` is 'all'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no behavioral detail beyond purpose, which is acceptable as annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter with full schema coverage, annotations providing safety guarantees, and existence of output schema, description is complete enough for agent to correctly invoke tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and parameter description in schema lists all enum values. Description adds no additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a structured comparison' between Savvly and another product type. It distinguishes from sibling tools like project_* or check_eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user is evaluating options for longevity risk, retirement income, or comparing Savvly to annuities, target-date funds, or other strategies.' Provides clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_savvly_faqGet Savvly FAQARead-onlyIdempotentInspect
Get answers to frequently asked questions about Savvly. Use when the user has specific questions about how Savvly works, fees, withdrawals, or regulatory status. For richer, audience-specific Q&As (employee / advisor / broker / employer), use search_savvly_content instead.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Filter FAQ by topic | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | Topic filter applied to produce this result set ('all' if no filter). |
| total | Yes | Count of FAQ entries returned. |
| entries | Yes | Filtered FAQ entries. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to reiterate safety. The description adds some context about the scope of questions but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guidance, no filler. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description covers when to use, provides an alternative, and distinguishes from siblings. No gaps for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema includes a description for the single parameter 'topic' with an enum. The description does not add further parameter-level details, but the enum values are self-explanatory. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves answers to frequently asked questions about Savvly. It distinguishes itself from the sibling tool `search_savvly_content` by noting the latter handles richer, audience-specific Q&As.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: 'when the user has specific questions about how Savvly works, fees, withdrawals, or regulatory status.' Also provides an explicit alternative: 'For richer, audience-specific Q&As... use search_savvly_content instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_savvly_product_infoGet Savvly Product InfoARead-onlyIdempotentInspect
Get complete product information about Savvly, an SEC-registered investment fund offering longevity protection. Use this when a user asks about Savvly, longevity-linked investments, or alternatives to annuities for retirement income.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Product name (e.g. 'Savvly Longevity Benefit'). |
| tagline | No | Short marketing tagline. |
| category | Yes | Product category slug, e.g. 'longevity_benefit_fund'. |
| description | No | Long-form product description. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the product type (investment fund) but does not need to repeat safety traits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the tool's output, second provides usage guidance. It is concise, front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and an output schema, the description fully covers purpose and context. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered. Baseline 4 applies since no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'complete product information about Savvly' and specifies it's an SEC-registered investment fund for longevity protection. This verb+resource combination is distinct from sibling tools that handle eligibility, comparisons, FAQs, or projections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when a user asks about Savvly, longevity-linked investments, or alternatives to annuities for retirement income,' providing clear context. While it doesn't list exclusions, the sibling tool names offer alternatives, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_retirement_with_savvlyProject Retirement Trajectory With SavvlyARead-onlyIdempotentInspect
Full retirement simulation showing the projected savings trajectory WITH and WITHOUT a Savvly allocation across the planning horizon (current_age → life_expectancy). Returns gap_score, possible_higher_monthly_paycheck, a server-provided headline message, and a per-year age_dependent_values[] timeline. Disclaimers + per-field hints under metadata. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | No | Current age (default 40) | |
| inflation_rate | No | Expected annual inflation rate % (default 3) | |
| retirement_age | No | Planned retirement age (default 68) | |
| life_expectancy | No | Planning horizon (default 100) | |
| monthly_paycheck | No | Desired monthly retirement paycheck in USD (default 4500) | |
| monthly_contribution | No | Monthly retirement contribution in USD (default 1000) | |
| percentage_in_savvly | No | Percentage of the retirement portfolio allocated to Savvly (default 5) | |
| pre_retirement_return | No | Expected pre-retirement annual return % (default 6) | |
| annual_income_increase | No | Annual contribution % increase (default 2) | |
| post_retirement_return | No | Expected post-retirement annual return % (default 5) | |
| other_retirement_income | No | Other monthly retirement income in USD (default 1600) | |
| current_retirement_savings | No | Current total retirement savings in USD (default 60000) |
Output Schema
| Name | Required | Description |
|---|---|---|
| inputs | Yes | |
| result | Yes | |
| summary | Yes | Convenience summary. The narrative carries the canonical full-disclosures URL inline; display it verbatim alongside any figures from this response. |
| metadata | Yes | |
| disclosure | Yes | DISCLOSURE 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. |
| visualization | No | Recommended chart for this projection — a year-by-year area chart of `result.age_dependent_values` (savings with vs. without Savvly). Render it when the surface can display a graph. The richer `metadata.display_hints` block carries the same chart plus layout/tooltip detail. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: discloses SEC/FINRA disclosure requirements, widget behavior (MCP Apps rendering), and cautions against creating duplicate visualizations. Also explains return structure and optional parameters. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all consistent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: purpose first, then disclosure, visualization, ordering rules, and inputs. It is front-loaded with key information and every sentence serves a purpose. Could be slightly more concise, but complexity justifies length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Highly comprehensive: covers purpose, usage rules, disclosure, widget behavior, return structure, metadata, and input defaults. Leaves no essential guidance for correct invocation. Output schema existence reduces need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 12 parameters described). The description adds only general guidance that all parameters are optional and default to sensible values, but does not provide additional semantic detail beyond the schema for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'full retirement simulation showing the projected savings trajectory WITH and WITHOUT a Savvly allocation across the planning horizon'. It distinguishes itself from siblings like project_savvly_lumpsum or project_savvly_monthly by being a holistic simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call immediately without asking for inputs (params are optional), provides a lead-in paragraph rule, and covers disclosure and visualization constraints. It clearly differentiates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_savvly_lumpsumProject Savvly Lump-Sum InvestmentARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | No | Investor's current age (default 40) | |
| average_return | No | Expected average annual S&P 500 return % (default 8) | |
| funding_amount | No | Lump sum investment in USD (default 10000) | |
| withdrawal_age | No | Early-withdrawal age (default 82) — drives `early_withdrawal_value` and `total_payout_at_withdrawal_age_*` in the response |
Output Schema
| Name | Required | Description |
|---|---|---|
| inputs | Yes | Echo of the validated input arguments passed to the tool. |
| result | Yes | Raw projection envelope returned by the upstream estimator. |
| summary | Yes | Convenience summary including a human-readable narrative. |
| metadata | Yes | |
| disclosure | Yes | DISCLOSURE 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. |
| visualization | No | Recommended 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds methodology details for Savvly vs market alone calculations, explains field meanings (_lower/_upper), mandates SEC/FINRA disclosure, and describes widget behavior without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with logical sections (purpose, methodology, disclosure, visualization, ordering). Each sentence adds necessary guidance; no fluff, though some redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 optional params, output schema present, rich annotations), the description thoroughly covers usage context, methodology, disclosure requirements, widget integration, and ordering with siblings, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions and defaults for all 4 parameters. Description adds value by instructing to omit default parameters and clarifying the role of withdrawal_age in driving specific response fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a retirement projection for a lump-sum investment, specifies the output (payout amounts at milestone ages with comparisons), and distinguishes from sibling tools like project_savvly_monthly by focusing on lump-sum vs monthly investments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (retirement planning, annuity analysis), ordering instructions (write lead-in before call, call immediately without asking), and how to handle the widget and visualization, which are detailed and actionable for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project_savvly_monthlyProject Savvly Monthly ContributionsARead-onlyIdempotentInspect
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | No | Investor's current age (default 40) | |
| average_return | No | Expected average annual S&P 500 return % (default 8) | |
| monthly_amount | No | Monthly deposit in USD (default 100) | |
| withdrawal_age | No | Early-withdrawal age (default 82) — drives `early_withdrawal_value` and `total_payout_at_withdrawal_age_*` in the response | |
| contribution_years | No | Number of years contributing (default 27 = retirement age 67 − current age 40) | |
| installment_increase_percentage | No | Optional annual % increase applied to monthly contributions |
Output Schema
| Name | Required | Description |
|---|---|---|
| inputs | Yes | Echo of the validated input arguments passed to the tool. |
| result | Yes | Raw projection envelope returned by the upstream estimator. |
| summary | Yes | Convenience summary including a human-readable narrative. |
| metadata | Yes | |
| disclosure | Yes | DISCLOSURE 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. |
| visualization | No | Recommended 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond by detailing the payout methodology (two investors comparison), explaining market-alone depletion, and disclosure requirements. It also discloses visualization behavior (MCP App widget and conditional rendering), adding rich context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured into sections (purpose, methodology, disclosure, visualization, ordering). It is front-loaded with the core purpose. Some verbosity is justified by complexity, but could be slightly more concise without losing key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, 100% schema coverage, existence of output schema, and no required fields, the description covers everything: methodology, interpretation, disclosure, visualization, and call ordering. It leaves no gaps for an AI agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all 6 parameters described. The description adds value by stating all parameters are optional with sensible defaults, explaining the effect of 'withdrawal_age' on response fields, and instructing to call immediately without asking for inputs. Despite full schema coverage, it enhances usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a retirement projection for monthly contributions to the Savvly Longevity Benefit, listing specific outputs (payouts at milestones, cumulative totals). It distinguishes from sibling tools like 'project_savvly_lumpsum' which handles lump sums, by specifying monthly contributions and having a dedicated name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use contexts (retirement savings, annuity comparison), required disclosure instructions (SEC/FINRA), lead-in writing orders, and call-ordering (call immediately without asking for inputs). It also explains how to interpret fields like '_upper' and '_lower', covering both usage and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_savvly_contentSearch Savvly Q&A Content LibraryARead-onlyIdempotentInspect
Search the Savvly Q&A Content Library — 50 audience-tagged questions and answers compiled from Savvly's marketing collateral, organized by stakeholder (employee, advisor, broker, employer, universal) and subsection (e.g. 'Tax & Legacy', 'Retention & Talent Strategy', 'Implementation'). Use this when the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging. Each entry carries the verbatim answer plus any disclaimer footnotes attached to it in the source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cap on matched entries returned. Default 20, max 50. | |
| query | No | Free-text substring filter applied to questions, answers, and footnotes. Case-insensitive. | |
| audience | No | Restrict to one stakeholder audience. Omit to search across all audiences. | |
| subsection | No | Substring match against subsection labels (e.g. 'Tax', 'Retention', 'Eligibility'). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
| entries | Yes | Matched Q&A entries. |
| matched | Yes | Count of entries matching the supplied filters. |
| filter_applied | Yes | Echo of the filters that produced this result set. |
| total_in_library | Yes | Total Q&A entry count in the library across all audiences. |
| available_subsections | Yes | Subsection labels available within the (optionally) selected audience. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds that each entry includes the 'verbatim answer plus any disclaimer footnotes,' providing additional behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, followed by usage guidance. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the description's mention of returned data structure (verbatim answer plus footnotes), the description is complete for a search tool with clear annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to compensate for missing param info. The description adds context about the library structure but not detailed parameter semantics, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'the Savvly Q&A Content Library' with specific resources (50 audience-tagged questions/answers). It distinguishes from sibling tools by focusing on Q&A content, not eligibility, comparisons, or projections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'when the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging.' Although it doesn't list exclusions, the context and sibling list make alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!