LunaTerminal

Roth conversion plan

roth_conversion_plan

Read-onlyIdempotent

Compare Roth conversion strategies year by year under 2026 federal tax law in today's dollars: no conversions versus filling the 12%, 22%, 24% or 32% bracket each year until RMDs start (or stopAge). Models RMDs, Social Security taxation, the senior deduction, a flat state tax and heirs' tax on the remaining traditional balance, and flags IRMAA years. Returns each strategy's lifetime tax, after-tax wealth and amount converted, the best strategy by after-tax wealth, its year-by-year schedule, and the assumptions. Required: filingStatus, birthYear and traditional balance.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filingStatus": "<filingStatus>",
      "birthYear": "<birthYear>",
      "traditional": "<traditional>"
    },
    "name": "roth_conversion_plan"
  }
}

Input Schema

Name	Required	Description
`roth`	No	Roth balance (default 0).
`endAge`	No	Last plan year age (default 95).
`stopAge`	No	Last conversion age (default the year before RMDs start).
`taxable`	No	Taxable account balance that pays conversion tax (default 0).
`startAge`	No	First plan year age (default the client's age in 2026).
`birthYear`	Yes	Client birth year.
`realReturn`	No	Annual return after inflation in percent (default 0).
`heirTaxRate`	No	Heirs' tax rate on the inherited traditional balance in percent (default 24).
`otherIncome`	No	Wages and pensions per year (default 0).
`traditional`	Yes	Traditional IRA/401(k) balance in dollars.
`filingStatus`	Yes	single or mfj (married filing jointly).
`stateTaxRate`	No	Flat state income tax rate in percent (default 0).
`socialSecurity`	No	Household Social Security benefits.
`spouseBirthYear`	No	Spouse birth year (mfj only; default same as client).
`otherIncomeEndAge`	No	Age when other income stops (default never).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), so the bar is lower; the description still adds substantial context by disclosing the modeling assumptions (RMDs, Social Security taxation, senior deduction, flat state tax, heirs' tax, IRMAA flags) and the fixed 2026-law/today's-dollars basis. It does not mention computational cost or input validation behavior, but for a deterministic calculator this is a rich disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded with the core comparison and then the model scope and return values, with no filler. It is delivered as one very long compound sentence, which is dense but still ordered logically; a short list would have made the return values easier to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter planning tool with a nested object and no output schema, the description supplies the essential missing piece by enumerating what is returned (per-strategy lifetime tax, after-tax wealth, amount converted, best strategy, schedule, assumptions). Minor gaps remain -- currency/units for balances beyond 'dollars' and state-tax handling interactions are left to the schema -- but an agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains all 15 parameters including the stopAge default and the nested Social Security object, which sets the baseline at 3. The description adds only light reinforcement -- the 'until RMDs start (or stopAge)' linkage and a restatement of the three required fields -- without new syntax or interaction details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource -- comparing Roth conversion strategies year by year -- and enumerates exactly what strategies are compared (no conversions vs. filling the 12%, 22%, 24% or 32% bracket until RMDs or stopAge). It also states the outputs (lifetime tax, after-tax wealth, best strategy, schedule, assumptions), so an agent can tell this apart from broader siblings like retirement_plan or social_security_strategies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the scoping language ('year by year under 2026 federal tax law', 'until RMDs start'), which tells an agent this is a what-if projection tool rather than a data lookup. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as retirement_plan for whole-portfolio questions, so the agent must infer boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All LunaTerminal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?