MCP's Big Rewrite Ships Today. The Hard Part Was Never the Protocol.

What the stateless core actually changes

Under the old spec, a remote MCP server was a stateful thing. Sessions had to be pinned, gateways needed deep packet inspection to route correctly, and horizontal scaling meant session-store gymnastics. That friction acted as a natural rate limiter on how many tools organizations exposed to their agents. Standing up a new MCP server was enough work that teams thought twice.

The 2026-07-28 spec removes that friction almost entirely. A stateless server behind a round-robin load balancer, routing on an Mcp-Method header, with clients caching tool lists for whatever ttlMs the server permits - that's a deployment story any platform team can execute in an afternoon. The Extensions framework means capabilities like Tasks and Apps compose cleanly instead of bloating the core. The formal deprecation policy means enterprises can finally build on MCP without worrying the ground will shift underneath them.

So here's the second-order effect nobody's pricing in: tool catalogs are about to explode. When servers are cheap to deploy, stateless to scale, and safe to depend on, every internal API becomes an MCP server. Every SaaS vendor ships one. The agent that today chooses between 15 tools will be choosing between 150 by year's end. And tool selection - deciding which tool to call, with which arguments, in which order - was already the weakest link in most agentic systems when the catalog was small.

The protocol was never the bottleneck

It's worth being precise about what MCP solves and what it doesn't. MCP standardizes how an agent discovers and invokes tools: the wire format, the handshake, the capability negotiation. It says nothing about whether the agent invokes the right tool. That distinction gets lost in the excitement around protocol milestones.

I've watched teams celebrate getting their MCP integration working end-to-end, then quietly discover in production that their agent:

• Calls a search_orders tool when the user asked about invoices, because the tool descriptions overlap and the model pattern-matched on "find"
• Passes a date as MM/DD/YYYY to a tool whose schema says ISO 8601, and the server's lenient parsing silently accepts it - until it doesn't
• Retries a failed write operation that actually succeeded, because it misread a timeout as a failure (the new Tasks extension helps here, but only if the agent uses it correctly)
• Chains three tool calls where one would do, burning latency and tokens on a path a human operator would never take

None of these are protocol failures. Every one of these calls was spec-compliant JSON-RPC. They're judgment failures - and judgment doesn't come from the transport layer. It comes from training data.

Tool use is a learned behavior, and most models learned it on toy catalogs

Here's the uncomfortable part. The function-calling and tool-use capabilities in today's frontier models were largely trained and evaluated on small, clean tool sets - benchmarks like BFCL variants with a handful of well-differentiated functions, synthetic API environments, curated demonstrations. That data taught models the syntax of tool use extremely well. Modern models almost never emit malformed tool calls anymore.

What that data did not teach - because it barely exists at scale - is discrimination between near-duplicate tools in large catalogs. When your MCP client aggregates a dozen servers and presents the model with four different tools that can all "get customer data," each with subtly different scopes, freshness guarantees, and side effects, you're operating outside the distribution the model was trained on. The stateless spec makes this aggregation scenario the default, not the edge case.

The teams getting ahead of this are treating tool selection as a data problem with three concrete workstreams:

1. Trajectory correction data. You can't fix tool-selection errors you haven't captured. The highest-leverage dataset most teams aren't building is a corpus of corrected agent trajectories: real production runs where the agent chose wrong, annotated by someone who understands the domain well enough to say what the right call sequence was and why. This is painstaking work - a reviewer has to reconstruct intent, evaluate each step, and rewrite the trajectory - but it's the difference between an agent that repeats its mistakes and one that improves. It's also precisely the kind of work covered in SyncSoft.AI's reasoning and human feedback data practice, where tool-use validation and agent trajectory correction have gone from a niche request to one of the most common engagements over the past year. That shift in demand tells you where the industry's pain actually is.

2. Preference data over tool-call candidates. For fine-tuning or RLHF-style optimization, you need pairwise judgments: given this context, is calling tool_A(args_x) better than tool_B(args_y)? These judgments frequently require domain expertise - a labeler who doesn't understand your billing system can't rank tool calls against it. Generic crowdsourcing falls over here; you need annotators who can read an API schema and reason about side effects.

3. Evaluation sets that reflect your actual catalog. Public benchmarks won't tell you how your agent performs against your 150 tools with your naming conventions and your overlapping capabilities. You need held-out eval sets built from your own tool definitions: adversarial cases with near-duplicate tools, underspecified user requests, and multi-step workflows with a known-optimal path. Scoring these consistently at scale is its own discipline - rubric design, inter-annotator agreement, regression tracking across model versions - which is why model evaluation and QA has become a standing function in mature agent teams rather than a one-off pre-launch exercise.

Practical takeaways for the migration window

If you're planning your move to the 2026-07-28 spec, here's what I'd add to the standard migration checklist:

• Log tool-selection decisions, not just tool calls. Most telemetry captures what the agent called. Capture what it could have called - the full candidate set presented at each step. Without that, you can't distinguish "picked wrong from good options" from "never saw the right tool," and those have completely different fixes. Amazon's new CloudWatch Coding Agent Insights points in this direction for coding tools; you want the equivalent for every agent surface you run.

• Audit your tool descriptions like prompts, because they are. With cacheable tools/list responses, your descriptions will be consumed at massive scale. Near-duplicate descriptions are the number one cause of selection errors. Write them adversarially: if two descriptions could plausibly match the same request, the model will eventually confuse them.

• Budget for correction, not just construction. Teams routinely allocate engineering budget for building MCP servers and zero budget for the annotation work that makes agents use them well. A reasonable starting ratio we've seen work: for every ten tools you expose, budget review of a few hundred production trajectories in the first quarter. Front-load it - selection errors compound as users learn to distrust the agent.

• Treat the Tasks extension as an eval surface. Long-running operations are where silent failures hide. When work moves to Tasks, "did the agent correctly poll, resume, and reconcile task state" becomes a new failure class that didn't exist in your old evals. Build test cases for it before your users find them for you.

The unglamorous conclusion

Protocol standardization is how ecosystems scale, and the 2026-07-28 spec is MCP growing up: stateless, extensible, enterprise-ready. The maintainers deserve the credit they're getting. But every time the plumbing gets easier, the differentiator moves up the stack. In 2024 the hard part was connecting models to tools at all. In 2025 it was orchestration. As of today, connecting and orchestrating are largely solved problems - which means the gap between agents that demo well and agents that ship is now almost entirely a function of the data behind them: corrected trajectories, expert preference labels, and evaluation sets that look like production. The protocol is finished. The dataset isn't.

I work at SyncSoft.AI, where our teams in Vietnam build reasoning, human-feedback, and evaluation datasets for AI labs and product teams. If tool-use quality is on your roadmap this quarter, we're always happy to compare notes - feel free to reach out or just browse our case studies.