MCP 1.0 is here. What changes for the servers you already wrote

MCP 1.0 ratified. If you held off building MCP servers waiting for the spec to settle, that wait is over. If you already have servers running, this post is about what actually breaks and what is forward-compatible. For where the protocol was heading just before this, see my notes on the stateless spec release candidate.

Headline: most working servers continue working. There are three places the new spec genuinely requires changes, and one place you should change voluntarily. I will take them in the order they tend to bite during a real migration.

1. The enterprise auth profile

Pre-1.0, every server invented its own auth story or skipped it entirely. The 1.0 spec defines a standard auth profile built on OAuth 2.1 with PKCE and scope-based capabilities. Public hobby servers can keep ignoring auth. Anything you ship to a customer should adopt the standard profile before the next compliance audit, because "we rolled our own token check" is exactly the finding that turns a procurement review into a six-week delay. This is the same governance pressure I wrote about in Databricks Unity, the AI gateway, and MCP governance.

2. Remote-server registry behaviour

Servers can now register themselves with a discovery endpoint and announce capabilities at version-handshake time. If you hardcoded capabilities in your client config, those configs keep working, but you lose graceful degradation when a server changes. The practical upgrade is to stop pinning a static capability list in the client and let the handshake negotiate, so a server that gains or drops a tool does not silently break the client that assumed otherwise.

3. Streaming-response semantics

The streaming spec was loose pre-1.0 and servers improvised. The new spec defines stream-completion signals and partial-result schemas. If your server emits chunks, validate against the new schema. Silent truncation is the failure mode I have seen twice now: the client believes a stream completed, the user gets a half answer, and nothing logs an error because the old contract never defined what "done" looked like.

What to change voluntarily

Move tool descriptions from inline strings to externalised resources. The 1.0 ecosystem assumes you can hot-swap descriptions for prompt-engineering iteration, and as I argue in tool descriptions are prompts, description edits are some of the highest-leverage tuning you do. If yours are baked into the binary, every wording change is a redeploy, and you will outgrow that the first week you take selection accuracy seriously.

A migration checklist

1. 01
   Run your servers against a 1.0 client

   Most will pass untouched. Note any streaming handshakes that fail validation; those are your real breakages.
2. 02
   Gate customer servers on the auth profile

   Add OAuth 2.1 with PKCE and scoped capabilities before the next security review, not after it flags you.
3. 03
   Externalise descriptions

   Pull tool descriptions out of the binary so you can iterate without redeploying.

Net: 1.0 is a stabilisation release, not a rewrite. Treat the auth profile and streaming validation as the load-bearing changes and the rest as cleanup you do on your own schedule. If you are standardising MCP across a team, that rollout is something I help with in consulting and cover in training.