savvly
Server Details
Savvly Longevity Benefit Fund: product, comparisons, eligibility, and retirement projections.
- 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.4/5 across 8 of 8 tools scored.
Each tool serves a clearly distinct purpose: eligibility, comparison, FAQ, product info, full retirement projection, lump-sum projection, monthly projection, and content search. No overlaps or confusion between them.
All tools follow snake_case with verb_noun pattern. There is a minor inconsistency: project_retirement_with_savvly uses 'with_savvly' while the other projection tools use 'savvly_lumpsum' and 'savvly_monthly' without 'with', but overall pattern is strong.
8 tools is well-scoped for a financial product information and projection server. Each tool earns its place covering eligibility, comparisons, FAQs, product info, three types of projections, and content search.
The tool set covers the core domain comprehensively: eligibility, comparisons, product info, FAQs, multiple projection types, and content search. Minor gap: no tool for account management or application initiation, but that seems outside the server's intended scope.
Available Tools
8 toolscheck_savvly_eligibilityCheck Savvly EligibilityARead-onlyIdempotentInspect
Check if a person is eligible to invest in Savvly's Longevity Benefit Fund. Eligibility is based on age (25–79), US residency, and distribution channel (individual, employer-sponsored, advisor-placed). Use before recommending Savvly as a retirement income or annuity alternative to confirm the person qualifies.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Person's current age | |
| channel | No | Distribution channel | individual |
| us_resident | No | Whether the person is a US resident |
Output Schema
| Name | Required | Description |
|---|---|---|
| channel | Yes | Distribution channel under consideration for this check. |
| message | Yes | Human-readable explanation of the eligibility outcome. |
| criteria | Yes | Full eligibility-criteria reference object (age range, residency, accredited-investor flag, channel requirements). |
| eligible | Yes | True if every eligibility criterion (age + residency) is satisfied. |
| age_eligible | Yes | True if age falls within the 25–79 minimum/maximum range. |
| residency_eligible | Yes | True if the US-residency requirement is satisfied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds specific eligibility criteria (age range, residency, channel), giving useful behavioral 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?
Two sentences, front-loaded with purpose, concise and to the point. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but known), the description fully covers the eligibility check criteria and use case. 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 good descriptions. The description adds no new per-parameter detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks eligibility for Savvly's Longevity Benefit Fund based on age, residency, and channel. It distinguishes from sibling tools like projections or comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before recommending Savvly...' providing clear context for when to use. No explicit when-not, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_savvly_vs_alternativeCompare Savvly vs Alternative ProductARead-onlyIdempotentInspect
Get a structured comparison between Savvly and another retirement product type. Use when the user is evaluating options for longevity risk, retirement income, or comparing Savvly to annuities, target-date funds, or other strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| alternative | Yes | The product type to compare against Savvly, or 'all' for the full matrix |
Output Schema
| Name | Required | Description |
|---|---|---|
| savvly | Yes | Savvly's profile across the comparison dimensions. |
| metadata | Yes | Comparison dimensions, definitions, and source notes. |
| comparison | No | The selected alternative product's profile. Present when `alternative` is a specific product type (i.e. not 'all'). |
| comparisons | No | Full comparison matrix — one entry per alternative product type. Present when `alternative` is 'all'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns a 'structured comparison' but does not elaborate on behavior beyond that. It is consistent 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 two sentences: first states purpose, second gives usage guidance. No unnecessary words or repetition. Highly 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 rich annotations and presence of an output schema, the description is sufficient for an agent to understand when and how to use the tool. It covers purpose and usage without missing critical details.
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 has 100% coverage with parameter 'alternative' having a description and enum values. The description does not add additional meaning beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.
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: 'Get a structured comparison between Savvly and another retirement product type.' It specifies the verb (get), resource (comparison), and distinguishes from sibling tools like project_retirement_with_savvly or get_savvly_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?
The description provides explicit usage context: 'Use when the user is evaluating options for longevity risk, retirement income, or comparing Savvly to annuities, target-date funds, or other strategies.' This gives clear guidance, though it doesn't explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_savvly_faqGet Savvly FAQARead-onlyIdempotentInspect
Get answers to frequently asked questions about Savvly. Use when the user has specific questions about how Savvly works, fees, withdrawals, or regulatory status. For richer, audience-specific Q&As (employee / advisor / broker / employer), use search_savvly_content instead.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Filter FAQ by topic | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | Yes | Topic filter applied to produce this result set ('all' if no filter). |
| total | Yes | Count of FAQ entries returned. |
| entries | Yes | Filtered FAQ entries. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds that the tool provides answers to FAQs, which is consistent and slightly extends context without contradicting 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?
Two sentences, each serving a purpose: first defines function, second provides usage guidance and alternative. No 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?
With an output schema present, the description need not explain return values. The single optional parameter is well-defined, and the description covers purpose and when to use, differentiating from siblings.
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 a clear enum description. The description lists example topics (fees, withdrawals) that map to enum values, adding contextual meaning 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 answers to frequently asked questions about Savvly' with specific verb and resource. It distinguishes from sibling tool search_savvly_content by noting that tool offers richer, audience-specific Q&As.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when the user has specific questions about how Savvly works, fees, withdrawals, or regulatory status, and directs to search_savvly_content for alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_savvly_product_infoGet Savvly Product InfoARead-onlyIdempotentInspect
Get complete product information about Savvly, an SEC-registered investment fund offering a Longevity Benefit. Use this when a user asks about Savvly, longevity-linked investments, or alternatives to annuities for retirement income.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Product name (e.g. 'Savvly Longevity Benefit Fund'). |
| tagline | No | Short marketing tagline. |
| category | Yes | Product category slug, e.g. 'longevity_benefit_fund'. |
| description | No | Long-form product description. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that the tool returns 'complete product information' and identifies Savvly as an SEC-registered fund with a Longevity Benefit, providing moderate additional context.
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 only, each earning its place: first defines the tool, second specifies when to use. No wasted words.
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?
Simple retrieval tool with no parameters and an output schema; description adequately states its purpose and typical use cases. Could add more detail about output structure but not necessary given the output schema.
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?
No parameters exist; schema coverage is 100% by default. Baseline score of 4 applies as per guidelines.
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 'Get complete product information about Savvly', specifying the verb and resource. Distinct from sibling tools like check_eligibility or compare, which address narrower queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when a user asks about Savvly, longevity-linked investments, or alternatives to annuities'. Provides clear usage context but does not explicitly list when not to use or 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). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | Yes | Current age | |
| inflation_rate | No | Expected annual inflation rate % | |
| retirement_age | Yes | Planned retirement age | |
| life_expectancy | No | Planning horizon (default 100) | |
| monthly_paycheck | No | Desired monthly retirement paycheck (USD) | |
| monthly_contribution | Yes | Monthly retirement contribution in USD | |
| percentage_in_savvly | No | Percentage of retirement savings allocated to Savvly | |
| pre_retirement_return | No | Expected pre-retirement annual return % | |
| annual_income_increase | No | Annual contribution % increase | |
| post_retirement_return | No | Expected post-retirement annual return % | |
| other_retirement_income | No | Other monthly retirement income (USD) | |
| current_retirement_savings | Yes | Current total retirement savings in USD |
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds a critical mandatory disclosure requirement under SEC and FINRA rules, which is a behavioral constraint not captured in structured fields. This provides essential transparency for the agent.
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 with a clear first paragraph explaining functionality and outputs, and a second paragraph for legal disclosure. It is slightly verbose due to regulatory text, but every sentence serves a purpose and it is front-loaded.
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 complexity (12 parameters, 100% schema coverage, output schema present, annotations provided), the description is complete: it explains the simulation purpose, return fields, and mandatory disclosure. No gaps for an agent to execute 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?
All 12 parameters have descriptions in the input schema (100% coverage), so the description adds no new parameter-level semantics beyond what the schema already provides. Baseline of 3 is appropriate as no additional clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Full retirement simulation' comparing with and without Savvly, lists specific return fields, and distinguishes itself from sibling tools like `project_savvly_lumpsum` and `project_savvly_monthly` by its comprehensive nature.
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?
While not explicitly stating when not to use this tool, it implies its use for a full comparison and mentions return values that support decision-making. The context of sibling tools provides implicit guidance, but explicit exclusion of simpler scenarios (e.g., lumpsum projection) would improve clarity.
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 Savvly's Longevity Benefit Fund. 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 Savvly's Longevity Benefit Fund; 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | Yes | Investor's current age | |
| average_return | Yes | Expected average annual return % | |
| funding_amount | Yes | Lump sum investment in USD | |
| withdrawal_age | No | Optional early-withdrawal age — 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations declaring it read-only and idempotent, the description adds substantial behavioral detail: explains payout methodology, comparison logic, field meanings (_lower/_upper), and mandatory disclosure requirements. 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 quite long and contains detailed methodology and disclosure instructions. While all content is relevant, it could be more concise. It is front-loaded with the purpose but becomes verbose.
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 parameters, output schema), the description covers purpose, field hints, and disclosure. It does not detail output schema fields, but that is provided separately. The description is largely complete for an agent to use 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 basic descriptions. The tool description does not elaborate on individual input parameters beyond their existence. It adds no additional meaning for current_age, funding_amount, etc., so it meets the baseline.
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 retirement projections for a lump-sum investment in Savvly's Longevity Benefit Fund, specifying milestone ages (80, 85, 90, 95) and comparisons with market alone. It distinguishes from siblings like project_savvly_monthly by focusing on lump-sum vs monthly investment.
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 clear usage context (retirement planning, annuity alternative analysis) and guidance on interpreting _upper and _lower fields. However, it does not explicitly state when not to use this tool vs siblings like project_savvly_monthly.
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 Savvly's Longevity Benefit Fund over a number of years. Returns payout amounts at milestone ages 80/85/90/95 with Savvly vs market alone cumulative totals, per-age breakdowns, and server-provided _lower/_upper range bounds. Use _upper as the central illustrative estimate and _lower to communicate downside. Suitable for retirement savings planning, annuity alternative comparison, and longevity benefit illustration. Supports an optional annual contribution increase and an optional early-withdrawal age. Disclaimers + per-field hints under metadata. Payout methodology — Savvly vs market alone: the payout values are calculated by comparing two investors of the same age committing the same principal. Investor 1 invests in the market with Savvly's Longevity Benefit Fund; 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.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | Yes | Investor's current age | |
| average_return | Yes | Expected average annual return % | |
| monthly_amount | Yes | Monthly contribution in USD | |
| withdrawal_age | No | Optional early-withdrawal age — drives `early_withdrawal_value` and `total_payout_at_withdrawal_age_*` in the response | |
| contribution_years | Yes | Number of years contributing | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's behavior beyond annotations: it is a non-mutating projection that calculates comparing two investors, provides range bounds, and requires SEC/FINRA disclosure. There are no contradictions with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false).
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 verbose, with several paragraphs explaining methodology and disclosure requirements. While informative, it could be more concise to improve quick scanning by an AI agent. The structure is logical but front-loading the key purpose and usage would be beneficial.
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 parameters, output schema exists), the description is highly complete. It covers purpose, methodology, interpretation of results (including range bounds), and regulatory disclosure requirements. The presence of an output schema reduces the burden, but the description still provides essential context for correct invocation.
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, baseline is 3. The description adds value by explaining the effect of optional parameters (withdrawal_age, installment_increase_percentage) and their impact on output fields, going beyond bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a retirement projection for monthly contributions to Savvly's Longevity Benefit Fund, differentiating from sibling tools like project_savvly_lumpsum (lump sum) and project_retirement_with_savvly (broader projection) by specifying 'monthly contributions'. It also details the output fields and methodology, 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 explicitly states suitability for 'retirement savings planning, annuity alternative comparison, and longevity benefit illustration' and provides guidance on interpreting '_upper' and '_lower' fields. However, it does not explicitly compare with sibling tools or state when not to use, which would be helpful given the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_savvly_contentSearch Savvly Q&A Content LibraryARead-onlyIdempotentInspect
Search the Savvly Q&A Content Library — 50 audience-tagged questions and answers compiled from Savvly's marketing collateral, organized by stakeholder (employee, advisor, broker, employer, universal) and subsection (e.g. 'Tax & Legacy', 'Retention & Talent Strategy', 'Implementation'). Use this when the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging. Each entry carries the verbatim answer plus any disclaimer footnotes attached to it in the source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Cap on matched entries returned. Default 20, max 50. | |
| query | No | Free-text substring filter applied to questions, answers, and footnotes. Case-insensitive. | |
| audience | No | Restrict to one stakeholder audience. Omit to search across all audiences. | |
| subsection | No | Substring match against subsection labels (e.g. 'Tax', 'Retention', 'Eligibility'). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
| entries | Yes | Matched Q&A entries. |
| matched | Yes | Count of entries matching the supplied filters. |
| filter_applied | Yes | Echo of the filters that produced this result set. |
| total_in_library | Yes | Total Q&A entry count in the library across all audiences. |
| available_subsections | Yes | Subsection labels available within the (optionally) selected audience. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: it searches a compiled library of 50 entries, returns 'verbatim answer plus any disclaimer footnotes.' This complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph of four sentences. It front-loads the action and scope, then provides details and usage guidance. No redundant or ambiguous words; every sentence adds value.
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 has 4 optional parameters, no required ones, rich annotations, and an output schema (implied but not shown), the description fully covers the purpose, content, and usage context. It explains what the library contains and when to invoke this tool, leaving 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%, baseline 3. The description adds meaning by specifying the content structure (audience-tagged, organized by stakeholder/subsection) and how the 'query' parameter works ('free-text substring'). This enriches the schema explanation.
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 a specific verb ('search') and resource ('Savvly Q&A Content Library'), clearly defining the tool's scope. It mentions 50 audience-tagged questions and organization by stakeholder/subsection, which distinguishes it from sibling 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?
Explicitly states when to use: 'when the user asks about Savvly's positioning, value props, audience-specific talking points, or Q&A-style messaging.' While it doesn't list explicit exclusions, the sibling tool names provide context for alternatives. The guidance is clear enough for an agent.
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!