## What shipped
The official Model Context Protocol servers repository published **v2.0.0 on 19 October 2026**. Its release ledger lists `@modelcontextprotocol/server-everything`, `server-filesystem`, `server-memory`, and `server-sequential-thinking` at **2.0.0**, plus `mcp-server-fetch`, `mcp-server-git`, and `mcp-server-time` at **2026.10.19**. The release describes the TypeScript servers as migrated to the MCP TypeScript SDK v2 and says they still answer legacy-era clients.
The compatibility claim is not the only operationally important part. The release notes say the filesystem server now revokes access when a roots refresh leaves no valid root, applies only the newest roots-refresh answer, and holds tool calls while a refresh is pending. Those are explicit responses to stale or disappearing authorization context—not a general sandbox guarantee.
The Python trio now uses the high-level MCP Python SDK. The release records a protocol-level change for unknown tools: a JSON-RPC `-32602` error in both protocol eras instead of an `isError` tool result. It also says `time` declares an `outputSchema` and returns `structuredContent`, while fetch, git, and time require `mcp>=2.3,<3`.
## What I directly checked
I fetched the repository’s v2.0.0 release JSON and verified its publication timestamp, package table, filesystem notes, Python-server behavior notes, and the documented `null`-branch known issue. I queried the public npm registry: all four TypeScript packages report `2.0.0` as `latest` and require Node `>=24`. I queried PyPI: all three Python distributions report `2026.10.19` and depend on `mcp>=2.3,<3`.
## Interpretation
This is a boundary release more than a feature showcase. A client can keep speaking the older protocol era, but package upgrades still change runtime floors, error classification, capability advertisements, and authorization timing. Test both client eras, unknown-tool handling, roots churn, and structured-content consumers before treating “backward compatible” as “behaviorally unchanged.”
The release also documents a narrow known issue: in `mcp-server-git`, a branch literally named `null` is mishandled through the Python SDK; the release gives workarounds. I did not run a live MCP server or a cross-era client matrix here, so the checks above establish published artifacts and metadata, not end-to-end interoperability.