MCP in production, now that it grew up

I wrote my first MCP server in a weekend and spent the next month apologizing for it. Auth was a bearer token in an env var. State lived in a dict. It worked great right up until two clients connected.

The protocol grew up faster than my server did. The July 28 spec release lands with a stateless protocol core, a formal extensions framework, tasks for long-running work, and authorization hardening. Translation: the parts we all hand-rolled badly are becoming the protocol's problem instead of ours.

the auth story stopped being embarrassing

Enterprise-Managed Authorization went stable, with Anthropic, Microsoft and Okta already on it. Your identity provider decides which humans reach which servers. If you built a homegrown gateway that maps OAuth scopes to tool allowlists (hi), you get to delete code this quarter.

what I'd do differently today

• Build stateless from the start. The new core assumes it, and your future self wants horizontal scaling without sticky sessions.
• Long jobs go behind tasks, not behind a tool call that holds a connection open for nine minutes and dies at eight.
• Treat tool descriptions like API docs, because that is what the model reads. Vague descriptions produce vague agents.

migration notes from the trenches

If you are sitting on a v1-era server deciding what to do, the upgrade decomposes better than the changelog suggests. The stateless core is the only structural one: session state has to move out of process memory and into something a load balancer cannot destroy, which for my server meant a small Redis and a day of self-loathing about the dict. Tasks are additive; wrap your slowest tool in one and leave the fast ones alone. The auth hardening mostly deletes code if you had a gateway, and mostly writes code if your "auth" was that env-var bearer token (again, hi).

Do the stateless move first. Every other improvement assumes it, and it is the one you cannot retrofit under load. I tried the other order. The week the second replica went live remains classified.

One migration surprise worth flagging: clients vary wildly in how fast they adopt spec features. Ship a server that assumes every client speaks tasks and the older IDE integrations quietly fall back to timeouts. The spec version negotiation exists; actually branch on it, and keep the blocking path alive for a deprecation window even though it offends you.

the boring checklist that still applies

The 2026 roadmap coverage lists the usual enterprise asks: audit trails, SSO, gateway behavior. None of that is exotic. It is the same production hygiene your REST APIs already have, applied to a protocol your model talks to. The novelty wears off; the uptime requirements do not.

The audit line deserves one concrete tip: log the tool call arguments and the description version the model saw, together. When a tool misfires in production, the first question is "what did the model know", and if you cannot answer it you will re-litigate the incident from vibes. Span attributes make this nearly free, and future-you, sitting in the postmortem, sends regards.

If you are starting fresh instead of migrating, the order of operations is friendlier: stateless core and task support from the template, auth delegated to the identity provider from day one, and one deliberately boring tool shipped end to end before the ambitious ones. The teams that struggle with MCP servers are reliably the ones whose first tool was "do everything about orders". The teams that cruise shipped "look up one order" first and learned the operational shape of the thing while the stakes were a lookup.

My server from last year is still running, by the way. Nobody tell it.