Savvly MCP: query fund data, model projections, and compare against alternative retirement products.
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.
Average 4.5/5 across 8 of 8 tools scored.
Each tool targets a distinct purpose: eligibility checking, product comparison, FAQ retrieval, product info, three projection types, and content search. Even the FAQ and search tools are explicitly disambiguated in their descriptions, with FAQ scoped to factual questions and search for richer audience-specific Q&A.
Tool names follow a consistent verb_savvly_noun pattern (check, get, project, search), with a minor deviation for 'project_retirement_with_savvly' where the object precedes savvly. All names use snake_case and are clearly readable, but the slight structural inconsistency prevents a perfect score.
Eight tools is well within the ideal 3-15 range for a focused domain. Each tool serves a distinct, legitimate function, from eligibility checks to retirement projections, making the count appropriate and not bloated.
The tool surface covers the full lifecycle of a user's interaction with Savvly: checking eligibility, understanding the product, reading FAQs, comparing to alternatives, and running detailed projections (full, lump-sum, monthly). It also includes a content search for richer stakeholder-specific questions. No obvious gaps that would cause agent failures.
check_savvly_eligibilityCheck Savvly EligibilityACheck 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 — one of 'individual', 'employer', 'advisor' (default 'individual'). | individual |
| us_resident | No | Whether the person is a US resident |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it states the data source ('Savvly's own current records') and that the response includes primary sources like SEC filings. The annotations already declare readOnlyHint=true and idempotentHint=true, so the description's additional details about data provenance are useful and non-redundant.
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 long, front-loaded with the core purpose, and every sentence adds value: purpose/criteria, usage guidance, and data source/response content. No filler or 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 tool's simplicity, full schema coverage, and the presence of an output schema, the description covers all essential aspects: what it does, when to use it, and the source of truth. It does not need to explain return values because an output schema exists.
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 baseline is 3. The description adds meaningful detail about the age parameter by specifying 'no minimum; maximum enrollment age 75', which is not present in the schema's parameter description. This gives the agent concrete constraints beyond the schema's generic 'Person's current 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 the tool's purpose: 'Check if a person is eligible to invest in the Savvly Longevity Benefit.' It names the specific resource (Savvly Longevity Benefit) and the action (check eligibility), and distinguishes it from sibling tools like compare_savvly_vs_alternative or get_savvly_product_info. The listed criteria (age, residency, channel) further specify the scope.
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 usage context: 'Use before recommending Savvly as a retirement income or annuity alternative to confirm the person qualifies.' This tells the agent when to invoke the tool. However, it does not mention when not to use it or name an alternative tool, so it lacks the full when/when-not structure.
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 ProductAGet 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 | No | Which product type to compare Savvly against. Use EXACTLY one of: 'fixed_annuity', 'variable_annuity', 'indexed_annuity', 'target_date_fund', 'managed_payout_fund', or 'all' for the full matrix. Pick a SPECIFIC annuity subtype — there is no generic 'annuity'. |
| 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'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context: it states the data source ('Savvly's own current records'), includes primary sources, and mentions the interactive widget output. This is credible value beyond the annotations, though it doesn't cover every edge case.
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 the main purpose, and includes usage triggers, parameter guidance, and data provenance without redundancy. Every sentence contributes to the agent's understanding.
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 has one parameter, an output schema, and clear annotations. The description covers when to use it, what to pass, and what to expect (interactive widget, primary sources). There are no major gaps given the tool's simplicity.
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 input schema already has 100% coverage with a detailed enum description. The tool's description adds only a brief reminder to pass 'all' for the full matrix, which is already implied. Therefore, it meets the baseline for schema-driven documentation but does not add significant new parameter semantics.
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 states the tool's function with a specific verb and resource: 'Get a structured comparison between Savvly and another retirement product type.' It clearly distinguishes itself from sibling tools (none of which offer comparisons) and the title reinforces the purpose.
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 gives explicit when-to-use guidance: '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 also clarifies how to request the full matrix, but does not explicitly mention when not to use it (e.g., for general product info), so it falls slightly short of a 5.
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 FAQAGet answers to frequently asked questions about Savvly. Use when the user has specific questions about how Savvly works, expenses, 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 |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: facts come from Savvly's current records and the response includes primary sources (e.g., SEC filings) for reference. This provides transparency about data provenance and response content without any 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?
Three informative sentences, each earning its place: purpose, usage/alternative, and data source. Front-loaded with the primary action, no wasted words, and well-structured for quick agent parsing.
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 (one optional parameter, output schema exists). The description covers purpose, when to use, exclusions, and source context. With the output schema handling return value details, the description is fully sufficient for an agent to select and invoke 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% for the single parameter 'section', which includes an enum and a clear description. The tool description does not add parameter-specific detail beyond the schema, but that is not needed because the schema itself fully explains the parameter. 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 states 'Get answers to frequently asked questions about Savvly' with a specific verb and resource. It also distinguishes from the sibling 'search_savvly_content' by positioning itself as a convenience view scoped to factual FAQs, making the purpose unmistakable.
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 states when to use: 'Use when the user has specific questions about how Savvly works, expenses, withdrawals, or regulatory status.' It also names the alternative and exclusion: 'for richer, audience-specific Q&As... use search_savvly_content instead.' This is ideal usage guidance.
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 InfoAGet 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 expenses, 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 — one of 'all', 'overview', 'regulatory', 'investment', 'expenses', 'payouts', 'tax', 'distribution' (default 'all'). The full overview card always renders regardless. | all |
| Name | Required | Description |
|---|---|---|
| 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. |
| expenses | No | Expense structure in basis points (common vs tracking shares) and the blended range; illustrations are net of expenses. |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar for additional disclosure is lower. The description adds valuable context: it 'renders an interactive product overview card' and notes facts come from 'Savvly's own current records' with primary sources like SEC filings for reference, going beyond the structured data.
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 the primary purpose, and each sentence earns its place: purpose and usage, parameter guidance, and behavioral context with data sources. There is no redundant phrasing or unnecessary detail.
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 one optional parameter, full schema coverage, an output schema present, and clear annotations, the description covers all necessary aspects: purpose, when to use, behavior, and parameter effect. It is complete for a read-only information tool without needing to explain return values.
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 input schema covers the `section` parameter fully with enum, default, and description, achieving 100% coverage, so the baseline is 3. The description reinforces 'Pass `section` to focus the answer' and adds a meaningful detail: 'The full overview card always renders regardless,' clarifying the parameter's actual scope 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?
The description clearly states 'Get complete product information about Savvly' and lists specific query types (what Savvly is, how it works, expenses, eligibility, payouts), which distinguishes it from specialized siblings like get_savvly_faq and check_savvly_eligibility. The verb 'get' plus the resource 'product information' is specific and unambiguous.
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 it whenever the user asks what Savvly is, how it works, its expenses, eligibility, or payouts, or wants an overview,' providing clear when-to-use guidance. It does not explicitly name when-not-to-use or alternative tools, but the scenarios effectively differentiate it from siblings.
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 SavvlyAFull 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) |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true and idempotentHint=true in annotations, the description adds substantial behavioral context: legal disclosure requirements under SEC/FINRA rules, the canonical interactive chart behavior, prohibition on claiming chart visibility, and the mandatory lead-in ordering. This goes well beyond what annotations cover.
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 ALL-CAPS section markers (DISCLOSURE, VISUALIZATION, ORDER) and front-loads the core purpose. Every sentence carries important information, though it could be tightened or split into clearer paragraphs.
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 description covers legal disclosure, output fields, widget interaction, ordering constraints, defaults, and fallback behavior. With 12 optional parameters and an output schema, this is highly complete and leaves little ambiguity for an 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?
Schema description coverage is 100% per parameter (type, default, min/max), so the baseline is 3. The description only adds aggregate guidance that all parameters are optional and to pass only user-stated values, which is more of a usage rule than per-parameter semantic enrichment.
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 specific verb+resource+scope distinguishes it from sibling tools like project_savvly_lumpsum or project_savvly_monthly, and it also lists key return values.
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 gives strong contextual usage guidance: 'Call this tool IMMEDIATELY', 'do NOT ask the user for starting values', and a specific lead-in paragraph order. However, it does not explicitly mention when to use this tool over alternative sibling projection tools, so it falls short of a 5.
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 InvestmentARetirement 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate read-only, idempotent, and non-destructive behavior, the description goes far beyond by disclosing SEC/FINRA compliance requirements ('display `disclosure.text` verbatim'), the interactive widget emission and its rendering constraints, and the requirement to avoid implying a chart is visible. It also details the payout methodology and the meaning of market-alone values, adding significant behavioral context not present in 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 front-loaded with a clear summary, but it is extremely verbose, containing extensive sections on disclosure, visualization, and ordering. Some statements are redundant or could be tightened (e.g., the multiple negative commands about charts). While every sentence carries operational importance, the overall length and repetition make it less concise than ideal.
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 (4 optional parameters, rich output schema, legal/visualization concerns), the description is remarkably complete. It covers use cases, safety, methodology, compliance, widget behavior, and invocation order. It even explains how the response should be presented to the user. The presence of an output schema means return values are documented elsewhere, but the description still adds essential context for successful tool use.
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%, so the baseline is 3. The description adds a bit of contextual meaning (e.g., all parameters are optional and default to sensible values; the rendered widget has editable fields for adjusting assumptions), but it does not elaborate on each parameter beyond what the schema already provides. The methodology explanation focuses on output semantics rather than input semantics.
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 opens with a specific verb+resource: 'Retirement projection for a lump-sum investment in the Savvly Longevity Benefit.' It clearly enumerates what is returned (payout amounts at milestone ages, Savvly vs market alone totals, per-age breakdowns, range bounds). This distinguishes it from sibling tools like project_savvly_monthly (monthly contributions) and compare_savvly_vs_alternative (comparison analysis).
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 strong usage context: 'Suitable for retirement income planning, annuity alternative analysis, and longevity benefit illustration.' It also gives explicit sequencing instructions ('BEFORE you call this tool, ALWAYS write at least one short lead-in paragraph') and a directive to call immediately with only user-stated values. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of a 5.
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 ContributionsARetirement 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (which already state readOnlyHint, idempotentHint, destructiveHint) by disclosing detailed behavioral traits: returns payout amounts with _lower/_upper ranges, explains the payout methodology (comparing two investors), mandates disclosure text/link, describes the interactive widget behavior, and specifies the ordering requirement (lead-in paragraph before calling). No contradictions with annotations exist; it enriches the agent's understanding of side effects and constraints.
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 clear sections for purpose, methodology, disclosure, visualization, ordering, and inputs. It is front-loaded with the core purpose and each section carries necessary information (especially legal and UI instructions). Some redundancy exists (e.g., repeated emphasis on not asking for inputs), but given the complexity of the tool, the length is justified. A tighter edit could improve brevity, but it remains efficient for its 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 description is exceptionally complete given the tool's complexity and rich annotations/schema. It covers what the tool returns, how to interpret results (_lower/_upper), disclosure obligations, widget rendering behavior, and the exact calling sequence (lead-in text, then tool call, then grounded figures). The presence of an output schema further reduces the need to describe return fields in prose. An agent has sufficient context to invoke the tool 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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema: it explains the contribution_years constraint ('must finish by age 80', auto-fits when omitted), how withdrawal_age drives specific output fields, and the meaning of _upper/_lower as central/downside estimates. While not every parameter is re-explained, it enhances understanding of the key parameters and their relationship to outputs.
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's function: 'Retirement projection for monthly contributions to the Savvly Longevity Benefit.' It specifies the resource (Savvly Longevity Benefit), the action (projection), and the scope (monthly contributions, milestone ages 80-95). It distinguishes itself from sibling tools like project_savvly_lumpsum by explicitly focusing on monthly contributions, making the purpose unmistakable.
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 clear context on when to use the tool: 'Suitable for retirement savings planning, annuity alternative comparison, and longevity benefit illustration.' It does not explicitly name alternatives or exclusions, but the monthly-vs-lump-sum distinction is implicit in the title and description. It also gives operational guidance on how to invoke it ('Call this tool IMMEDIATELY', pass only user-stated values), which is valuable for an agent.
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 LibraryASearch 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. Use EXACTLY one of: 'employee', 'advisor', 'broker', 'employer', 'universal', or 'general' ('general' is the factual FAQ). Omit to search across all audiences. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description only needs to add behavioral context. It does so by revealing that each entry contains the verbatim answer, disclaimer footnotes, and that responses include primary sources (e.g., SEC filings). This provides useful transparency about return content beyond what annotations cover, though it doesn't discuss limitations like result ordering or pagination.
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 well-structured and front-loaded with the core purpose. It uses three sentences to efficiently convey the data organization, usage scenarios, and return content. Every sentence contributes meaningful 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?
The description is comprehensive given the tool's complexity. It covers the data domain, content organization, intended use cases, and what each entry includes. With a full schema and annotations, the description adds sufficient context to enable correct selection and invocation, and it clearly differentiates from sibling tools.
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%, so the baseline is 3. The description enhances parameter understanding by explaining that content is organized by stakeholder (which maps to the audience enum) and section slugs (which maps to the section parameter), and by clarifying that entries contain answers and footnotes. This adds context beyond the schema's individual parameter descriptions.
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, specifying the content type (audience-tagged Q&A from marketing collateral and factual FAQ). It distinguishes itself from sibling tools by emphasizing its use for positioning, value props, and audience-specific talking points, which is not covered by other tools like get_savvly_faq or get_savvly_product_info.
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 the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging.' This gives clear context for when to use the tool, but it does not mention when NOT to use it or explicitly name alternative tools, so it falls short of a 5.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.