The July MCP revision went stateless, with OAuth 2.0 and OpenID Connect, so servers can run serverless. That sounds like a boring spec note. It is not.
Why stateless matters
Stateless plus standard auth is the difference between a protocol you demo on a laptop and one you can put behind a load balancer at work.
When a server keeps per-session state in memory, every request from a client has to reach the same instance. That fights against how most production infrastructure works: load balancers spread traffic, serverless functions come and go, and instances are replaced during deploys. A stateless server can handle any request on any instance.
Why standard auth matters
OAuth 2.0 and OpenID Connect are what identity infrastructure already speaks. Using them means an MCP server can plug into the same auth setup as everything else, instead of needing its own.
Removing the excuse
Most integration standards die because nobody could deploy them the way their infrastructure already works. This one just removed that excuse.
Takeaways
- The July MCP revision is stateless and uses OAuth 2.0 and OpenID Connect.
- Stateless servers can scale horizontally and run serverless.
- Standard auth lets MCP fit into existing identity infrastructure.
- Deployability is what decides whether an integration standard survives.
Building something like this?
I'm Ahmed Mamdouh, a senior full-stack & AI engineer. I reply within one working day.
The systems I am proud of are built from boring parts
The best systems use boring parts like Postgres, a queue and a well-defined cache; the real engineering is in the failure handling.
What actually breaks when AI agents go to production
Production agents fail on state, partial failure and knowing when to stop, which are distributed systems problems, not prompt problems.
Claude output is now watermarked
Claude output now carries watermarks and signed provenance by default; tell your users, and never treat a missing watermark as proof.