Roth vs Traditional Optimizer

by com.kindoflost.roth-vs-traditional-calculator

Optimize Roth vs traditional contributions

optimize_retirement_contributions

Read-onlyIdempotent

Find the best yearly split of retirement savings between traditional and Roth 401(k), IRA/backdoor Roth, HSA and brokerage, including employer match, Roth conversions and retirement withdrawals. Returns this year's dollars per account, how the optimal mix compares with always-traditional and always-Roth, Roth share, lifetime totals, the first working years and retirement milestones. Runs in a few seconds (a few more with exact_income_limits). All money in today's dollars. Optimal for the stated assumptions; not tax advice. Call get_contribution_example first if unsure of the shape.

Input Schema

Name	Required	Description
`age`	Yes	Your age this year. The plan starts now.
`filing`	No	Tax filing status. Default 'single'. 'married' = one joint return; fill in the spouse_* fields.
`salary`	Yes	Your gross pay this year, in dollars.
`end_age`	No	Plan until this age (default 92; horizon at most 90 years).
`accounts`	No	Which accounts the user can use. Defaults: 401(k) and Roth 401(k) available, IRA allowed, no HSA, no match.
`balances`	No	Current household balances, dollars. Omitted = 0.
`retire_age`	Yes	Age you stop working. Must be above 'age'.
`assumptions`	No	Modeling assumptions; the defaults are reported back.
`spouse_salary`	No	Married only: spouse's gross pay this year (0 or omitted = spouse does not work).
`real_raise_pct`	No	Yearly raise above inflation, whole percent (1 = 1%). Default 1.
`social_security`	No	Expected Social Security (household). Omitted = none modeled.
`spouse_retire_age`	No	Married only: the age YOU will be when your spouse stops working (all ages on this server are the primary earner's). Default = retire_age.
`children_birth_years`	No	Birth years of dependent children (child tax credit, head of household).
`spending_in_retirement`	Yes	Yearly spending after retiring, today's dollars (before income tax).
`spending_while_working`	No	Yearly living costs while still working, today's dollars. Default = spending_in_retirement.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish this as a safe, read-only, idempotent computation. The description adds useful behavioral context beyond annotations: runtime expectations, today's-dollar convention, the scope of optimization, and a clear caveat that results are optimal only for stated assumptions and are not tax advice.

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

Conciseness5/5

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

The description is dense, front-loaded, and free of filler. Every sentence adds a distinct piece of value: optimization scope, return contents, runtime, dollar convention, caveat, and helper-tool pointer.

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

Completeness5/5

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

For a complex 15-parameter financial optimizer with no output schema, the description is complete enough. It explains what is optimized, summarizes the returned outputs, sets runtime expectations, states the dollar convention, and points to an example tool for input shape.

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 all 15 parameters are already well documented in the schema. The description does not add parameter-specific syntax or semantics beyond what the schema provides, which is acceptable at baseline 3 when the schema carries that burden.

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 states a specific optimization verb and resource: finding the best yearly split of retirement savings across traditional/Roth 401(k), IRA/backdoor Roth, HSA, and brokerage. It clearly distinguishes the actual optimization tool from the sibling helper get_contribution_example by describing the detailed result it returns.

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

Usage Guidelines4/5

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

It explicitly routes uncertain users to get_contribution_example for input shape and gives practical runtime context. It does not mention when not to use the tool or clarify the role of the other sibling, check_request.

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

All Roth vs Traditional Optimizer 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?