An MCP server that gives AI agents current U.S. financial-planning figures with their primary-source citations, plus small synthetic household samples and a benchmark for AI financial-advice systems.
Ask an agent "What's the 2026 401(k) limit?" and it answers from the IRS source, with the document and section, instead of from a model's memory, which is often last year's number.
Tool | What it returns |
| One cited planning figure (e.g. |
| Every figure in the 2026 federal feed, by domain, marking which are in the free sample |
| A small synthetic household sample (banded amounts, 12-month history) |
| The household archetypes and record schema |
| Data products and where to buy them |
| 50 benchmark tasks for AI financial-advice systems, with answer keys |
Figures cover IRS, SSA, CMS and HHS: contribution limits, tax brackets, standard deduction, RMD tables, IRMAA tiers, Social Security COLA and wage base, HSA limits, estate and gift figures, and more. 2027 figures are added as the agencies publish them (tracker).
Related MCP server: Offramp MCP Server
Without a key you get a free sample of 10 headline figures. A paid Rule Sets plan (from $49/month) returns every federal and state figure. Set your key as WEALTHSCHEMA_API_KEY.
Clients that support remote MCP servers can connect directly:
{ "mcpServers": { "wealthschema": { "url": "https://www.wealthschema.com/api/mcp" } } }With a paid key, send Authorization: Bearer <key>.
For clients that only run local servers (Claude Desktop, Cursor, Windsurf, Cline and others):
{
"mcpServers": {
"wealthschema": {
"command": "npx",
"args": ["-y", "github:CapsteraSupport/wealthschema-mcp"],
"env": { "WEALTHSCHEMA_API_KEY": "optional-paid-key" }
}
}
}The local server relays to the hosted one, so tools and answers are always current. Requires Node.js 18+.
npm install
npm test # starts the server over stdio, lists tools, calls a free and a paid figureInformational only; not tax, legal or financial advice. Every figure links to its primary source so you can check it.
All household data is synthetic: no real people or accounts.
Also in the official MCP Registry as com.wealthschema/mcp.
Questions: support@wealthschema.com · wealthschema.com/for-agents
Code in this repository is MIT-licensed. Data returned by the server is licensed under the WealthSchema terms.
Describe the top-level fields of a synthetic household record.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Describe' suggests a read-only, non-destructive operationaine; the phrase 'top-level fields' bounds the scope of what is reported. Still, it does not disclose the return shape, whether nested structure is omitted, or any other behavioral detail beyond the core act of describing.
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, front-loaded sentence with no filler or redundant clauses. Every word contributes to identifying what the tool does, which is ideal for a parameterless introspection 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?
Given the tool's trivial input surface, the description is nearly complete: it says exactly what the tool exposes (top-level fields) and the domain (synthetic household). It could mention the output format explicitly, but 'describe... fields' already conveys the essential contract.
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 tool has zero parameters)Skip an empty input schema, so there is no parameter documentation burden on the description. The description correctly adds nothing about parameters because none exist.
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 names the verb 'Describe' and the specific resource: 'top-level fields of a synthetic household record.' It distinguishes the tool from the get/list siblings by framing it as a schema-introspection operation, though it does not explicitly compare itself to any sibling.
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 tool when you need to know the top-level fields of a synthetic household. However, there is no explicit guidance about when to prefer it over alternatives like get_sample_household, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Planning Benchmark v2 - 50 free evaluation tasks for AI financial-advice systems with answer keys by construction: required figures cited to primary source documents, wrong-but-plausible stale values enumerated with reason codes (the Stale Figure Rate metric). Pass blind=true to omit the answer keys for blind evaluation. Scoreboard + protocol: https://www.wealthschema.com/benchmark ; commercial eval packs: https://www.wealthschema.com/ai-eval-sets
| Name | Required | Description | Default |
|---|---|---|---|
| blind | No | Omit answer keys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the benchmark's design (answer keys by construction, stale figure enumeration, Stale Figure Rate metric) and the blind option's effect. However, it does not describe the return format, any side effects, authentication needs, or rate limits. For a read-only getter, this is adequate but not comprehensive.
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 information-dense and front-loaded with the purpose, followed by a usage note and external links. However, the trailing URLs ('Scoreboard + protocol', 'commercial eval packs') are not necessary for invoking the tool and could be considered extraneous. It is structured but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity (one optional boolean, no output schema, no annotations). The description explains what the benchmark contains and the blind option, but does not specify the output structure or what exactly the tool returns (e.g., JSON array of tasks, file link). The external links partially compensate for missing protocol details. Overall, adequate but with clear 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 description coverage is 100% for the single 'blind' parameter, which already states 'Omit answer keys.' The description adds context by linking the parameter to 'blind evaluation,' but this is a minor addition. Following the rubric, the baseline is 3 when the schema is fully descriptive, and the extra context does not elevate it further.
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 retrieves 'Planning Benchmark v2' comprising '50 free evaluation tasks for AI financial-advice systems' and details the content (answer keys, stale figures). It uses a specific verb and resource, and the content is distinctively different from sibling tools (household schemas, reference parameters), so differentiation is implicit.
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 implies usage for AI financial-advice evaluation through phrases like 'evaluation tasks' and 'blind evaluation', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions for choosing a sibling tool. The blind=true note gives conditional usage but not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the one-time-purchase product URL for a bundle.
| Name | Required | Description | Default |
|---|---|---|---|
| bundleId | Yes | Bundle id, e.g. 'B01' (see list_bundles). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'one-time-purchase' which is a useful behavioral attribute, but it does not disclose error behavior, output format (explicitly), or any side effects. For a get operation, it's minimal and leaves the agent uncertain about what happens on invalid bundleId or the exact return structure.
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, compact sentence that is front-loaded with the key purpose. Zero wasted words; it is appropriately concise and clear.
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 no output schema, the description is mostly adequate. It implies the return is a URL ('product URL'), which covers the main need. Missing error-handling details and explicit return type, but for this simple case, it's sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides (bundleId with example and reference to list_bundles). No extra value is added.
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 ('Get'), a specific resource ('one-time-purchase product URL'), and the target ('a bundle'). It clearly distinguishes from sibling tools, which focus on households, benchmarks, or listing bundles. No ambiguity about what this tool does.
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 no explicit when-to-use guidance or alternatives. However, the schema references 'list_bundles' for obtaining a bundleId, which indirectly suggests usage. But the description itself does not state when to use this tool versus others, so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a source-verified U.S. federal financial-planning parameter by key and tax year, with its value and primary-source citation. Without a paid key, only the headline free-sample figures return values.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Parameter key, e.g. 'retirement.401k.elective_deferral.under_50' (see list_reference_parameters). | |
| tax_year | No | Tax year (default 2026). 2027 is filled in as the IRS, SSA and CMS publish; see https://www.wealthschema.com/rule-sets/2027. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that without a paid key only headline free-sample figures are returned, which is important access context. It does not explicitly state read-only behavior or error handling, but for a 'get' tool this is acceptable.
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 with no wasted words; the purpose is front-loaded and the limitation follows. Structure is ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter lookup with no output schema, the description covers what is returned (value and citation) and the paid-key limitation. It does not detail error cases or response format, but this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the notion of 'source-verified' and 'primary-source citation' but does not explain parameter formats beyond what the schema already documents. The schema's example and tax-year enum already handle the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a resource ('U.S. federal financial-planning parameter'), and a key/tax-year lookup scope, and indicates the return includes a value and citation. It is clearly distinguishable from sibling list_reference_parameters (which lists keys) and get_planning_benchmark (a different metric type).
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 implies this tool is used when you need a specific parameter value by key and tax year. It does not explicitly state alternatives or when not to use it, though the schema's pointer to list_reference_parameters partially compensates. No exclusion guidance is given, making it adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one deliberately-insufficient sample household (PII removed, dollar amounts banded, 96-month trajectory truncated to 12 months, projections withheld). Free sample archetypes: F-01, A-01, H-01, H-02, S-01, R-01, RE-01, RL-01. Other archetypes are in the paid corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| archetypeId | Yes | Archetype id, e.g. 'A-01' (see list_archetypes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It thoroughly discloses key behavioral traits: PII removed, dollar amounts banded, trajectory truncated to 12 months, and projections withheld. This exceeds the minimum expectation and gives the agent a clear picture of what will and won't be returned.
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 with no filler. The key limitation is front-loaded, followed by a precise list of valid archetypes. Every sentence earns its place and the description is easy to scan.
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 compensates well by describing the sample's degraded nature and the available archetype set. It doesn't describe the exact output structure, but the sibling describe_household_schema likely covers that, and the single required parameter is fully addressed.
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 the parameter already includes an example and reference to list_archetypes, so the baseline is 3. The description adds extra value by explicitly enumerating the free archetype IDs available, which helps the agent choose a valid parameter without an additional call.
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 operation: 'Get one deliberately-insufficient sample household'. It distinguishes the tool from siblings by focusing on a sample household, while siblings handle schemas, benchmarks, reference parameters, and bundles. The list of free archetypes adds further specificity.
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 notes that only listed archetypes are free and that other archetypes are in the paid corpus, which gives some context on limits. However, it does not explicitly state when to prefer this tool over siblings like get_planning_benchmark or list_archetypes, nor does it state any exclusion conditions beyond the free/paid distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all synthetic household archetypes (id, name, life stage, wealth tier, household type).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. The verb 'List' conventionally implies a read-only operation with no side effects, but the description does not explicitly state that it is safe, non-mutating, or idempotent, nor does it mention any limitations such as pagination or data volume.
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, front-loaded sentence that conveys the action and the returned fields with no redundant words. Every word earns its place, and it is appropriately sized for a zero-parameter read-only list 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 zero-parameter read-only list, the description names the resource and the fields returned, which gives an agent a clear sense of the result content. However, without an output schema it does not specify the response envelope (e.g., array vs object) or any pagination, and it lacks explicit usage context, leaving a small but noticeable 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?
The input schema is an empty object with zero parameters, so the baseline for parameter semantics is 4. There are no parameters for the description to clarify, and the description does not need to add anything because none exist.
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 specific verb 'List' and the resource 'synthetic household archetypes', and enumerates the included fields (id, name, life stage, wealth tier, household type). The resource name differentiates it from sibling list tools like list_bundles, but it does not explicitly contrast with them, so it does not fully earn a 5.
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 no guidance on when to use this tool versus alternatives such as describe_household_schema, get_sample_household, or list_bundles. There is no stated use case, no context on when a list of archetypes is needed, and no indication of what this tool is not for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List product bundles (themed household datasets) with use cases and one-time-purchase links.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List' reasonably implies a read-only operation, and the description reveals that results include use cases and one-time-purchase links. However, it does not mention pagination, data freshness, or any side effects, leaving some behavioral detail undisclosed.
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 sentence that front-loads the main action ('List product bundles') and adds clarifying detail immediately. There is no filler, repetition, or unnecessary 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 parameterless listing tool with no annotations and no output schema, the description provides sufficient context: it identifies the resource (product bundles), clarifies their nature (themed household datasets), and states what is returned (use cases and one-time-purchase links). Given the low complexity, nothing critical 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?
The tool has zero parameters and the input schema is empty, so no parameter documentation is needed. Baseline 4 applies because there are no parameters for the description to elaborate on; the description's mention of bundle content does not contradict or omit any parameter information.
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 and resource: 'List product bundles (themed household datasets)'. It clarifies that bundles are themed household datasets, which distinguishes them from sibling tools like list_archetypes and list_reference_parameters. The mention of included use cases and purchase links further defines the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need product bundles with use cases and purchase links, use this tool. However, it does not explicitly state when to use it instead of alternatives such as list_archetypes or get_purchase_link, and it offers no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the U.S. federal financial-planning parameters for a tax year (keys, labels, domains), marking which are in the free sample. Optionally filter by domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional filter: retirement | tax | social_security | medicare | health | estate. | |
| tax_year | No | Tax year (default 2026). 2027 is filled in as the IRS, SSA and CMS publish; see https://www.wealthschema.com/rule-sets/2027. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose that the output marks which parameters are in the free sample, which is useful context. However, it does not explicitly state that the operation is read-only, nor mention any rate limits, pagination, or error behavior. For a simple list operation, the read-only nature is implied, and the free-sample marking adds value, but more could be 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, front-loaded sentence that directly states the action and resource. Every word earns its place; there is no fluff or repetition. It is appropriately sized for the tool's simplicity.
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 low complexity (2 optional params, no output schema), the description covers the key aspects: what is listed, the free-sample marking, and the optional domain filter. It does not explicitly specify the return format (e.g., array of objects) but mentions keys, labels, and domains, which gives a reasonable idea. For a simple list tool, this is largely sufficient, though a bit more detail on return structure would round it out.
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 provides 100% coverage for both parameters: domain has a description listing valid values, and tax_year has a description and enum. The description only repeats 'Optionally filter by domain' and 'for a tax year', adding no new meaning beyond the schema. Since coverage is full, the baseline of 3 applies, and the description does not enhance parameter understanding.
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 action (list), the resource (U.S. federal financial-planning parameters), and the scope (for a tax year). It specifies output content (keys, labels, domains) and the free-sample marker, which distinguishes it from sibling tools like get_reference_parameter (singular retrieval) and list_archetypes (different resource). This is a specific, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing parameters with an optional domain filter, but it does not explicitly state when to prefer this over get_reference_parameter or other sibling tools. It provides no exclusions or alternative names. The context is implied by the verb 'list' versus 'get', but not made explicit, so guidance is only implicit.
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.
v0.1.0describe_household_schemaget_planning_benchmarkget_purchase_linkget_reference_parameterget_sample_householdlist_archetypeslist_bundleslist_reference_parametersScored across 8 tools
Most tools target clearly distinct resources (archetypes, bundles, reference parameters, benchmark). The only mild overlap is between list_bundles (which already includes purchase links) and get_purchase_link, plus the list_/get_ pair for reference parameters, but descriptions make the split legible.
Every tool follows a uniform snake_case verb_noun pattern (describe_, list_, get_), with verbs that accurately reflect the operation. No mixed camelCase or vague verbs.
Eight tools is well-scoped for a read-only data/benchmark catalog: discovery (list/describe), retrieval (get_sample, get_reference_parameter), and commerce (purchase link, benchmark). Each tool earns its place.
The API covers the domain's lifecycle: schema introspection, archetype/bundle listing, sample retrieval, purchase links, reference parameters, and a benchmark with blind mode. Minor gaps exist (e.g. no search-by-attribute across archetypes or bundle contents preview), but core agent workflows are supported.
Cited 2026 U.S. planning figures (IRS, SSA, CMS), synthetic household samples, and an AI benchmark.
Retirement Monte Carlo, tax-aware withdrawal and Roth-conversion plans, and a 2026 return estimate.
Deterministic US financial planning: retirement Monte Carlo, Roth conversion, RMD, tax, IRMAA, SS
Current source-cited 2026 US tax constants and calculators for AI agents; every answer cites IRS.
