Keeping an MCP server alive as the spec moves

You wired Claude into your own data with a small MCP server. It reads jobs out of your scheduling table, or turns a folder of invoices into something an assistant can actually query, or exposes four internal endpoints so you stop copying numbers by hand. It worked. You stopped thinking about it. Then one morning it returned a protocol version error and you had to reconstruct, from memory, how any of it fits together.

That is the real maintenance cost of the Model Context Protocol for a one-person or five-person shop. Not the build, which is the small part, but keeping it working while the protocol underneath it changes. The July 2026 revision, for instance, deleted the initialize/initialized handshake and session identifiers outright and made the protocol core stateless [5]. If your server had session assumptions baked in, that was a real migration. The useful thing is that MCP now publishes its own break schedule, in a form you can put in a calendar. This guide is for the person who owns the code of a server. If you only install servers other people maintain, skip to the sections on client lag and SDK tiers, which are the two places you can still get hurt.

The protocol publishes its own break schedule

MCP versions are dates, in YYYY-MM-DD form, and the date means one specific thing: the last day a backwards-incompatible change was made. The version is not incremented for backwards-compatible improvements [1]. The current revision is 2026-07-28 [1]. So a version string is a compatibility claim, not a release counter, and a server that has not moved in a year may be perfectly current.

Since the July revision, version negotiation is per request rather than per session. Every request declares its version in the io.modelcontextprotocol/protocolVersion key of its _meta field, and on Streamable HTTP the same value rides along in an MCP-Protocol-Version header. The server accepts or rejects each request independently, and both sides may support several versions at once. A server that does not support the requested version answers with UnsupportedProtocolVersionError, listing what it does support, so the client can retry [1]. There is also a mandatory RPC, server/discover, which returns a server’s supported versions, capabilities and identity in one call. Servers MUST implement it; clients are not obliged to call it [8].

The part worth reading twice is the deprecation policy, adopted as SEP-2596. Every feature sits in exactly one of three states: Active, Deprecated, Removed. A deprecation requires a SEP that names the feature, states the rationale, documents a migration path or explicitly states that none is needed, and specifies a minimum deprecation window of at least twelve months, counted from the release of the revision in which the feature first goes Deprecated [2]. That floor can be shortened only for an active security risk, meaning a published advisory or documented in-the-wild exploitation with no in-place mitigation, and even then the shortened window must leave at least ninety days [2].

Six entries are already on the clock

The registry of what is on its way out lives on one page, and it is the page to check before you write new code [3]. Six features are currently Deprecated.

Roots, Sampling and Logging all went Deprecated in 2026-07-28 under SEP-2577, with an earliest removal of the first revision released on or after 2027-07-28 [3]. The documented migrations are unglamorous and mostly involve doing the thing directly: pass directories or files through tool parameters, resource URIs or server configuration instead of Roots; call an LLM provider’s API yourself instead of Sampling; log to stderr on stdio transports and use OpenTelemetry for observability instead of the Logging capability [3]. Dynamic Client Registration is deprecated on the same schedule, with Client ID Metadata Documents as the replacement [3]. The includeContext values "thisServer" and "allServers" were reclassified as Deprecated back to 2025-11-25 and follow Sampling out the door [3].

The one with a genuinely short fuse is the old HTTP+SSE transport, deprecated since 2025-03-26 and reclassified under the new policy with an earliest removal of three months after SEP-2596 reaches Final [3]. Streamable HTTP is the replacement. If you are still on HTTP+SSE, that is the item to move first.

Two details soften all of this. Earliest removal is when a feature becomes eligible for removal, not when it goes; the actual call is made by Core Maintainers during release preparation and features may sit Deprecated far longer than the minimum [2][3]. And removal from the spec does not oblige an SDK to drop the feature, which follows the SDK’s own revision-support policy [2]. Meanwhile Tier 1 SDKs must mark the deprecated API surface using the language’s native mechanism in their next release, and should emit a runtime warning when you exercise it [2]. In practice you will usually get told by your compiler before you get told by an outage.

The client you run against is behind the spec

Writing to the newest revision buys you nothing if the thing calling your server does not speak it. As of today, Anthropic’s MCP connector documentation points at specification version 2025-11-25, uses the beta header mcp-client-2025-11-20, and notes that the previous mcp-client-2025-04-04 is deprecated [7]. The connector requires the server to be publicly exposed over HTTP, accepting either Streamable HTTP or SSE, and states that local stdio servers cannot be connected directly [7]. It also says that of the whole MCP feature set, only tool calls are currently supported [7].

Read that last line carefully before you spend a weekend on resources or prompts for a server whose only consumer is that connector. The lag is not a defect; a client that ships a stable API cannot chase a spec revision the week it lands. But it does mean the version your server should target is the one your actual clients send, not the one at the top of the spec site. Support the range, answer UnsupportedProtocolVersionError properly, and let clients pick. On stdio, where there is no HTTP status code to drive fallback, a client that handles both the modern per-request _meta style and the legacy handshake SHOULD send server/discover first, so implementing that RPC correctly is what makes the old path work [8].

Authentication has the same shape. The connector expects you to run the OAuth flow yourself, obtain an access token before the call and refresh it as needed, passing it as authorization_token [7]. The July revision meanwhile hardened authorization on the spec side with RFC 9207 issuer validation and bound client credentials to the issuer that minted them, with no reuse across authorization servers [5].

A smaller tool surface is where the roadmap is heading anyway

The August 2026 roadmap names five priorities: agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience [4]. The one that touches an ordinary small server soonest sits under improved primitives, and it is progressive discovery: letting a server offer a small entry point and reveal more of its catalogue as the conversation narrows, rather than handing over everything up front [4].

You do not have to wait for it. The roadmap states the cost plainly: connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows [4]. The interim fix is the same shape as the eventual standard, which is fewer tools per server, split by purpose. A server scoped to one job is already close to what a discovery mechanism would select between, so the work composes rather than being thrown away. The July revision also added ttlMs and cacheScope to the responses from tools/list, prompts/list, resources/list and resources/read, so a well-behaved client can stop re-fetching a manifest that has not changed [5]. Set those.

Credentials belong behind an interface you own

The roadmap’s security priority is aimed at a gap you have probably worked around by hand. MCP authorization today is built around a person approving access in a browser, which does not fit a cloud agent that has its own identity and no human at a keyboard [4]. The planned fix is to finalise Demonstrating Proof of Possession and drive its adoption, plus an opinionated path for agent identity and delegation through Workload Identity Federation with standard token exchange [4]. It is roadmap work, not shipped protocol.

The practical move is not to guess at the eventual API. It is to make sure that when it lands, swapping to it is a backend change rather than an architecture change. If today you mint one long-lived key per integration, put credential issuance behind a small interface in your own code, so the shared-secret implementation can be replaced without touching every call site. The July revision already gave a preview of how this migrates: Dynamic Client Registration was formally deprecated in favour of Client ID Metadata Documents, and the old mechanism keeps working for backward compatibility until a future revision removes it [3][5]. That is the pattern the deprecation policy requires, since a named replacement must already be Active in the revision where the deprecation takes effect [2]. It means additive migrations rather than flag days.

SDK tier is a maintenance cost, not a badge

The tier your SDK sits in is a direct statement about how much of the upgrade work lands on you. Tier 1 requires a 100% conformance pass rate and new protocol features implemented before a new spec version ships, with issue triage within 2 business days and critical bug resolution within 7 days. Tier 2 requires 80% conformance, new features within 6 months, triage within a month and critical bugs within two weeks. Tier 3 commits to nothing [6]. Tiers are not permanent: an SDK whose conformance tests fail continuously for 4 weeks gets relegated, as does one whose issues sit unaddressed for two months [6].

For a small team, the six-month gap between Tier 1 and Tier 2 is the whole decision. It is the difference between your server picking up a revision when you bump a dependency and you hand-rolling the new behaviour for half a year. All four Tier 1 SDKs spoke 2026-07-28 on the day it shipped, those being TypeScript, Python, Go and C#, and the maintainers were candid that a migration cost remains, especially for developers who depended on session identifiers [5]. The scale explains the caution: Tier 1 SDKs see close to half a billion downloads a month, and the TypeScript and Python SDKs have each crossed a billion total downloads [5]. Experimental features and extensions such as Tasks and MCP Apps are not required for any tier, which is a fair warning that anything you build on Tasks today is running ahead of the guarantees [6].

What still goes wrong

The dates are floors, not plans. Earliest removal tells you the soonest a feature can disappear, and the roadmap sets direction for protocol work over the coming months without attaching a delivery date to any item on it [4]. So you can schedule the removals but not the arrivals, and building against a roadmap item before it ships is still speculation. The Tasks extension is the obvious trap: it moved out of the experimental core into the io.modelcontextprotocol/tasks extension in July [5] and the roadmap describes it as maturing so it can move into the specification [4], which is a polite way of saying it will change.

The floor also has an exception you should know about before you rely on it. Twelve months is the minimum for a feature deprecated under the current policy, but the window can be cut to ninety days where there is a published security advisory or in-the-wild exploitation with no in-place mitigation [2], and the entries carried over from before the policy existed run on their own clocks, which is why HTTP+SSE has three months rather than a year [3].

The other reliable failure is the mismatch this guide keeps circling. Your server can be perfectly conformant to 2026-07-28 and still be useless to the client someone actually points at it, because the connector supports tool calls only [7]. Nothing in the deprecation policy protects you from that, because it is not a spec problem. Test against the client, not the spec.

And none of this applies cleanly to the servers you did not write. If a third-party server you depend on is on a Tier 3 SDK, quietly using Sampling, and maintained by one person who has moved on, the twelve-month window is theirs to use and you will find out when it stops. The registry tells you what is coming for your own code. For everyone else’s, the only real check is whether the repository has had a commit since the last revision landed.