MCP Changelog & Version History

What changed on mcp.digitalcalculator.info/mcp, release by release — and why none of it broke your integration. We ship continuously, and anonymous-tier responses stay byte-for-byte stable across every release below. For the rules that govern how we change things, 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 history the answer is the same: anonymous-tier parity is maintained byte-for-byte and no breaking change has shipped. That is the whole point of our stability posture — we add tools and refine math without disturbing existing integrations.

Release history for the Digital Calculator MCP server and the @markcolabs/mcp shim
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 (current).	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.

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 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. To date, no MAJOR bump has shipped.

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 16-call golden baseline 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?

No. Every release in the history above preserved anonymous-tier responses byte-for-byte. New tools and optional inputs are additive — existing clients ignore what they don’t call. 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.