Home & Loans View All →
Savings & Wealth View All →
Retirement View All →
Income & Taxes View All →
Debt & Credit View All →
Everyday View All →
All Guides →
Planners About

MCP Changelog & Version History

What changed on mcp.digitalcalculator.info/mcp, release by release. Through the whole 0.x era, anonymous-tier responses stayed byte-for-byte stable and every anonymous-surface change was purely additive. Contract 1.0.0 is the one deliberate exception: a pre-listing surface consolidation made while the 0.x rules still permitted it — with every retired tool kept working indefinitely through its REST alias. For the rules that govern how we change things from 1.0.0 forward, see the Versioning & Deprecation Contract.

Current version

The MCP endpoint tracks three independent version numbers, each covering a different surface:

  • Contract version — returned as serverInfo.version in the initialize handshake at https://mcp.digitalcalculator.info/mcp. This is the canonical version of the tool contract (tool names, input/output shapes, envelope). Point any MCP client at the endpoint and read the field — it can never disagree with what the server is running.
  • npm shim version (@markcolabs/mcp, currently 0.4.3) — versions the optional stdio transport adapter, not the contract. A shim patch does not imply a contract change.
  • Per-tool engine version (engineVersion, returned in every response) — versions the math behind a specific result; moves when a calculator’s formula is refined, independently of the contract.

These are deliberately separate axes (see the Versioning & Deprecation Contract); a change to one does not imply a change to the others.

Reading the live version

We deliberately do not print the current contract version as a static number on this page — a hardcoded number can drift out of sync with the running server. The authoritative value is always the serverInfo.version field of the initialize handshake response. Read it from the endpoint and you can never be wrong.

Release history

Each release below carries a Compatibility line. Across the entire 0.x history the answer is the same: anonymous-tier parity maintained byte-for-byte, no breaking change. Contract 1.0.0 is the single deliberate exception — the surface consolidation the 0.x version range existed to permit, executed before any directory listing froze the schemas, with the REST compatibility layer keeping every retired name working.

Release Date What changed Compatibility
v0.1.0 2026-05-09 First public shim release. 5 tools. Initial release — baseline.
v0.2.0 2026-05-22 Hosted Streamable-HTTP cutover; 2 tool renames; engine-version policy reset to 1.0.0. Anonymous-tier parity maintained byte-for-byte; no breaking change.
v0.2.1 2026-05-27 Packaging/licensing polish (patch). Anonymous-tier parity maintained byte-for-byte; no breaking change.
v0.3.0 2026-05-27 Retirement cluster added (IRA, Roth conversion, RMD, HSA) → 9 tools. Anonymous-tier parity maintained byte-for-byte; no breaking change.
v0.4.3 2026-06-12 stdio↔HTTPS transport-adapter architecture; MCP Registry submission metadata; 13 tools at that release. Anonymous-tier parity maintained byte-for-byte; no breaking change.
S150 2026-06 / 07 Bearer-tier authentication foundation + backward-compatibility regression gate (16-call golden baseline + schema-snapshot CI check). Anonymous-tier parity maintained byte-for-byte; no breaking change.
S151 2026-06 / 07 Published the formal MCP Tool Versioning & Deprecation Contract (notice windows: 90 days anonymous / 180 days Bearer). Anonymous-tier parity maintained byte-for-byte; no breaking change.
v0.8.x 2026-07-06 Added generate_report (tool 14): branded PDF report generation for Bearer-tier sessions. Bearer-tier only — anonymous responses untouched; no breaking change.
v0.9.x 2026-07-07 Added money_flow_map (tool 15): conversational budget → computed summary + interactive Sankey-map deep link, Bearer-tier at launch. Bearer-tier only — anonymous responses untouched; no breaking change.
v0.10.x 2026-07-11 Contract-quality wave: round-to-cents on all 13 calculator outputs plus truthful-caveat additions (RMD joint-life, 401(k) catch-up, HSA excess-contribution, IRA deductibility, and more). Additive fields only; anonymous == authenticated byte-parity preserved; no breaking change.
v0.11.x 2026-07-17 money_flow_map promoted to the anonymous tier: it now appears in the anonymous tools/list (14 tools) and the methodology manifest, callable without an API key under standard anonymous rate limits. Additive to the anonymous surface (a new tool appears; every existing tool’s response is unchanged). MINOR bump; golden baseline + schema snapshot regenerated with the release.
1.0.0 2026-08-07 Contract 1.0.0 — surface consolidation. The anonymous surface becomes 10 tools: four new verb-first scenario tools (plan_retirement_income, evaluate_roth_conversion, check_contribution_eligibility, project_growth) absorb eight granular tools; the four highest-traffic calculators and money_flow_map are kept. Adds the provenance envelope fields (rule_year, sources[]), three statutory reference-data resources (dc://irs/limits/2026, dc://irs/uniform-lifetime, dc://ssa/bend-points/2026), the prompts capability (3 prompts), a shared canonical vocabulary across every schema, and protocol revision 2026-07-28 support (server/discover, session-header-free operation, response cacheability advertisements). The -poc suffix retires. The one deliberate breaking release, made under 0.x rules before any directory listing froze the surface. REST compatibility guarantee: every pre-1.0 alias at api.digitalcalculator.info/v1/tools/{alias}/calculate keeps working indefinitely with its original request/response shapes — see the alias table. A 32-case replay battery verified numeric parity between the absorbed tools and their composite successors. 1.0.0 has been live on the hosted production endpoint since 2026-08-08 — read serverInfo.version from the endpoint for the authoritative answer.
1.2.0 2026-09-22 (stage; production on the owner's dispatch) Conformance, tranches 1 + 2. Tranche 1 (folded into this release rather than shipped separately as 1.1.0 in production): every JSON-RPC result carries resultType: "complete"; snake_case aliases replace camelCase as the advertised spelling for 17 arguments across the four single-quantity calculator tools (deprecated camelCase still works, marked in tools/list and flagged with a namespaced _meta marker); the anonymous 429 body became a JSON-RPC error object; capabilities.extensions["io.modelcontextprotocol/ui"] and _meta["openai/outputTemplate"] declared on view-bearing tools. Tranche 2: Bearer-tier 401/429 denials on /mcp became JSON-RPC error objects too (-32001 / -32000, distinct codes, HTTP status and rate-limit headers unchanged); the anonymous per-IP window now meters tools/call only — discovery methods (initialize, server/discover, ping, tools/list, resources/list, resources/read, prompts/list, prompts/get) are exempt; additionalProperties: false is now enforced (not just advertised) on tools/call for all ten tools; plan_retirement_income now returns non-empty provenance[]; ttlMs/cacheScope moved from a bare _meta key to top-level result fields on every list-shaped result, and to _meta["info.digitalcalculator/cache"] on resources/read. Purely additive (MINOR) on both tranches — golden baseline 19/19 same fields, 0 value diffs; schema snapshot zero contract-surface diffs. Two rules tightened in a spec-compliant way rather than removing anything: unknown top-level arguments, previously stripped silently, are now rejected with INPUT_VALIDATION (the schema always advertised additionalProperties: false, so a client written against the published contract was never sending them); and the Bearer denial body moved from a bare {"error":...} object into the JSON-RPC error envelope (HTTP status and every rate-limit/quota header unchanged). See the argument deprecation notice and the API Reference for the full 1.2.0 wire.
1.3.0 2026-09-23 (stage; production on the owner's dispatch) Server polish: error classes, discoverable defaults, and a prompt that completes. INPUT_VALIDATION messages now name their failure class instead of one shared range message — missing ("<field> is required"), wrong type ("<field> must be a number/an integer/a string/a boolean"), and unknown argument ("unknown argument '<key>' — did you mean '<closest>'?" or "— no close match.", both naming the accepted keys); genuine out-of-range messages are unchanged. The 23 input properties whose description already stated a default (plan_retirement_income 7, evaluate_roth_conversion 2, check_contribution_eligibility 1, project_growth 2, paycheck_net_pay 5, emergency_fund_recommendation 6) now carry that default as a real JSON Schema default keyword. Internal history (finding IDs, “absorbs the former …” clauses, engine file names) was stripped from every description on the anonymous surface. The instructions field was restructured from a 2,073-character unbroken paragraph into a line-broken, ≤1,500-character sequence (YMYL posture, unit contract, routing, provenance, resources). The retirement-readiness-review prompt now declares annual_return_percent (optional, stated fallback 7) so a host that collects exactly the prompt's declared arguments can complete the review. Purely additive (MINOR) — golden baseline 19/19 same fields, 0 value diffs; schema snapshot shows 23 property-add diffs, all default keys, 0 property-remove/type-change/value-change. Every 1.2.0-valid request remains 1.3.0-valid with identical figures. See the API Reference for the full 1.3.0 wire and worked examples in the Quickstart.
1.4.0 2026-09-23 (stage); production 2026-09-27 A tenth tool: evaluate_affordability. A fifth verb-first scenario tool that answers “how much home can I afford?” from gross annual income, existing monthly debt, down payment, rate and term: it computes the front-end and back-end debt-to-income ratios at lender-standard targets (defaults 28/36, caller-adjustable) and searches for the maximum home price whose principal & interest keeps both ratios at or under target — the same amortization formula mortgage_monthly_payment uses, inverted by a bracketed goal-seek rather than re-derived. P&I only (an optional monthly_property_costs folds taxes, insurance, HOA and PMI in as a fixed monthly amount). Returns max_home_price, max_loan_amount, monthly_payment_at_max, both ratios, binding_constraint (which target capped the answer) and a note stating the scope, the targets applied and the search outcome. Listed after the four composites; REST twin at /v1/tools/evaluate-affordability/calculate; the methodology manifest gains its entry (tool_count 9 → 10); instructions now routes affordability questions to it instead of listing affordability as not offered. Purely additive (MINOR) — no existing request, figure or schema moves: golden baseline 19/19 unchanged and extended by two calls for the new tool (they are asserted only once production serves 1.4.0 — the anonymous-parity re-run reports them as pending deploy, not drift, until then); schema snapshot shows one tool-add, 0 changes to any existing tool. Every 1.3.0-valid request remains 1.4.0-valid with identical figures. Rollout: live on the stage endpoint; the hosted production endpoint keeps serving contract 1.3.0 (nine tools) until the owner dispatches the production deploy — read serverInfo.version from the endpoint before relying on the new tool. See the API Reference entry.
1.5.0 2026-09-24 (stage); production 2026-09-27 Ask the server for an outcome, and let the server ask you for a number. Two additive capabilities, each reached only by a call that opts into it. (a) Target mode on plan_retirement_income: an optional target: { metric, value, solve_for } input. State the outcome you want — a projected 401(k) balance at retirement (future_balance) or a Social Security monthly benefit (monthly_benefit) — and the tool solves for the input that reaches it by inverting its own forward projection with a bracketed goal-seek, rather than making you guess an input and re-call. “When can I retire?” is solve_for: "retirement_age". Solvable inputs are the dials you actually control: contribution_percent, annual_return_percent, retirement_age, balance and annual_salary for a balance target; claim_age and annual_salary for a benefit target. Inputs that are facts rather than dials (birth_year, years_worked, life_expectancy, the employer-match fields, the booleans) are refused by name with the reason. An unreachable target is answered, not refused: the result's target block reports reached: false, the metric at both ends of the searched range, and modules_computed_at — the value the projection below it was actually computed at, which is not your target. (b) Elicitation (Multi Round-Trip Requests): a call missing a required input can come back as resultType: "input_required" with an inputRequests map (one elicitation/create whose requestedSchema is derived from the tool's own published input schema, so every field carries its real type, range and unit) plus an opaque requestState; collect the values and retry the original request with inputResponses. This is the protocol’s 2026-07-28 MRTR pattern, not the server-initiated elicitation that revision removed. Because this server keeps no session state, it cannot recall the capability you declared at initialize — so it asks only when the call declares support, via params._meta["info.digitalcalculator/elicitation"]: true. Without that key the behaviour is exactly 1.4.0's. Purely additive (MINOR) — no previously-valid request changes shape, message or figure: golden baseline 21/21 unchanged and extended by two target-mode calls (reported pending deploy, not drift, until production serves 1.5.0); schema snapshot shows one property-add (target on plan_retirement_income), 0 changes to any other tool. Both new behaviours are opt-in, so a client written against 1.3.0 or 1.4.0 sees no change at all. The REST twins are untouched — MRTR is a JSON-RPC pattern and has no REST equivalent. Rollout: live on the stage endpoint; the hosted production endpoint keeps serving contract 1.3.0 until the owner dispatches the production deploy — read serverInfo.version from the endpoint before relying on either capability. See the API Reference entry.
1.6.0 2026-09-25 (stage); production 2026-09-27 Versioned, diffable reference data. Every statutory dc:// resource now carries a version (the rule year plus the date its tables were last verified, e.g. 2026.20260924) and a content_hash (sha256: over the canonical JSON of the body without those two fields), so a client can cache a resource and tell for certain whether it changed. dc://irs/uniform-lifetime gains the published date the other two already carried. supersedes is now filled in from the years the server holds: dc://ssa/bend-points/2026 links the new dc://ssa/bend-points/2025. Two new resources: dc://ssa/bend-points/2025 and dc://ssa/bend-points/diff/2025..2026, a field-by-field rule-year diff (path, old value, new value). The same diff shape exists for dc://irs/limits/diff/{from}..{to} and appears for 2026..2027 when the 2027 IRS figures are added; no 2025 IRS resource is served, because the server does not hold a complete 2025 IRS record. See Versions, hashes and rule-year diffs. Purely additive (MINOR) — every existing resource body is its previous serialization plus the new fields; the one value that moves is supersedes on dc://ssa/bend-points/2026 (null → the 2025 URI). No tool, schema or figure changes: golden baseline 23/23 unchanged, schema snapshot unchanged.
1.7.0 2026-09-25 (stage); production 2026-09-27 Citations you can click, and a result a model can read. (a) https source links: every success envelope gains source_links[] — one { uri, url } pair per sources[] entry, where url is the public page that shows the same figures — and every provenance[] record gains the same url beside its uri. Where no page shows a resource (the methodology manifest, or a rule year the site does not publish), the link is the tool’s methodology page; see https source links. (b) The content summary: a request that sends MCP-Protocol-Version 2025-06-18 or later gets a short plain-text summary in content[0].text — key figures (currency to the cent, percentages to at most two decimals), notes with argument names spelled as the schema spells them, applied assumptions, unit warnings, methodology and source links, and the disclaimer — instead of the serialized envelope; structuredContent keeps everything, including year-by-year series. For plan_retirement_income the text a model reads falls from about 9 KB to about 3.5 KB. A request without the header keeps the serialized envelope, and _meta["info.digitalcalculator/contentFormat"] ("summary" | "json") picks either per call; see The content summary. (c) evaluate_affordability’s methodology.url is now its own page, /mortgage-affordability-calculator/methodology/ (was the mortgage P&I methodology). (d) The withholding-checkup prompt now names pre_tax_401k_annual, pre_tax_cafeteria_annual and pre_tax_deductions_annual instead of their deprecated camelCase spellings. Additive (MINOR) — every existing structured field keeps its name and value, and no figure moves: golden baseline 23/23 unchanged; the schema snapshot shows only added output properties (source_links, provenance[].url). The behaviour that moves is content[0].text for requests that send MCP-Protocol-Version: those clients also receive structuredContent, which carries the full result; requests without the header see the pre-1.7.0 text.
1.8.0 2026-09-25 (stage); production 2026-09-27 One naming convention for results: the v2 envelope. Every success envelope of the ten anonymous tools — on tools/call and on each tool’s REST twin — gains, beside the keys it already had: (a) a snake_case twin of every camelCase key, at every depth (monthly_payment beside monthlyPayment; modules.accumulation.year_by_year beside yearByYear); (b) a *_percent field for every rate or ratio, as a whole-number percent — the decimals become percents rounded to 2 decimals (marginal_rate_on_conversion_percent: 22 beside marginalRateOnConversion: 0.22; state_effective_rate_percent beside stateEffectiveRate), computed percents are rounded to 2 decimals (savings_rate_percent: 33.65), and a percent that echoes your own argument keeps your exact value; (c) notes that name arguments the way the schema does (traditional_deduction_note says workplace_coverage), and an argument on every unit warning; (d) calculated_at, engine_version, an inputs echo of the arguments the result was computed from (snake_case, after aliases and defaults — send it back and you get the same result) and defaulted_inputs, naming the ones that came from a default. The output schemas declare every new field and mark the camelCase properties deprecated; tool descriptions name the new keys. The 17 camelCase argument spellings stay accepted, now with the removal rule in their descriptions and in the _meta deprecation marker. See The v2 envelope. Additive (MINOR) — every existing key keeps its name and value byte-for-byte, every accepted argument is still accepted, and no figure moves: golden baseline 23/23 unchanged; the schema snapshot shows only added output properties (the twins, inputs, defaulted_inputs) and deprecated flags. The legacy REST-only aliases are unchanged. Scheduled removal: the camelCase argument spellings and the camelCase/decimal output keys are removed 2 minor versions or 60 days after production serves 1.8.0, whichever is later, in a MAJOR release under the contract’s notice rules.
1.9.0 2026-09-26 (stage); production 2026-09-27 The foundation for interactive result views (MCP Apps). (a) One app-only tool, recompute_scenario: { tool, arguments } returns exactly what calling tool with arguments returns. It is listed with _meta.ui.visibility: ["app"] so an MCP Apps host keeps it from the model; an interactive view calls it only when it cannot compute a changed scenario itself (a view built against an older engine, or a rule year it does not carry). Models should call the calculators directly, and it is not counted among the 10 tools. (b) Content-hashed view URIs: each ui:// view is linked and listed at ui://digitalcalculator/<view>-<hash>, where the hash is taken over the view’s HTML, so a host that caches views by URI picks up a changed view; resources/read answers any hash of a known view, and the earlier fixed URIs, with the current view. (c) Internally, the mortgage, loan and affordability tools now compute through one shared module per tool that the interactive views will also run, so a figure a view shows is the figure the server returns. See recompute_scenario and View URIs. Additive (MINOR) — one new tool and new view URIs; every existing tool, argument, key and value is unchanged: golden baseline 23/23 unchanged, and the full result of 1,768 calls to the three refactored tools is byte-identical before and after. The schema snapshot adds recompute_scenario only. The five existing views are the same documents at new URIs; their old URIs keep working.
1.10.0 2026-09-26 (stage; the two new views are served on the stage endpoint only for now) The interactive home scenario. (a) One view now serves both mortgage_monthly_payment and evaluate_affordability, so evaluate_affordability gains a ui:// view (_meta.ui.resourceUri and _meta["openai/outputTemplate"]). It shows the payment or the maximum home price, a year-by-year repayment chart with the previous scenario drawn as a dashed line, the front-end and back-end debt-to-income ratios against their targets (in words as well as on a gauge), and sliders that recompute in the view with the same calculation module the server runs. When you stop adjusting for 1.5 seconds, the view tells the assistant which scenario you settled on, and it says so on screen; a Use this scenario button shares it at once. Where the host offers it, a full-screen mode compares up to four pinned scenarios. (b) loan_monthly_payment’s view is rebuilt the same way. (c) Both views read only the v2 (snake_case) keys, so the scheduled removal of the camelCase names cannot break them. For now both are served only by the stage endpoint; the production endpoint keeps its current views until they move there. Additive (MINOR) — a view on a tool that had none; no tool result, argument or schema changes: golden baseline 23/23 unchanged, and the schema snapshot is unchanged. Tool results are the same on both endpoints. The earlier mortgage and loan view URIs keep resolving.
1.11.0 2026-09-26 (stage; the two new views are served on the stage endpoint only for now) Growth and emergency-fund views, and a call counter. (a) emergency_fund_recommendation gains a ui:// view: the target, a progress ring of the savings so far against it with the time to the goal in words, and the month-by-month savings balance against the target, with sliders that recompute in the view. (b) project_growth’s view is rebuilt as a stacked area of the money put in and the growth on it, year by year, with the year growth overtakes the money put in marked. Both share a settled scenario with the assistant the same way as the 1.10.0 views, and say so on screen. For now both are served only by the stage endpoint; the production endpoint keeps its current views. (c) recompute_scenario also accepts emergency_fund_recommendation. (d) The server counts calls per tool per day: each call records the tool name and the date, and nothing else — no arguments, results or caller details. Additive (MINOR) — a view on a tool that had none, and one more value in recompute_scenario’s tool list; no tool result or argument changes, and tool results are the same on both endpoints. The earlier growth view URI keeps resolving.
2.0.0 2026-09-26 (stage); production 2026-09-27 paycheck_net_pay stops computing state income tax, for every state. The state figure for the 41 states and DC that tax wages came from one effective rate per income tier, and where it could be checked against a full bracket calculation it differed by up to 87%, in both directions. The $0 for the 9 states with no tax on wage income is not a complete state deduction either (Washington, for example, withholds WA Cares and paid-family-leave premiums). So, for every state, unless you pass the new optional argument state_local_tax_annual: state_tax, state_tax_annual, state_effective_rate_percent, state_tax_source and no_state_income_tax are null, a new state_tax_status field reads not_provided, state_tax_notes says state and local taxes are not included, and net pay is after federal tax and FICA only. state_local_tax_annual (USD per year, no default) takes your own state and local tax and uses it exactly, for any state (state_tax_status: "user_supplied"). state is still accepted and validated, and changes no figure. The paycheck engineVersion moves to 2.0.0. See paycheck_net_pay. MAJOR — five output fields that were always numbers or booleans may now be null, which the versioning rules class as breaking. Nothing is removed or renamed and every call that worked before still works; net pay for a state that taxes wages rises by the estimate that is no longer deducted, and federal and FICA figures are unchanged. The 90-day notice window was waived, and is disclosed here and on the contract page: the release withdraws a state-tax figure that could be materially wrong on a tax question, and keeping it published for the notice period was the greater risk (owner decision, 2026-09-26). Check state_tax_status before reading state_tax as a number. The schema snapshot adds the new argument and state_tax_status and makes the five fields nullable. Golden baseline: the Texas paycheck call keeps every federal, FICA and net-pay figure, with its state fields now null, and two paycheck calls are added (a state with no figure, and a caller-supplied figure).
2.1.0 2026-09-27 (stage); production 2026-10-04 Two corrections and one new optional argument. (a) project_growth takes rate_type. Omitted or nominal, the rate compounds at compounding_frequency as before, the compound interest calculator’s convention. apy reads it as an annual percentage yield, the rate a bank advertises, and runs the savings calculator’s formula. Before this release an APY passed to the tool was read as nominal and overstated the balance: $10,000 plus $500 a month at 5% for 10 years gave $94,111.23, where the savings calculator gives $93,470.53. With rate_type: "apy" the tool now gives $93,470.53. When the default is applied, assumptions says so. (b) plan_retirement_income’s accumulation module applies the IRC 415(c) limit on total annual additions (employee plus employer, with any catch-up on top), taking the excess off the employer match, and adds annual_additions_note when it binds. The 401(k) calculator already applied it, so for a $500,000 salary with a 20% deferral and a 100% match up to 10%, age 45 to 65 at 7% with catch-up, the module gave $3,293,789.30 and now gives the calculator’s $3,191,300.57. (c) emergency_fund_recommendation’s description no longer describes a difference from the site’s methodology that no longer exists: the tool and the calculator run one engine. (d) The interactive views follow: the mortgage view reads the snake_case argument names, the 401(k) view (and the embeddable 401(k) widget, which shares it) applies the 415(c) limit, and the earlier project_growth view shows a notice for an APY result rather than a nominal card. Additive (MINOR) — one optional input and two output fields; every call that worked before still works. Without rate_type, project_growth figures are unchanged. The 415(c) cap is a correction toward the statute: it moves only high-salary, large-match accumulation projections, and always downward; typical projections do not move.
2.2.0 2026-09-28 (stage); production 2026-10-04 The RMD start age for people born July 1949 through 1950. plan_retirement_income’s rmd module gave a start age of 70½ for everyone born in 1950 or earlier. Under the SECURE Act of 2019, anyone who reached 70½ after December 31, 2019 — born on or after July 1, 1949 — starts at 72, so the module now reports 72 and the matching first RMD year for births from July 1949 through 1950 (born 1950: 72 and 2022, where it gave 70½ and 2021). Birth year alone cannot split 1949, so the tool takes a new optional birth_month (1–12). Without it, a birth in 1949 or earlier is read as the first half of the year, which gives the earlier start age and first RMD year, and assumptions.birth_month says so. The RMD amount itself does not change: everyone affected is past both ages. The RMD calculator applies the same rule with the birth month it already asks for. Additive (MINOR) — one optional input; every call that worked before still works. The start age and first RMD year move only for births in 1950 or earlier (a correction toward the statute); births from 1951 on are unchanged, and so is every RMD amount.
2.3.0 2026-09-28 (stage); production 2026-10-04 The Form W-4 Step 3 dependent credit, split by kind. paycheck_net_pay applied one flat $2,000 per dependents, at every income. Form W-4 (2026) Step 3 has two amounts — $2,200 per qualifying child under 17, $500 per other dependent — and applies only when total income is at or below $200,000 ($400,000 married filing jointly). The tool now takes optional children_under_17 and other_dependents (each 0–20); the legacy dependents still works, read as qualifying children under 17, and a new dependent_credit_status field (applied, none_claimed, or income_above_limit) says what happened. Sending dependents together with either new count is refused rather than guessed. When the legacy field is what moved the credit, the new dependents_reading_note field says it was read as qualifying children under 17 (null otherwise). The paycheck engineVersion moves to 2.1.0. Additive (MINOR) — two new optional inputs and two new output fields; every call that worked before still works and no existing figure moves for a call that used only dependents at $0. A call using a non-zero dependents above $200,000/$400,000 income now correctly reports no credit, where the flat pre-2.3.0 rule would have applied one anyway — a correction toward the form, riding the MINOR (a call at that shape is new territory for the tool: dependent_credit_status did not exist before). Golden baseline: the three paycheck calls that send dependents: 0 or omit it keep every figure, their engineVersion moves to 2.1.0; two calls are added (above the income limit, and an other-dependent).
2.4.0 2026-09-28 (stage); production 2026-10-04 Answers say when their IRS figures may be out of date. check_contribution_eligibility and plan_retirement_income (with the accumulation module) add a warnings[] entry with field: "rule_year": rule_year_newer_published when the IRS has published a newer year’s figures that this server does not apply yet (today, the 2027 HSA limits on kind: "hsa" answers), and rule_year_past_review once the rule year’s figures pass their review date. The IRS limit figures behind these tools also moved to a single shared record used by both this server and the website’s calculators; no value changed. Additive (MINOR) — one new, optional-to-read warning entry, present only when there is something to say; no input, output field or figure changes. Golden baseline unchanged. The 401(k) and IRA result views are re-published at new content-hashed URIs (their bundled code was re-laid out, not changed); the old URIs still resolve.
2.5.0 2026-09-29 (stage); production 2026-10-04 Out-of-range arguments are named in the answer. An argument answered although it is outside its documented range adds a warnings[] entry with code: "input_out_of_range" naming the argument, the value and the accepted range. Today only paycheck_net_pay’s legacy dependents (documented 0 to 20, whole numbers) reaches it; every other documented range is already refused. The dependents description carries the notice. Additive (MINOR) — one new warning entry, present only for an out-of-range argument; no input, output field or figure changes. Golden baseline unchanged. Refusing the warned values is a later MAJOR change, announced under Upcoming changes for no earlier than 2027-05-27.
2.6.0 2026-09-29 (stage); production 2026-10-04 An estimate of the first required minimum distribution. plan_retirement_income called with both accumulation and rmd, before required minimum distributions start, adds modules.rmd.first_rmd_estimate: the projected balance at retirement carried at the same return to December 31 of the year before the first RMD year, divided by the Uniform Lifetime Table period for the age reached that year, with the method in a note. Additive (MINOR) — one new output object, present only for that pairing of modules before RMDs start; no input or existing figure changes. The tool’s engineVersion moves from 1.0.0 to 1.1.0. Golden baseline: one call added; the other plan_retirement_income calls keep every figure.
2.7.0 2026-10-04 (stage; production serves 2.6.0 until the owner’s dispatch) The Roth break-even compares like with like. evaluate_roth_conversion’s break_even_years is now the first whole year, within the new optional horizon_years (default 20), in which converting is at least even with not converting: the Roth balance against the Traditional balance after tax at the retirement rate, plus the conversion tax kept invested at the same return. Otherwise it is null. At constant rates that is 0 when the retirement rate is at or above the conversion’s effective rate, and null when it is below. The earlier log-ratio estimate compared the retirement rate with the marginal rate and could report a break-even of a few years where converting never caught up. The Roth conversion calculator uses the same rule from the same code. MINOR — a new optional input with a documented default; break_even_years keeps its name and type but changes meaning, and break_even_note is reworded. The tax, marginal and effective rates and the 5-year-rule flag do not change. The tool’s engineVersion moves from 1.2.0 to 2.0.0. Golden baseline: the one call with a retirement rate moves from 2.17 years to null; no other call moves.

Why the contract and shim versions differ

You’ll notice the shim version (@markcolabs/mcp 0.4.3) and the release milestones (S150, S151) don’t line up one-to-one. That is expected: the shim versions the stdio adapter, while the server-side foundation and contract work advance on their own cadence. The only version that governs the shape of your tool results is the serverInfo.version contract version from the handshake.

What a release can — and can’t — do to you

Under our contract, additive changes (new tools, new optional inputs, new output fields) ship freely as MINOR bumps and a compliant client keeps working through them unchanged. Engine-math refinements that keep the same output shape are PATCH bumps — the per-tool engineVersion in every response tells you when the math moved. The only kind of change that can break existing code — removing or renaming a tool, removing an input, renaming or retyping an output field — is a MAJOR bump, and from 1.0.0 forward it triggers the full deprecation process: at least 90 days notice for anonymous callers, 180 days for Bearer customers, with both shapes working during the coexistence window. The one exception so far is 2.0.0: the 90-day notice was waived, and is disclosed in the release history above and on the contract page, because the release withdraws a state-tax figure that could be materially wrong on a tax question (owner decision, 2026-09-26). Contract 1.0.0 itself was the 0.x-era consolidation those rules now protect against ever needing again — and even it removed nothing from REST.

How we keep releases from breaking you

This is enforced in CI, not just promised in prose. Every build runs a JSON schema snapshot of every tool’s input and output, plus a golden baseline of real tool calls captured with no Authorization header. If a release would change the shape of an anonymous response without an intentional, reviewed version bump, the deploy fails before it reaches you. See Anonymous-Parity Guarantee for the details.

FAQ

What version is the server running right now?

Read the serverInfo.version field from the initialize handshake at https://mcp.digitalcalculator.info/mcp. That is the canonical, always-current answer. We intentionally do not print it as a static number here so it can never go stale.

Does a new release require me to update my client?

Usually not. New tools and optional inputs are additive — existing clients ignore what they don’t call. 2.0.0 is the exception: paycheck_net_pay’s state fields can now be null, so a client that reads state_tax as a number should check state_tax_status first. Its notice window was waived and disclosed because it withdrew a state-tax figure that could be materially wrong. Otherwise you only need to act if we announce a MAJOR bump, which comes with 90–180 days of advance notice.

Why is the npm shim on 0.4.3 while you reference S150/S151 milestones?

The shim (@markcolabs/mcp) versions the optional stdio transport adapter. Sprint milestones like S150 and S151 cover server-side and contract work that doesn’t change the shim. They are separate axes on purpose — see Current version.

Where do I get notified about upcoming breaking changes?

The Deprecation Policy is the source of truth today: MAJOR bumps publish a dated notice, a note in the tool’s MCP description, and an X-Deprecation response header; Bearer customers also get a direct email. A subscribable feed is planned but not yet live. One removal is scheduled: the camelCase names retired by the 1.8.0 v2 envelope (see the removal rule).

See Also

This changelog is the customer-facing summary of releases. The authoritative contract version is always the serverInfo.version field of the live initialize handshake; the governing rules are in the Versioning & Deprecation Contract and ADR-0053.