What MCP is, and what to do when it changes under you

At some point you clicked a button that said “Connect”. Your calendar, your docs, your repo, your invoicing tool. It asked for permission, you gave it, and the assistant could suddenly see your work. Then one morning it cannot. A tool that ran for six months returns nothing, or the assistant claims the connector does not exist, and nothing on the screen tells you whether the fault is your account, your vendor, or the standard underneath all of it.

The standard underneath is MCP, and in July 2026 it changed shape. The release post for the 2026-07-28 revision describes MCP “transforming from a bidirectional stateful protocol into a request/response stateless protocol” [2]. The useful thing to take from that is not the rewrite. It is that the same revision arrived with a published clock, so for the first time you can tell how much notice you get before something you depend on is taken away [4][5]. This guide is for the person on the clicking end, and for the small team that runs one server somebody else wrote. If you maintain an MCP server other people depend on, this is too shallow for you, and the changelog and the security page are the actual reading [3][6].

MCP is a plug shape, not a product

MCP is described by its own maintainers as “an open-source standard for connecting AI applications to external systems”, and the analogy they use is a USB-C port: one connection shape, so any tool that speaks it can be plugged into any assistant that speaks it [1]. That is the whole idea. Agents reaching your Google Calendar and Notion, and Claude Code building a web app from a Figma design, are the examples the documentation itself gives [1]. Claude, ChatGPT, Visual Studio Code and Cursor all support it [1].

The scale is worth knowing because it explains why the standard moves at all. Across its Tier 1 SDKs the maintainers report “close to half-a-billion downloads a month”, with “both TypeScript and Python SDKs crossing the 1 billion total downloads threshold” [2]. A standard with that much deployed code behind it accumulates real operational complaints, and eventually acts on them.

What matters for you is what you are actually buying. You do not buy MCP. You pay a vendor for a client, and that client speaks a version of a standard that a separate group of maintainers revises on its own schedule. Three parties have to agree for your connector to keep working: the standard, the client you pay for, and whoever runs the server on the other end. You control none of them.

The 2026 revision removed the connection itself

Until July 2026, an MCP client and server opened something like a phone call. They ran an initialize handshake, the server minted a session, and every later request carried an Mcp-Session-Id header proving it belonged to that call. The 2026-07-28 revision removed protocol-level sessions and that header from the Streamable HTTP transport, and retired the handshake with them. Every request now carries its own protocol version and client capabilities, and a version mismatch is answered request by request [3].

The motive was operational. As the release post puts it, “Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage” [2]. Nothing has to remember you between requests, so a server can be scaled, restarted and redeployed without anyone noticing.

One removal in the same release is visible from your side of the screen. Stream resumability is gone: a broken response stream loses the in-flight request, and the client must re-issue it as a new request with a new request ID [3]. A long tool call that dies halfway through no longer picks up where it stopped. It starts again from nothing.

Other features were marked deprecated in that revision rather than removed. Roots, Sampling and Logging were deprecated together, the OAuth 2.0 Dynamic Client Registration Protocol was deprecated in favour of Client ID Metadata Documents, and the older HTTP+SSE transport, described as deprecated since the 2025-03-26 revision, was reclassified as Deprecated under a new lifecycle policy [3][5]. Deprecated features “remain fully functional during the deprecation window” [3] and stay part of the specification while being scheduled for removal [5]. That distinction is the part worth internalising, because it is where your notice period lives.

Twelve months is the number you can plan around

MCP versions are dates, and the date means something specific: it indicates “the last date backwards incompatible changes were made”. The version deliberately does not move when a change keeps compatibility [4]. So a version string like 2026-07-28 is not a release number, it is a warning label.

The rule attached to it is the genuinely useful fact in this whole topic. A deprecated feature remains in the specification “for at least twelve months” before it becomes eligible for removal, and the policy’s expedited-removal exception still has to leave at least ninety days [4]. That floor is published, not implied.

You can also see the dates. The deprecated features registry lists Roots, Sampling, Logging and Dynamic Client Registration with an earliest removal of “First revision released on or after 2027-07-28” [5]. Earliest removal only marks when a feature becomes eligible: the registry says the actual removal is “a Core Maintainer decision taken during release preparation and may happen later” [5]. In practice a page you can check in two minutes tells you what is on the way out and roughly when, which is more than most software you depend on offers.

Your client is behind the spec, and that is usually fine

The specification moving does not mean your tools moved. OpenAI’s connectors guide references the “2025-03-26 version of the MCP spec” and says the API works with remote servers supporting “either the Streamable HTTP or the HTTP/SSE transport protocols” [8], while HTTP+SSE is formally Deprecated in the current revision [3][5]. That is not a criticism of anyone. It is how standards and products relate: the standard is a target, and clients arrive at it in their own time.

The protocol accommodates the lag on purpose. Every request declares the protocol version it is using, the server accepts or rejects each request independently, and clients and servers may support multiple protocol versions simultaneously [4]. Nothing snaps at midnight on release day.

The practical consequence is that the date to watch is your client’s release notes, not the specification’s. When a connector breaks, work down the three things a person actually changed: the operator of the server, the authorisation you granted it, and the vendor that ships your client. The specification version is the last place to look, not the first.

Nobody in the chain is vouching for the server you connect

Read what the vendors actually say. Anthropic’s own support documentation states that “Custom connectors allow you to connect Claude to arbitrary services that have not been verified by Anthropic”, warns that “Malicious MCP servers may include hidden instructions that try to make Claude perform unintended actions”, and tells you to “Only connect Claude to servers built and hosted by organizations and applications you trust” [7]. OpenAI’s guide is just as direct, warning that “A malicious server can exfiltrate sensitive data from anything that enters the model’s context”, which is why “OpenAI will request your approval before any data is shared with a connector or remote MCP server” by default rather than as an option you switch on [8].

Two things follow. First, the model’s context is a shared room. Your exposure is not set by how sensitive the newest connector is, because the sentence above puts everything that enters the model’s context within reach of a bad server in that conversation [8]. It is set by the most sensitive thing that lands in the session while the connector is attached.

Second, scope is the only control you actually operate. Anthropic’s advice is to review during authorisation what permissions the server is requesting, “limit these scopes when possible and deny access if requested permissions seem unnecessary” [7]. That consent screen is the one moment where you decide how much damage a bad server can do, and it is easy to click through in two seconds.

The specification’s own security guidance is written for implementers but tells you what the failure modes are. Servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server”, which is the rule that stops one service’s credential being replayed at another [6]. Local servers “are binaries that are downloaded and executed on the same machine as the MCP client” and run with the same privileges as that client, which is why a one-click local install has to show you the exact command first, without truncation [6]. And because the protocol no longer has sessions, servers that need to remember something between calls mint a handle and take it back as an ordinary tool argument, so the spec has to say out loud that servers “MUST NOT treat possession of a state handle as authentication” [6].

Keep an inventory of what you have plugged in

Anthropic allows custom connectors on the Free, Pro, Max, Team and Enterprise plans, and limits free users to one [7]. The page sets no limit for the paid plans, which is the actual hazard. Connectors accumulate quietly, and nothing prompts you to review them. OpenAI states there are “no additional fees involved per tool call”, so the running cost is tokens, paid when tool definitions are imported and when calls are made [8]. That cost is small per connector and invisible in aggregate, which is another reason nobody prunes.

Write down five things for each server you have connected: what it is, who operates it, what it can read, which scopes you granted, and what stops working if it disappears tomorrow. That last column is the one that matters. A connector nobody would miss can be removed today at zero cost. A connector holding up a workflow you run every Monday deserves a note about what you would do the week it stops.

What still goes wrong

The deprecation clock covers features of the specification, and nothing else [5]. It says nothing about whether your vendor keeps offering a connector, whether a server operator stays in business, or whether the small tool you rely on gets acquired and switched off. The registry is a genuine improvement to one of your three risks and silent on the other two, and the other two are the ones with no published notice period at all.

Prompt injection is not solved by any of this. Anthropic says Claude “has built-in protections that attempt to block these attacks”, and in the same sentence tells you to pay attention to tool inputs and outputs and to connect only to trusted servers [7]. Trust in an operator is a judgement you cannot audit from outside, and hidden instructions are exactly the kind of thing that does not announce itself. The specification’s security document is aimed at developers implementing MCP authorization flows, server operators and security professionals [6], not at you, and its contents are mitigations to build rather than controls to switch on. Your available defences are narrow scopes, few connectors, and paying attention to what is in the session at the same time.

Finally, the statelessness that motivated the rewrite is a benefit you will never see and a cost you occasionally will. Servers scale better and restarts stop mattering [2]. In exchange, a broken stream loses the in-flight request rather than resuming it [3]. If a long job fails halfway on a flaky connection, running it again from the start is the expected behaviour now, not a bug worth reporting.