Video summary

MCP Is Getting Its Biggest Update Ever (No One's Ready)

Main summary

Key takeaways

Technology

Technological summary (MCP “biggest update ever” — July 28)

  • MCP is undergoing a major rewrite (~16 months after launch): the release is described as a “biggest rewrite” and includes removing or deprecating core protocol mechanisms.
  • Intentional simplification (“make the protocol dumber”) is meant to prevent operational failures:
    • Handshake deleted
    • Session ID deleted
    • Three original features deprecated
    • The goal is to shift from a stateful design to a stateless one that works better in production.

What changes technically

1) From stateful sessions to stateless requests

Original MCP was stateful:

  • Each connection opened with a handshake
  • The server minted a session ID
  • Follow-up requests had to route to the exact machine holding that session in memory

Impact of the old model in production:

  • Required sticky sessions in load balancers
  • Forced complex infrastructure (e.g., Redis clusters for protocol plumbing)
  • Broke with serverless models because there was no persistent in-memory session behavior
  • Gateways had to inspect request bodies to route correctly

2) New transport: “wire with no memory”

New design is stateless:

  • Each request carries everything needed: protocol version, client identity, capabilities
  • Any MCP instance can serve any call

Operational benefits:

  • Enables round-robin load balancing
  • Supports auto-scaling
  • Works with serverless deployments

3) Multi-step work is handled via client-resident state blobs

Instead of server-side sessions, when mid-work state is required:

  • The server returns a sealed blob of its state
  • The client echoes it back on the next request
  • The replica that receives it continues from where it left off

This is compared to patterns like signed cookies (state round-trips through the client).

Risks / remaining hard problems

1) State management is pushed to explicit handles—handled by the LLM

The new state approach implies:

  • Servers/tools must mint explicit handles/IDs
  • Storage must remain alive

Key risks noted:

  • Language models can drop or mangle IDs (non-deterministic behavior)
  • If a server accepts a handle without verifying it belongs to the caller, it can become an authorization vulnerability (described as a “textbook authorization hole”).

2) Authorization remains inconsistent across clients

Even with sessions reduced/removed:

  • Authorization is described as the top recurring complaint.

Different clients implement MCP auth differently, for example:

  • Some require bring-your-own bearer token
  • Others run full OAuth flows themselves
  • Others reject machine-to-machine credential approaches

Compatibility varies across platforms, with examples including:

  • Anthropic API / Claude
  • ChatGPT
  • Google Cloud
  • VS Code (using older spec revisions)

3) OAuth standard dependency concerns

Concerns include:

  • MCP is described as mandating OAuth 2.1
  • However, OAuth 2.1 was still unfinished/draft at the standards-body level (years into development)

The July release adds authorization hardening via multiple proposals, but the core unification problem is still not fully solved.

Adoption / readiness concerns (developer readiness audit)

  • Claim: Internet declared MCP dead in March, with coding agents reportedly preferring plain CLI tools and treating protocol layering as overhead.
  • A “readiness problem” is highlighted:
    • Two weeks before release, an engineer probed reachable servers in the official MCP registry
    • Only 1 server was ready for the new spec (out of 4,356 that responded)

Compatibility / deprecation strategy

  • Old versions still negotiate during release transitions
  • Deprecated features get a 12-month floor (possibly longer), reducing abrupt breakage
  • The “scariest release” risk is mainly for servers currently running in production

Performance / context claims

  • The “context bloat” complaint is argued to be aimed at the wrong layer:
    • A prior Cloud Code issue consumed a large fraction of a tool-definition token window
    • The fix involved loading tools on demand in the client
    • Protocol itself allegedly wasn’t the cause

Ecosystem / traction and business reality

  • 110 million SDK downloads per month is cited as evidence of continued adoption (compared to React’s multi-year ramp)
  • Mentions of major enterprise deployments behind corporate firewalls:
    • Salesforce, Jira, Snowflake, HR systems
  • These are framed as high-value deployment channels that aren’t “trending,” but sustain usage.

Practical checklist for maintainers (July 28)

  • Don’t rely on old error-code numbers (example: string matching error code -32002 can change to -32602)
  • Ensure the proxy passes new MCP routing headers rather than stripping them
  • Use strict JSON content type

Main speakers / sources (as stated or implied)

  • MCP co-creator (quoted about transport and admitting earlier parts were wrong)
  • Unnamed engineer who performed the server readiness probe in the official MCP registry
  • Various client/ecosystem examples mentioned: Anthropic/Claude, ChatGPT, Google Cloud, VS Code, and enterprise integrations

Original video