- wire spec: lifecycle, stdio + Streamable HTTP transports, tools, utilities, legacy SSE, versioning, changelog (14 Tier 1) - client ecosystem: Claude Code/VS Code/Cursor/Codex configs, mcp-remote, Smithery, registries, Glama (12 Tier 1) - security/ops: authorization draft, trust model, poisoning, rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards - conclusions: minimal stdlib client on 2025-11-25, normalizer + resolver agent for pasted configs/GitHub URLs, untrusted-until- consent trust model; nothing built yet - audit PASS (14 subjects, 797 sources, 32 conclusions)
3.4 KiB
Versioning policy + current revision
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute - Research & Retrieval Division |
| Subject | mcp-client-support |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | Versioning (MCP docs, current) |
| Source URL | https://modelcontextprotocol.io/docs/learn/versioning |
| Source publisher / author | Model Context Protocol authors (Anthropic-donated open project; site docs) |
| Source type | standard |
| Source date (published) | Unknown - not stated (content served from /docs/2026-07-28/learn/versioning.md; references 2026-07-28 as current) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | gather-subagent direct page fetch, parent synthesis from evidence pack |
| Confidence | High |
| Status | Active |
Summary
This page states the versioning policy: versions are YYYY-MM-DD strings bumped only on backwards-incompatible change, with Draft / Current / Final revision states, and "The current protocol version is 2026-07-28." In 2026-07-28 every request declares its protocol version via the io.modelcontextprotocol/protocolVersion key in _meta, the server accepts or rejects each request independently, and clients may optionally call the mandatory server/discover RPC for up-front version selection. It points at a Backward Compatibility section for the handshake-based revisions (2025-11-25 and earlier).
Key findings
- "The current protocol version is 2026-07-28." Versions are
YYYY-MM-DDstrings, bumped only on backwards-incompatible change. - Revisions: Draft / Current / Final.
- In 2026-07-28: "Every request declares the protocol version… via the
io.modelcontextprotocol/protocolVersionkey in its_metafield, and the server accepts or rejects each request independently"; "Clients MAY callserver/discover, a mandatory RPC," for up-front version selection; "Calling it is optional." - "For interoperability with… handshake-based protocol revisions (
2025-11-25and earlier), see Backward Compatibility."
Pros / strengths
- Date-stamped versions with bump-only-on-breakage give clients a simple compatibility rule: same version string means same wire contract.
- The per-request versioning model in 2026-07-28 (version in
_meta, independent accept/reject) is stateless and probe-friendly compared to the handshake. - Explicitly preserves the handshake-based line (2025-11-25 and earlier) as an interop target with a dedicated Backward Compatibility section, rather than orphaning it.
Cons / limitations / caveats
- No publish date is stated on the page (only the 2026-07-28 current-version reference and the serving path), per the pack's Uncertainty notes; no explicit author names either.
- Two wire worlds now coexist (handshake-based 2025-11-25 and earlier vs stateless 2026-07-28), so a compatibility-maximizing client must eventually speak both.
- The Backward Compatibility section itself was not among the opened sources, so its exact guidance is not captured in this dossier.
Relevance to tai
Flags that the newest spec is stateless/per-request, but handshake-based 2025-11-25 remains the interop baseline a minimal client should target first. Sets the upgrade path: ship 2025-11-25 (handshake, sessions, ping), then add 2026-07-28 (per-request _meta version, server/discover) later.
Changelog
| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |