Retirement drawdown, 72(t) SEPP, RMD, Roth conversion, Social Security and state-tax calculators.
Each tool targets a distinct retirement planning calculation or site retrieval action, and the detailed descriptions clearly separate overlapping areas like 72(t) payments versus the bridge strategy, or drawdown duration versus sustainable withdrawal. No two tools appear to answer the same question.
All names are readable snake_case, but they mix styles: some are verb-first (fetch, search, list_pages), some are noun phrases (state_retirement_taxes, sustainable_withdrawal), one is verb-last (rmd_calculate), and one is a full sentence (how_long_will_money_last). The naming is not chaotic, but it lacks a single predictable convention.
15 tools is at the upper edge of the ideal range, and every tool covers a meaningful retirement calculator or site discovery function. The count feels intentional for the broad retirement-planning domain, with no obvious filler or redundant tools.
The set covers major retirement planning needs: drawdown, sustainable withdrawals, Social Security, taxes, RMDs, inherited IRAs, 72(t), Roth conversions, and pension decisions. Minor gaps exist, such as no standalone retirement-age readiness calculator or explicit Roth IRA ordering tool, but agents can generally accomplish the core workflows.
How an early retiree pays for the years between leaving work and 59 1/2, one year at a time, under three strategies: taxable first with a Roth conversion ladder, a 72(t) series on a carved-off IRA, or a blend. Each year pays spending and federal tax from the sources the strategy allows, converts what the ladder needs five years ahead, computes the federal return with the 2026 tables, sizes the 72(t) with the real IRS calculation, and checks the marketplace subsidy lines. Returns all three strategies unless one is chosen.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Current age. Must be under 60. | |
| cash | No | Cash in dollars. Default 0. | |
| cap_aca | No | Cap Roth conversions so marketplace income stays under 400% of the poverty line. Default false. | |
| strategy | No | all (default) compares the three; or ladder, sepp, blend for one. | |
| inflation | No | Spending growth in percent a year. Default 2.5. | |
| other_income | No | Other income in dollars a year: pension, rent, part-time work. Default 0. | |
| roth_balance | No | Roth IRA balance in dollars. Default 0. | |
| filing_status | No | Federal filing status: single, mfj (married filing jointly) or hoh (head of household). Default single. | |
| household_size | No | Household size for the marketplace lines. Default 1. | |
| pretax_balance | No | Pre-tax IRA and 401(k) balance in dollars. Default 0. | |
| annual_spending | Yes | Spending this year in dollars, before tax, all in. | |
| expected_return | No | Annual return in percent. Default 5. | |
| taxable_brokerage | No | Taxable brokerage balance in dollars. Default 0. | |
| cost_basis_percent | No | Share of the taxable account that is cost basis, in percent. Default 50. | |
| sepp_share_percent | No | Blend only: share of spending the 72(t) covers, in percent. Default 50. | |
| roth_contribution_basis | No | Roth contribution basis in dollars, withdrawable any time. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and idempotent behavior. The description adds meaningful behavioral detail: it computes federal tax using 2026 tables, sizes 72(t) payments with the real IRS calculation, checks ACA marketplace subsidy lines, and returns all three strategies unless one is selected. This goes beyond the annotations and helps an agent understand what the tool actually calculates.
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 of dense, purposeful prose. The first sentence defines scope and strategies, the second details the calculation mechanics, and the third states the output behavior. Every sentence contributes, and the structure is front-loaded with the most important purpose information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 16-parameter tool with no output schema, the description gives a strong overview of inputs, calculations, and output selection. It does not detail the exact return shape, but it states that each year's spending, tax, conversions, 72(t) sizes, and ACA subsidy lines are computed, and that all three strategies are returned unless one is chosen. This is sufficient guidance for most calling scenarios, with a small gap around return formatting.
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 documents all 16 parameters with 100% coverage. The description reinforces the meaning of the strategy parameter by explaining that all three strategies are returned unless one is chosen, but it does not add substantial new meaning beyond the schema for the individual parameters. This matches the baseline for high schema coverage.
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: planning how an early retiree funds the gap between leaving work and age 59.5, comparing three named strategies. It is specific about the resource ('bridge to 59 1/2') and distinguishes itself from single-strategy sibling tools like sepp_72t_payment or roth_conversion_cost by covering multi-year, multi-strategy planning.
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 establishes clear context: it is for early retirees planning the gap years before 59.5, with either all three strategies or one chosen strategy. It does not explicitly state when not to use it or name alternatives, but the context is specific enough that an agent can infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A retiree's federal income tax for tax year 2026: the taxable share of Social Security (the Publication 915 worksheet), the standard deduction with the 65-plus additions and the senior deduction phase-out, ordinary brackets, the 0/15/20% stack for long-term gains and qualified dividends, the 3.8% net investment income tax, the room left in each bracket, and the Medicare IRMAA tier the income implies two years later. Federal only.
| Name | Required | Description | Default |
|---|---|---|---|
| ages | No | Age of each filer at year end, one or two entries. Drives the 65-plus additions and the senior deduction. | |
| capital_gains | No | Long-term capital gains and qualified dividends in dollars. Default 0. | |
| filing_status | No | Federal filing status: single, mfj (married filing jointly) or hoh (head of household). Default single. | |
| ordinary_income | No | Ordinary income in dollars: wages, pension, IRA and 401(k) withdrawals, interest, short-term gains. Default 0. | |
| social_security | No | Gross Social Security benefits for the year in dollars, both spouses. Default 0. | |
| tax_exempt_interest | No | Tax-exempt interest in dollars. Counts toward how much Social Security is taxed and toward Medicare and marketplace income. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent, non-destructive annotations, the description discloses precisely what the calculation includes: the Publication 915 Social Security worksheet, 65-plus standard deduction additions and phase-out, ordinary brackets, the 0/15/20% capital gains stack, the 3.8% NIIT, bracket room, and the IRMAA tier two years later. This gives an agent an unusually complete picture of the tool's behavior.
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 dense sentence that conveys a large amount of output detail without fluff, and the final 'Federal only' is a useful scope marker. A colon-list structure keeps it readable, though an explicit leading verb such as 'Calculates' would make it even more immediate.
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 no output schema, the description is the sole signal for what the tool returns, and it does enumerate the major output blocks: taxable Social Security, deduction, ordinary brackets, capital gains stack, NIIT, bracket room, and IRMAA. It could add caveats about assumptions or default behavior with zero inputs, but it is largely complete for a federal tax estimate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds contextual connections such as the 65-plus additions relating to ages and the 0/15/20% stack relating to capital gains, but it does not add meaning beyond what the parameter descriptions already provide.
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 identifies the resource — a retiree's federal income tax for tax year 2026 — and enumerates the exact computed components, making the tool's purpose unmistakable. It stops short of using a literal verb like 'calculates' or 'estimates', and differentiation from siblings rests mostly on the 'Federal only' tag.
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 clearly scopes the tool to federal income tax for retirees, and the closing 'Federal only' tells an agent it is not for state tax questions, which siblings like state_retirement_taxes would cover. It does not explicitly name sibling tools or provide richer when-to-use versus when-not-to-use guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full text of one savingslast.com page as markdown, by id from search, by slug, or by URL. Every calculator page carries its explanation, worked figures and FAQ; guides carry the article.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Page id from search, a slug like 72t-distribution-calculator, or a savingslast.com URL. |
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 safety profile is fully covered. The description adds useful context about the markdown output and the expected content of calculator pages versus guides, but it does not disclose failure modes, rate limits, or other behavioral traits. This is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core behavior and accepted identifiers; the second economically explains what different page types contain. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with full schema coverage and complete annotations, the description is sufficient. It covers what is returned (markdown), how to identify the page (id, slug, URL), and what content to expect on each page type. No additional context is necessary 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?
Schema description coverage is 100% and the property description already explains that id can be a page id, slug, or URL. The tool description essentially repeats this information without adding syntax details, normalization rules, or edge cases, so it provides no value 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 states a specific verb ('fetch'), a specific resource ('one savingslast.com page'), and the output format ('full text ... as markdown'). It distinguishes itself from sibling list/search tools by specifying it retrieves full page content rather than metadata or search results.
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 clearly indicates this tool is for retrieving one page's complete content, and provides the accepted input forms: 'by id from search, by slug, or by URL.' The phrase 'by id from search' implies a search-first workflow, giving context even though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Month-by-month drawdown of a retirement balance: how many years the money lasts at a monthly withdrawal that rises with inflation, the age it runs out, the odds of being alive then, and the most that could be withdrawn to last 20, 25 or 30 years. Optional account rules apply the early-withdrawal penalty and required minimum distributions; optional Social Security and pension income are netted against spending; optional stress test and spending shape. The same engine as savingslast.com, and the result carries a link to the page with these inputs filled in.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Current age. Optional; enables the run-out age, the survival odds, the account rules (penalty before 59 1/2, RMDs from 73) and the Social Security start age. | |
| account | No | Apply an account type's withdrawal rules: the 10% early-withdrawal penalty before 59 1/2 for a 401(k), 403(b), TSP, IRA, SEP or SIMPLE IRA; none for a governmental 457(b) or under the rule of 55; tax-free withdrawals for a Roth IRA; the 20% non-medical penalty before 65 for an HSA; required minimum distributions from 73 where they apply. Default none. | |
| balance | Yes | Starting balance in dollars. | |
| tax_rate | No | Tax on withdrawals in percent, 0 to 50. Withdrawals are grossed up so the after-tax amount matches. Default 0. Ignored for Roth and HSA accounts. | |
| inflation | No | Annual inflation in percent, -5 to 15. Default 2.5. The withdrawal rises at this rate so spending power stays level. | |
| stress_test | No | Apply a bad start: -20%, -10% and 0% returns in the first three years, then the average. Default false. | |
| annual_return | No | Expected annual return in percent, -10 to 20. Default 5. | |
| spending_shape | No | inflation: spending rises with inflation (default). level: fixed dollars. decline: rises with inflation until 75, then one point a year slower. | |
| pension_monthly | No | Pension or annuity in dollars a month, netted against spending. Default 0. | |
| monthly_withdrawal | Yes | Amount taken out each month today, in dollars, after tax. Enter what savings must cover, or enter total spending and give the Social Security and pension separately. | |
| social_security_monthly | No | Social Security benefit in dollars a month, netted against spending. Rises with inflation. Default 0. | |
| social_security_from_age | No | Age the Social Security benefit starts. Needs age. Default: from now. | |
| pension_rises_with_inflation | No | Whether the pension has a cost-of-living increase. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent; the description adds that it runs a month-by-month projection, applies optional account rules, and returns a link to a savingslast.com page with the same inputs. It also discloses that income is netted against spending and that a stress test changes return assumptions, which an agent would not learn from annotations or the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the core result and then layer optional behaviors and the external link. No sentence is filler; the description stays compact despite a 13-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex calculator with no output schema, the description enumerates the key return values and groups the optional parameter families coherently, while the schema supplies per-parameter details. It does not state the underlying mortality/return assumptions or the exact format of the results, but what an agent needs to select and invoke the tool is present.
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 structured descriptions already carry most parameter meaning. The description adds value by grouping optional parameters into behaviors—account rules (early-withdrawal penalty, RMDs), Social Security/pension netting, stress test, and spending shape—making the optional fields' joint purpose easier to grasp.
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 names a concrete calculation ('Month-by-month drawdown of a retirement balance') and enumerates distinctive outputs: years until exhausted, run-out age, survival odds, and sustainable withdrawal ceilings for 20/25/30 years. This makes the tool's role clear even though it does not explicitly contrast it with sibling tools like sustainable_withdrawal.
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 conveys when to use it—for retirement drawdown projections with optional account rules, Social Security/pension offsets, stress tests, and spending shapes—and these feature cues imply use cases. However, it never names an alternative tool or states when not to use this one, so differentiation from siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A withdrawal schedule for a non-spouse heir under the 10-year rule: the level annual withdrawal that empties the account exactly at the deadline, year-by-year balances and tax at a flat rate, and, when the owner had already started required distributions, the annual minimums for years one to nine under the 2024 final regulations (Single Life Table factor reduced by one each year).
| Name | Required | Description | Default |
|---|---|---|---|
| balance | Yes | Inherited account balance in dollars. | |
| tax_rate | No | Flat marginal tax rate on withdrawals in percent. Default 0. | |
| your_age | No | Heir's age in the year after the owner's death. Default 50. | |
| expected_return | No | Annual return in percent. Default 5. | |
| years_remaining | No | Years left before the account must be empty, 1 to 10. Default 10. | |
| owner_had_started_rmds | No | True if the owner died on or after their required beginning date, which makes annual minimums apply in years one to nine. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral detail: the account is emptied exactly at the deadline, balances and tax are computed at a flat rate, and year-one-to-nine minimums follow the 2024 final regulations with the Single Life Table factor reduced by one each year. It does not describe output formatting or edge cases, but the annotation coverage lowers the bar.
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 dense sentence that front-loads the purpose and lists the outputs efficiently. The embedded regulatory clause about the Single Life Table adds specificity but makes the sentence somewhat long; overall it is appropriately sized and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial tool with no output schema, the description covers the essential outputs and the key regulatory branch. It does not spell out output structure, rounding, or edge cases, but combined with the rich input schema and read-only annotations it is largely complete 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?
Schema coverage is 100% and each parameter already has a descriptive comment, so the baseline is 3. The description reinforces the role of years_remaining and owner_had_started_rmds through the 10-year rule and minimum-distribution branch, but it does not add significant 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 states a specific resource and scope: 'a withdrawal schedule for a non-spouse heir under the 10-year rule,' then enumerates concrete outputs such as level annual withdrawals, year-by-year balances, tax, and annual minimums. This clearly differentiates it from sibling tools like rmd_calculate or sustainable_withdrawal by subject matter.
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 use condition is explicit: non-spouse heir under the 10-year rule, with a clearly described branch for when the owner had already started required distributions. It does not name alternative tools or explicitly state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every page on savingslast.com with its URL, title, description and section, optionally one section only. Sections: Calculators; How long will a balance last; Reference; Retirement taxes by state; Social Security; Can I retire at an age; Guides.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional section name to filter by, or a type: calculator, guide, reference. |
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 safety profile is covered. The description adds useful output-shape context ('URL, title, description and section') and the section vocabulary, but does not disclose additional behaviors such as pagination limits or formatting rules.
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 with every sentence earning its place: the first maps the tool's output and optional filter; the second provides the closed list of valid sections. The main behavior is front-loaded before the enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only list tool, this is complete: it names the site, the returned fields, the filter semantics, and all section values. No output schema exists, but the description explicitly states what fields each page result will contain.
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 schema already documents the optional section parameter and mentions the type keywords, so it carries most of the semantic load. The description adds value by enumerating the exact section names (Calculators, 'How long will a balance last', Reference, etc.), which an agent would otherwise have to guess.
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 resource ('every page on savingslast.com') and the returned fields (URL, title, description, section), so an agent can tell this is a catalog/listing tool rather than a calculator or fetch tool. It lacks an explicit verb ('list' appears only in the title), and it doesn't name sibling tools, so it stops just short of full differentiation.
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 clearly conveys the optional section filter and enumerates valid sections, so an agent knows when to pass a section versus not. However, it gives no explicit guidance about when to choose this tool over siblings like search or fetch, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares a pension's lump-sum offer with its monthly annuity: the payout rate the pension implies, the age the invested lump sum runs out paying the same amount, the steady return the lump sum must earn to match the pension to a planning age, and the odds of being alive at each point on the IRS unisex mortality table, with a verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Age when payments would start. | |
| cola | No | Pension cost-of-living increase in percent a year. Default 0. | |
| lump_sum | Yes | The lump-sum offer in dollars. | |
| planning_age | No | Age to plan to. Default 90. | |
| expected_return | No | Return the lump sum would earn, in percent. Default 5. | |
| monthly_pension | Yes | The monthly pension it replaces, in dollars. For a joint-and-survivor option enter that lower figure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond those annotations, notably that it uses the IRS unisex mortality table, evaluates how long the lump sum lasts, computes the required return, and produces a verdict. It does not describe the exact output format, but the key assumptions are disclosed.
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 sentence that front-loads the core comparison and then lists the computed metrics. Each clause adds a distinct output with no filler, though the sentence is dense and somewhat long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial planning tool with no output schema, the description enumerates the major outputs and key assumptions, which is sufficient for an agent to understand what the tool will compute. It does not specify return types or units, but the schema covers parameter details and the selection purpose is fully clear.
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 each parameter already has a clear description and defaults. The tool description does not repeat those details, but it does connect the output concepts to parameters like planning age, expected return, and monthly pension. This meets the baseline for full schema coverage.
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 concrete verb, 'Compares', names the exact objects (the pension's lump-sum offer vs. its monthly annuity), and enumerates the specific outputs: payout rate, exhaustion age, required return, survival odds, and a verdict. This makes the tool's purpose unmistakable and distinguishes it from siblings such as how_long_will_money_last even without naming them.
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 clearly conveys the intended scenario: evaluating whether to take a pension lump sum versus an annuity, with planning-age and return assumptions. It does not explicitly state when not to use this tool or name alternative tools, so it lacks exclusion guidance, but the use context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The required minimum distribution for a year from a traditional IRA, 401(k) or similar account: the prior 31 December balance divided by the IRS Uniform Lifetime Table factor at the age reached that year, with the required beginning age from the birth year (72, 73 or 75 under SECURE 2.0), the due date, and a ten-year projection at an assumed return.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | Yes | Account balance on 31 December of the year before the distribution year, in dollars. | |
| birth_year | Yes | Owner's year of birth. | |
| expected_return | No | Annual return in percent for the projection only. Default 5. | |
| distribution_year | No | The year the distribution is for. Default: the current year. | |
| spouse_sole_beneficiary_more_than_10_years_younger | No | If true, the Joint and Last Survivor Table applies and the true RMD is smaller than the figure returned; noted in the result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds valuable behavioral detail beyond the annotations, including the calculation method, required beginning age rules under SECURE 2.0, the due date, and the ten-year projection at an assumed return.
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 dense sentence with no filler. It front-loads the core computation and then adds the key supporting details, all of which are relevant to invoking the tool correctly.
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 five parameters, no output schema, and a tax/retirement domain, the description covers the main inputs and outputs well: balance, birth year, projection, and due date. Optional parameter behavior is left to the schema, which fully describes those fields, so the overall context is sufficient.
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 semantic context tying balance and birth_year to the formula, and mentions the projection concept, but it does not add detailed per-parameter guidance beyond what the schema already provides.
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 defines the tool's purpose: calculating the required minimum distribution from a traditional IRA, 401(k), or similar account. It gives the exact formula, references the IRS Uniform Lifetime Table, and lists additional outputs like due date and ten-year projection, making it distinct from sibling tools such as inherited_ira_schedule or sepp_72t.
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 for when the tool applies: RMD calculations for traditional retirement accounts, not other withdrawal strategies. It does not explicitly name sibling tools or state when not to use them, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What converting an amount from a traditional IRA or 401(k) to a Roth costs in federal tax for 2026, on top of everything else that year, including the extra Social Security it makes taxable and the senior deduction it phases out. Also: how much fits under each bracket ceiling from today's position, the Medicare IRMAA tier with and without the conversion, the ACA marketplace subsidy cliff for the household, and what the conversion does to the first required minimum distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| ages | No | Age of each filer at year end, one or two entries. Drives the 65-plus additions and the senior deduction. | |
| capital_gains | No | Long-term capital gains and qualified dividends in dollars. Default 0. | |
| filing_status | No | Federal filing status: single, mfj (married filing jointly) or hoh (head of household). Default single. | |
| household_size | No | Household size for the marketplace poverty-line figures. Default 1. | |
| pretax_balance | No | Optional: total pre-tax balance today in dollars, for the RMD projection. | |
| aca_marketplace | No | True if health insurance is bought on the ACA marketplace (the 400% of poverty subsidy cliff matters). Default false. | |
| expected_return | No | Annual return in percent for the RMD projection. Default 5. | |
| ordinary_income | No | Ordinary income in dollars: wages, pension, IRA and 401(k) withdrawals, interest, short-term gains. Default 0. | |
| social_security | No | Gross Social Security benefits for the year in dollars, both spouses. Default 0. | |
| conversion_amount | Yes | Amount to convert in dollars. | |
| tax_exempt_interest | No | Tax-exempt interest in dollars. Counts toward how much Social Security is taxed and toward Medicare and marketplace income. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, so the description carries a low bar here and still adds substantial value. It discloses complex behavioral interactions: extra taxable Social Security, phased-out senior deduction, bracket ceilings from today's position, IRMAA with and without conversion, ACA subsidy cliff, and effect on the first RMD. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: the core question comes first, followed by a scoped list of additional outputs. It is one long sentence rather than bullets, but every clause contributes information and there is 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?
For a complex 11-parameter tool with no output schema, it enumerates the main return dimensions: cost, bracket fit, IRMAA, ACA cliff, and first RMD. It does not spell out the exact output shape or state tax-law assumptions beyond '2026,' but the schema covers parameter-level details adequately.
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, but the description adds real meaning beyond the schema. The phrase 'on top of everything else that year' tells callers to pass baseline income separately, and listed outputs tie social_security, ages, aca_marketplace, household_size, pretax_balance, and expected_return to why they matter.
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 names a specific calculation — the federal tax cost of a Roth conversion from a traditional IRA/401(k) in 2026 — and enumerates distinct outputs such as bracket headroom, IRMAA tier, ACA cliff, and first RMD impact. This clearly differentiates it from siblings like federal_tax_estimate and rmd_calculate.
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 context is clear: use this when you need the marginal 2026 federal cost of a conversion on top of an existing year, including Social Security, senior deduction, IRMAA, ACA, and RMD effects. It does not explicitly name alternatives or say when to prefer federal_tax_estimate or rmd_calculate, 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.
Full-text search across every page on savingslast.com: the calculators, the guides, the Social Security pages, the state retirement-tax pages and the reference pages. Returns ids to pass to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results, 1 to 25. Default 10. | |
| query | Yes | What to look for, in plain words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral value by disclosing that the tool returns ids rather than full page content, which is critical for invoking it correctly alongside fetch.
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 concise sentences with no filler. The core purpose is front-loaded, the scope is clarified with useful examples, and the return-value purpose is stated in the second sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one required parameter and full schema coverage, the description is largely complete. It explains the scope and what the return value should be used for. It does not detail result ordering or no-result behavior, but given the annotations and schema, this is a minor gap.
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 both query and limit are already documented. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: full-text search across every page on savingslast.com, and specifies the scope by naming the content categories. It also explains the output purpose ('Returns ids to pass to fetch'), distinguishing it from siblings like fetch and list_pages.
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 makes the use case clear: use this tool to find content by keyword across the site, then pass returned ids to fetch. It gives clear context and a natural workflow, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The date a 72(t) series may be changed without the recapture penalty: the later of five years from the first payment and the owner reaching 59 1/2, computed in calendar months the way the IRS does (six months after the 59th birthday, not 0.5 years).
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | Owner's birth date, YYYY-MM-DD. | |
| first_payment_date | Yes | Date of the first distribution, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful computational nuance beyond that: the rule is the later of five years from first payment and reaching 59 1/2, with calendar-month conventions explicitly noted (six months after the 59th birthday, not 0.5 years). This informs the agent of a non-obvious IRS calculation detail.
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?
A single, information-dense sentence that front-loads the purpose before stating the calculation rule. Every element contributes to understanding the computation, with 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?
For a two-parameter, read-only calculation tool with no output schema, the description is largely complete. It explains the inputs and the rule, and the title plus description make the return value (a date) clear. It could explicitly state the output format, but the inference is strong and no nested structures or edge cases are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described. The description adds value by showing how each parameter is used in the calculation: birth_date determines the 59 1/2 threshold and first_payment_date starts the five-year period, mapping the parameters into the rule.
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 specific computation result: the date a 72(t) series may be changed without recapture penalty. It includes the precise IRS rule, distinguishing it from related tools like sepp_72t_payment or bridge_to_59_half by focusing on the modification lock-in date.
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 for when the tool is relevant: determining the lock-in end date for a 72(t) series. It does not explicitly name alternatives or state when not to use it, but the definition is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The annual 72(t) substantially equal periodic payment under all three IRS methods in Notice 2022-6: fixed amortization, fixed annuitization and required minimum distribution, using the 2022 life-expectancy and mortality tables. Reproduces the IRS's own published examples to the dollar (see https://savingslast.com/72t-calculator-test-cases/). Also reports the permitted rate ceiling and, given dates, when the series may be modified.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Owner's age on their birthday in the year of the first payment. | |
| table | No | Life expectancy table: single (Single Life, the largest payment), uniform (Uniform Lifetime) or joint (Joint and Last Survivor, needs beneficiary_age). Default single. | |
| method | No | Which of the three Notice 2022-6 methods to headline. All three are returned. Default amortization. | |
| balance | Yes | Account balance in dollars on the statement date used for the series. | |
| birth_date | No | Optional, YYYY-MM-DD. With first_payment_date, gives the date the series may be modified without penalty. | |
| joint_factor | No | Optional: the Joint and Last Survivor Table entry for the two ages, from 26 CFR 1.401(a)(9)-9(d), if you have it. | |
| interest_rate | No | Interest rate in percent for the fixed amortization and annuitization methods. 5% is always permitted; a higher rate needs federal_midterm_120. Default 5. | |
| beneficiary_age | No | Designated beneficiary's age on their birthday in the distribution year. Required for the joint table. | |
| first_payment_date | No | Optional, YYYY-MM-DD. Date of the first distribution in the series. | |
| federal_midterm_120 | No | Optional: 120% of the federal mid-term rate, in percent, for one of the two months before the first payment. Raises the permitted rate ceiling above 5%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description is fully consistent with them (no contradiction). It adds genuine context beyond annotations: results reproduce IRS published examples to the dollar, the tool returns payments under all three methods, and it surfaces the permitted rate ceiling and the modification date — behaviors not visible in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core computation, then an accuracy/verifiability claim, then a compact list of additional outputs. The URL is a short parenthetical that earns its place as a correctness reference. No wasted words for a tool with this much domain complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter financial computation with no output schema, the description covers the essential ground: what is computed, the governing IRS authority, the accuracy guarantee, and the full set of reported outputs. The main gap is the total absence of any description of the return shape, which matters more here because there is no output schema to fall back on.
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 3 applies. The description does not add parameter-level meaning beyond the schema; it reinforces that all three methods are returned and provides a verification link, but those are behavioral claims rather than parameter semantics. The schema itself already carries the parameter documentation burden.
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 a specific computation — the annual 72(t) SEPP payment under all three Notice 2022-6 methods — and names the governing IRS authority and the 2022 mortality tables. It is clearly distinguishable from overlapping siblings like rmd_calculate (single-method RMD) and sepp_72t_lock_in_end (modification timing) because the three-method payment computation is the headline.
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 usage context is implied clearly for anyone needing a 72(t) payment figure, but the description never names an alternative or exclusion. This is a real gap because the sibling set includes rmd_calculate and sepp_72t_lock_in_end, and the description's own claim that it 'reports when the series may be modified' overlaps with that sibling without telling an agent which tool to prefer for that question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a US state taxes retirement income: Social Security, pensions, and IRA and 401(k) withdrawals, plus the estate or inheritance tax, sales and property tax levels, and an estimated effective state income tax on $40,000 of withdrawals for a 65-year-old single filer. All 50 states and DC. Give a state name or abbreviation, or nothing for every state.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State name or two-letter abbreviation. Omit for all states. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about the included tax categories and the specific assumption of a 65-year-old single filer on $40,000 of withdrawals, but it does not disclose the output format or behavior for invalid input. This is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense: two sentences cover content, scope, the estimation scenario, and input instructions. Every clause earns its place, and the main subject 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?
For a read-only informational tool with one optional parameter and no output schema, the description is complete. It tells an agent what tax topics are covered, the specific estimate scenario, the geographic scope, and how to request one state or all states. No required information for correct invocation is missing.
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%; the single optional 'state' parameter is already documented as a state name or abbreviation, and the description repeats this guidance without adding meaning beyond the schema. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: explaining how a US state taxes retirement income, with specific coverage of Social Security, pensions, IRA/401(k) withdrawals, estate/inheritance tax, sales and property tax, and an effective income tax estimate. It also states the scope (all 50 states and DC), which distinguishes it from sibling tools like federal_tax_estimate.
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 input guidance: provide a state name or abbreviation, or omit it for every state. It does not explicitly name alternatives or provide when-not-to-use conditions, but the context of state-specific retirement taxation is clear enough for an agent to know when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The largest starting monthly withdrawal, rising with inflation, that a balance can support for a chosen number of years at a given return, inflation and tax rate. Solved by bisection on the same drawdown engine.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Current age. Optional; enables the run-out age, the survival odds, the account rules (penalty before 59 1/2, RMDs from 73) and the Social Security start age. | |
| years | No | How long the money must last, in years. Default 30. | |
| account | No | Apply an account type's withdrawal rules: the 10% early-withdrawal penalty before 59 1/2 for a 401(k), 403(b), TSP, IRA, SEP or SIMPLE IRA; none for a governmental 457(b) or under the rule of 55; tax-free withdrawals for a Roth IRA; the 20% non-medical penalty before 65 for an HSA; required minimum distributions from 73 where they apply. Default none. | |
| balance | Yes | Starting balance in dollars. | |
| tax_rate | No | Tax on withdrawals in percent, 0 to 50. Withdrawals are grossed up so the after-tax amount matches. Default 0. Ignored for Roth and HSA accounts. | |
| inflation | No | Annual inflation in percent, -5 to 15. Default 2.5. The withdrawal rises at this rate so spending power stays level. | |
| stress_test | No | Apply a bad start: -20%, -10% and 0% returns in the first three years, then the average. Default false. | |
| annual_return | No | Expected annual return in percent, -10 to 20. Default 5. | |
| spending_shape | No | inflation: spending rises with inflation (default). level: fixed dollars. decline: rises with inflation until 75, then one point a year slower. | |
| pension_monthly | No | Pension or annuity in dollars a month, netted against spending. Default 0. | |
| social_security_monthly | No | Social Security benefit in dollars a month, netted against spending. Rises with inflation. Default 0. | |
| social_security_from_age | No | Age the Social Security benefit starts. Needs age. Default: from now. | |
| pension_rises_with_inflation | No | Whether the pension has a cost-of-living increase. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds a useful computational detail by mentioning bisection on the same drawdown engine, and it clarifies that withdrawals rise with inflation, but it does not describe the output format or numerical behavior beyond that.
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 short, front-loaded with the core purpose, and does not repeat the schema. The second sentence about bisection is somewhat extra but earns its place by giving a computational transparency cue without adding bulk.
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 13 parameters and the very detailed schema, the description clearly communicates the primary result: the largest starting monthly withdrawal. It does not describe the output format or explicitly mention how age, account type, pension, or Social Security feed the calculation, but the schema covers those inputs and the core return value is stated.
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 schema already documents all 13 parameters in detail. The tool description adds only a high-level relationship among years, return, inflation, and tax rate, which does not materially improve on the schema's parameter explanations.
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 a clear objective: compute the largest starting monthly withdrawal a balance can support for a chosen number of years given return, inflation, and tax assumptions. It is specific about the resource and calculation, but it does not explicitly differentiate itself from the sibling tool how_long_will_money_last, which answers the inverse question.
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 intended use is implied: use this when you want the maximum sustainable monthly withdrawal for a fixed time horizon. However, the description gives no explicit guidance about when to prefer this over alternatives such as how_long_will_money_last, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
bridge_to_59_halffederal_tax_estimatefetchhow_long_will_money_lastinherited_ira_schedulelist_pagespension_lump_sum_vs_annuityrmd_calculateroth_conversion_costsearchsepp_72t_lock_in_endsepp_72t_paymentsocial_security_claimingstate_retirement_taxessustainable_withdrawalClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Deterministic US financial planning: retirement Monte Carlo, Roth conversion, RMD, tax, IRMAA, SS
Retirement planning for Canada & US. CPP/OAS, Social Security, RRSP/TFSA, 401k/IRA, Monte Carlo.
FIRE & retirement calculators + a multi-currency portfolio rebalancer (exact buy/sell trades).
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
social_security_claimingSocial Security claiming agesARead-onlyIdempotent Inspect
What claiming Social Security at each age pays, from 62 to 70, using the statutory reduction (5/9 of 1% a month for the first 36 months early, then 5/12 of 1%) and delayed retirement credits (2/3 of 1% a month to 70); the cumulative benefit by age with an optional COLA; the break-even ages between claiming ages; and optionally the case where early payments are invested at a return.
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond annotations, including the statutory reduction formula, delayed retirement credits, optional COLA, break-even calculations, and an optional investment-return scenario. It does not disclose edge-case assumptions, but the provided disclosure is solid.
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 the core purpose and packs a lot of useful detail into one dense sentence. It could be more scannable with bullet points, but every clause earns its place and there is no filler or repetition.
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 absence of an output schema, the description does a good job enumerating what the tool returns: age-specific payments, cumulative benefits, break-even ages, and optional invested-early-payments results. It does not specify exact output formatting or limitations, but the scope and key outputs are clear enough for an agent to invoke the tool appropriately.
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% parameter description coverage, so the baseline is appropriately 3. The tool description adds formula context and mentions optional COLA and investment return, but it does not add substantial semantics beyond the schema descriptions for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Social Security claiming ages 62-70) and the core information delivered: monthly payments, cumulative benefits, and break-even ages. It lacks an explicit action verb like 'calculate' or 'compare,' but the noun-phrase structure is unambiguous and it is distinct from sibling retirement tools.
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 intended use is implied by the content: an agent would invoke this when asked about claiming Social Security at different ages, cumulative benefits, or break-even analysis. However, it never explicitly states when to use this tool versus alternatives or what should not be done with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.