Money Tools

roth_irmaa

What a Roth conversion does to Medicare costs (2026 IRMAA tiers).

Args: status: filing status: "single", "joint" (married filing jointly) or "separate" (married filing separately). magi: modified adjusted gross income before the conversion, USD. roth_conversion: extra income the Roth conversion would add, USD.

Returns JSON with the IRMAA tier before and after, Part B monthly premium, Part D surcharge, the extra annual Medicare cost per person, and the MAGI room left before the next bracket cliff. Tiers from the official Medicare 2026 costs fact sheet; IRMAA is a two-year lookback.

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": {
      "status": "<status>",
      "magi": "<magi>"
    },
    "name": "roth_irmaa"
  }
}

Input Schema

Name	Required	Description	Default
`magi`	Yes
`status`	Yes
`roth_conversion`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description carries the load; it does disclose the return contents, the official source of the tiers, and the two-year IRMAA lookback assumption. It says nothing about the 'separate' filing status being handled differently, whether thresholds are per-person or per-couple, or any failure mode, so meaningful gaps remain for an unannotated tool.

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?

The purpose is front-loaded in one sentence, followed by a compact Args block and a one-paragraph return summary. The docstring formatting is slightly mechanical but every line carries information; nothing is padded or repeated.

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 three-parameter read-only calculator with an output schema available, this covers inputs, output fields, the underlying data source, and the lookback timing. The only shortfall is unstated assumptions about how 'separate' status and per-person vs per-couple thresholds are treated.

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

Parameters5/5

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

Schema description coverage is 0%, yet the description defines every parameter: 'status' with its three accepted string values, 'magi' as pre-conversion modified AGI in USD, and 'roth_conversion' as the added income in USD (schema defaults it to 0). This fully compensates for the empty schema descriptions.

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 opening sentence names a specific computation (the effect of a Roth conversion on Medicare IRMAA costs) and pins the rule set to the 2026 tiers. It is unambiguous what the tool returns, and the sibling ss_break_even is a different calculation entirely, so no confusion is likely.

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?

The use case is implied by the purpose sentence — estimate Medicare cost impact of a Roth conversion before executing it — but there is no explicit when-to-use/when-not-to-use statement and no named alternative. The 'two-year lookback' note helps frame the result in time but is behavioral context rather than usage routing.

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

All Money Tools 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.