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.6/5 across 8 of 8 tools scored. Lowest: 4/5.
Each tool has a clearly distinct purpose: eligibility check, product comparison, FAQ, product info, full retirement projection, lump-sum projection, monthly projection, and content search. The three projection tools are differentiated by investment mode (retirement with/without Savvly, lump sum, monthly contributions) with clear parameter and output differences.
Tool names follow a consistent verb_savvly_noun pattern with snake_case. The minor deviation is `project_retirement_with_savvly` instead of `project_savvly_retirement`, but it is still readable and predictable.
8 tools is well-scoped for a product information and projection server. Each tool earns its place covering eligibility, product details, comparisons, FAQs, content search, and three distinct projection types without being excessive.
The tool set provides comprehensive coverage for the Savvly product domain: eligibility, product info, comparisons, FAQs, content search, and multiple projection scenarios (full retirement, lump sum, monthly contributions). There are no obvious gaps for the server's stated purpose.
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 (no minimum; maximum enrollment age 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. These facts come from Savvly's own current records; the response includes primary sources (e.g. SEC filings) for reference.
| 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 is at or under the maximum enrollment age (75); the filing sets no minimum age. |
| 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 readOnlyHint, idempotentHint, and destructiveHint, providing a good baseline. The description adds valuable context: data comes from 'Savvly's own current records' and includes primary sources like SEC filings, enhancing transparency.
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?
Three sentences with no wasted words. The first sentence states the core purpose, followed by eligibility criteria and usage guidance. Perfectly front-loaded and efficient.
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's simplicity, the presence of an output schema, and rich annotations, the description is complete. It covers when to use, what criteria are checked, data provenance, and reference sources.
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?
Input schema has 100% coverage with descriptions for each parameter. The description adds extra meaning by specifying the maximum enrollment age (75) and clarifying the distribution channel options, building on the schema's information.
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 uses the verb 'Check' with object 'eligibility' for Savvly Longevity Benefit, clearly stating the tool's purpose. It distinguishes from sibling tools like projections or comparisons by focusing on eligibility verification.
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... to confirm the person qualifies', providing clear context for when to use. It does not explicitly state when not to use, but the criteria given effectively guide usage.
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 it whenever the user compares Savvly to annuities, target-date funds, managed-payout funds, or any alternative, or asks how Savvly stacks up. It renders an interactive comparison widget the user expects to see. Pass 'all' for the full matrix, or a specific product type. These facts come from Savvly's own current records; the response includes primary sources (e.g. SEC filings) for reference.
| 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 indicate read-only, idempotent, and non-destructive behavior. The description adds that the tool renders an interactive widget, includes primary sources (SEC filings), and notes data recency ('current records'). This provides valuable context beyond annotations, though edge cases or limitations are not addressed.
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 three sentences, front-loaded with purpose and usage, then widget info, then parameter details. Every sentence contributes essential information without redundancy or filler.
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 tool with one parameter and good annotations, the description covers purpose, usage context, widget nature, and source reliability. The presence of an output schema fills in return structure details. No obvious 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 coverage is 100%, so baseline is 3. The description adds minimal value by clarifying that 'all' returns a full matrix, which is already implied by the enum values. No additional parameter details beyond schema are provided.
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 provides a structured comparison between Savvly and an alternative product, using specific verbs like 'Get' and 'compare'. It distinguishes from sibling tools (e.g., project_retirement_with_savvly, check_savvly_eligibility) by focusing solely on side-by-side comparison.
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 to use when the user compares Savvly to specific alternatives (annuities, target-date funds, etc.) or asks how Savvly stacks up. It mentions passing 'all' or a specific type, providing clear context. However, it does not explicitly state when not to use or list alternative tools for other tasks.
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. It is a convenience view of search_savvly_content scoped to the factual FAQ; for richer, audience-specific Q&As (employee / advisor / broker / employer), use search_savvly_content instead. These facts come from Savvly's own current records; the response includes primary sources (e.g. SEC filings) for reference.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Filter the FAQ to one section (kebab-case, e.g. 'tax-legacy'); 'all' returns every entry. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Count of FAQ entries returned. |
| entries | Yes | Filtered FAQ entries (the audience:'general' Q&A slice). |
| section | Yes | Section filter applied to produce this result set ('all' if no filter). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, openWorldHint. Description adds that facts come from Savvly's own records and response includes primary sources, providing useful context beyond 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?
Three concise sentences: first states purpose, second provides usage guidance and alternative, third adds transparency. No waste, front-loaded with key 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?
With output schema present, return values are covered. Description covers purpose, usage, parameter semantics, and data source. Complete for a read-only FAQ tool given the context.
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 description adds value by clarifying filtering by section with kebab-case example and noting 'all' returns every entry. This aids parameter understanding.
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?
Clearly states the tool retrieves answers to frequently asked questions about Savvly, with specific verb 'Get' and resource 'frequently asked questions'. Distinguishes from sibling 'search_savvly_content' by noting it's a convenience view scoped to factual FAQ.
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 to use when user has specific questions about how Savvly works, fees, withdrawals, or regulatory status. Provides 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 security offering longevity protection — use it whenever the user asks what Savvly is, how it works, its fees, eligibility, or payouts, or wants an overview. Pass section to focus the answer (default 'all'). It renders an interactive product overview card the user expects to see. These facts come from Savvly's own current records; the response includes primary sources (e.g. SEC filings) for reference.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Which part of the product profile to focus the text on; the full overview card always renders regardless. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| fees | No | Fee structure in basis points (common vs tracking shares) and the blended range; illustrations are net of fees. |
| name | Yes | Product name (e.g. 'Savvly Longevity Benefit'). |
| links | No | Relevant URLs (website, disclosures, etc.). |
| company | No | Issuer / advisor entity information. |
| tagline | No | Short marketing tagline. |
| category | Yes | Product category slug, e.g. 'longevity_benefit_fund'. |
| channels | No | Distribution channels through which Savvly is offered. |
| investment | No | How contributions are invested: underlying assets (S&P 500 ETF), asset managers, minimum/maximum monthly and lump-sum amounts, market participation. |
| next_steps | No | Suggested next actions for an interested investor. |
| regulatory | No | Regulatory status: SEC registration, Investment Company Act of 1940, advisor, custodian, and is_insurance/is_annuity flags. |
| description | No | Long-form product description. |
| disclaimers | No | SEC-style disclaimers and required legal language. |
| portability | No | Whether the position is portable. |
| tax_treatment | No | Tax treatment of payouts and contributions. |
| longevity_pool | No | How the longevity pool works — exited participants' unused shares may be allocated to remaining participants. |
| payout_schedule | No | Milestone payout schedule at ages 80/85/90/95. |
| early_withdrawal | No | Early-withdrawal / surrender terms and the value returned to the estate. |
| portability_note | No | Detail on portability. |
| positioning_statement | No | One-sentence positioning — what Savvly is and is NOT (not insurance, not an annuity). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds that it renders an interactive card, uses Savvly's own records, and includes primary sources like SEC filings, providing behavioral context beyond annotations. No 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?
Two sentences, front-loaded with purpose, and concise. Every sentence provides 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?
Given the single parameter (with schema coverage and enum), output schema, and annotations, the description is complete. It covers when to use, behavior, and data sources, leaving no gaps for an AI agent.
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?
Only one parameter 'section' with enum values and default 'all', fully described in the schema (100% coverage). The description reinforces its purpose ('Pass `section` to focus the answer') but adds no significant new semantics beyond the schema. Baseline 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?
Description clearly states the tool retrieves complete product information about Savvly and specifies when to use it (user asks about what Savvly is, how it works, fees, eligibility, payouts, or overview). It distinguishes from siblings like check_savvly_eligibility or compare_savvly_vs_alternative by being the general overview tool.
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?
Description explicitly says 'use it whenever the user asks what Savvly is, how it works, its fees, eligibility, or payouts, or wants an overview.' It also mentions the section parameter for focus, providing clear guidance on when and how to invoke. Sibling tools offer alternatives.
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). Requires current_age ≤ retirement_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?
The descriptions discloses age constraints (current_age ≤ retirement_age ≤ life_expectancy), required disclosure under SEC and FINRA rules, visualization widget behavior, and ordering requirements. Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description adds substantial context beyond these, such as the fact that the tool returns a specific set of fields and metadata.
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 long but well-structured with sections for disclosure, visualization, and ordering. Every sentence serves a purpose, given the tool's complexity (visualization, disclosure rules). Could be slightly more concise, but the clarity gained justifies the 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?
Given 12 optional parameters, output schema, and sibling tools, the description covers all necessary aspects: what the tool returns, how to handle visualization (MCP Apps widget, not to re-render), disclosure requirements, and calling order. It is comprehensive enough for an AI agent to use correctly without ambiguity.
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 each parameter having a description and default. The description adds that all parameters are optional and to pass only user-stated values, which is critical for correct invocation. It also provides context like age ordering constraint that complements 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?
The description clearly states it is a 'Full retirement simulation showing the projected savings trajectory WITH and WITHOUT a Savvly allocation across the planning horizon'. This distinguishes it from siblings like check_savvly_eligibility (which checks eligibility) and compare_savvly_vs_alternative (which compares alternatives). The verb 'project' and resource 'retirement trajectory' are specific.
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 the tool IMMEDIATELY without asking for inputs, to write a lead-in paragraph before calling, and to pass only explicitly stated parameters. Also clarifies when not to use: all parameters are optional and defaults are sensible. Differentiates from siblings by emphasizing this is the comprehensive simulation.
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). Min 18 (the projection matrix floor); max 75 (max enrollment age) | |
| 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: projection methodology (comparison of two investors), embedded disclaimers, per-field hint under metadata, and visualization behavior (widget vs text). No contradiction with 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 lengthy (over 500 words) and includes detailed methodology, disclosure rules, and ordering instructions. While well-structured, it could be more concise. Some repetition (e.g., mention of payout methodology twice) reduces efficiency.
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 high schema coverage (100%) and presence of output schema, the description is fully complete. It covers purpose, methodology, usage guidelines, visualization constraints, and compliance requirements. 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 coverage is 100% with descriptions for all four parameters. The description adds usage context beyond the schema: e.g., withdrawal_age drives early_withdrawal_value and total_payout_at_withdrawal_age_*, and advises to omit unstated parameters. This enhances semantics but schema already does most of the work.
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 identifies the tool as a retirement projection for lump-sum investments, specifying it returns payout amounts at milestone ages with comparisons between Savvly and market alone. It distinguishes from siblings like project_savvly_monthly (monthly contributions) and check_savvly_eligibility (eligibility check).
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 states when to use it (retirement income planning, annuity alternative analysis) and provides detailed instructions: call immediately without asking for inputs, display disclosure verbatim, conditionally reference the widget, and write a lead-in paragraph. It also advises not to duplicate the widget chart.
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | No | Investor's current age (default 40). Min 18 (the projection matrix floor); max 75 (max enrollment age) | |
| 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. 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_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?
The description adds extensive behavioral context beyond annotations: the comparison methodology, widget behavior, disclosure requirements, and the lead-in paragraph rule. No contradictions with annotations (readOnlyHint, idempotentHint).
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 very long but front-loaded with essential information. It could be more concise, but every sentence serves a purpose. Structure is logical with clear sections for methodology, disclosure, visualization, and ordering.
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's complexity (6 optional parameters, output schema, widget interaction), the description is thoroughly complete. It covers all aspects an agent needs to use the tool correctly, including edge cases and visual constraints.
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 baseline is 3. The description adds value by explaining the purpose and constraints of each parameter, e.g., the auto-fit logic for contribution_years and the role of withdrawal_age.
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 performs 'Retirement projection for monthly contributions' and specifies outputs like payout amounts at milestone ages. It distinguishes from siblings such as 'project_savvly_lumpsum' by focusing on monthly contributions.
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 indicates suitability for 'retirement savings planning, annuity alternative comparison, and longevity benefit illustration' and provides a lead-in paragraph ordering. It does not explicitly exclude scenarios but context from siblings implies when not to use.
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 — audience-tagged questions and answers compiled from Savvly's marketing collateral plus the factual FAQ, organized by stakeholder (employee, advisor, broker, employer, universal, general) and section (kebab-case slugs, 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. These facts come from Savvly's own current records; the response includes primary sources (e.g. SEC filings) for reference.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cap on matched entries returned. Default 20, max 50. | |
| query | No | Free-text search over questions, answers, and footnotes (case-insensitive). Multi-word queries match entries containing ANY of the words, ranked by relevance. | |
| section | No | Substring match against section slugs (e.g. 'tax', 'retention', 'eligibility'). Case-insensitive. | |
| audience | No | Restrict to one stakeholder audience ('general' is the factual FAQ). Use the exact lowercase token (the enum is case-sensitive). Omit to search across all audiences. |
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_sections | Yes | Section slugs 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. Description adds value by explaining search semantics (multi-word queries match any word, ranked by relevance) and that responses include primary source references. This goes beyond what annotations offer.
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 dense but well-structured. It front-loads the purpose, then adds usage guidance, parameter context, and behavioral details. All sentences are informative, though slightly verbose. Could be trimmed slightly but remains clear.
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 4 parameters, full schema descriptions, annotations, and output schema exist, the description covers purpose, usage, and behavioral nuances adequately. It doesn't explain output schema but that's separate. Sufficient for an agent to use the tool correctly.
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% with descriptions for each parameter. Description adds context: section slugs are 'kebab-case' with examples, audience enum is case-sensitive, and query behavior is explained. This extra detail justifies a 4 over the baseline 3.
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 it searches the Savvly Q&A Content Library with audience and section organization. It specifies the content type (questions/answers) and use cases (positioning, value props, Q&A messaging). While it distinguishes from siblings implicitly, it doesn't explicitly contrast with get_savvly_faq, leaving some overlap ambiguity.
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 guidance: 'Use this when the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging.' This tells the agent when to invoke the tool. It doesn't mention when not to use or suggest alternatives, but the context signals and sibling names help.
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!