MCP Co-Creator: Agents Need Connectivity, Not Stronger Models

At a tech conference in Japan, David Soria Parra — co-creator of MCP (Model Context Protocol) and engineer at Anthropic — offered a take that cuts against the industry's prevailing narrative: what determines the future of agent systems isn't further improvements in model capability, but connectivity — and the open standards built around it.

This view is grounded in his systematic analysis of how model capabilities are evolving and how agents are actually being deployed. Here's the core thread of his talk.

Model Capabilities Are Growing at a Compounding Rate

David opened by referencing a chart showing how model capabilities have changed over time. He noted that models from a year ago could only handle tasks that take humans a few hours — and even then, they required constant human steering and correction. Today, models are rapidly approaching the point where they can independently complete tasks that would take humans weeks — with models finishing in hours what used to take people weeks.

He emphasized that these capabilities are growing in a compounding fashion, rising along what looks like a straight line upward. At this trajectory, models capable of compressing months of human work into hours are just months away. This framing sets up his central argument: once the model itself is strong enough, the bottleneck shifts elsewhere.

From Demo to Coding Agent: Why Coding Was the First Production Use Case

David traced the evolution of agent products. When MCP launched in 2024, tool calling was still a brand-new concept for models — it's only been about two years. During that phase, most of what people built were "cool-looking demos" that weren't production-ready, because models couldn't yet handle sufficiently long tasks and tool-calling reliability was inconsistent.

2025 belongs squarely to coding agents. His explanation is worth noting: why were coding agents the first to reach production? Because programming has a unique property — you can use automated systems like unit tests and compilers to provide real-time correction and guidance to models. Even when models could only reliably work for a few hours at a time, developers could use compilers and similar tools to keep them on track.

As model capabilities have improved dramatically, people can increasingly rely on models to "just get it right" without constant supervision.

2026: The Inflection Point Where Knowledge Work Needs Connectivity

David predicts this will be the year agent systems first move beyond coding at scale, entering production-level applications in general knowledge work, scientific discovery, mathematics, and more.

But he cautions that there's a fundamental difference between apps for developers and apps for general knowledge workers. Knowledge workers — financial advisors, accountants — really only need one thing: connectivity, meaning the model's ability to interact with the systems they care about. These people work daily with Microsoft 365, Google Workspace, and a vast array of internal and SaaS systems.

This is where his core argument crystallizes: as model capabilities compound and approach a ceiling, the real question shifts from "how strong is the model" to "how do we connect it."

MCP's Explosive Growth in Numbers

To back up this trend, David shared ecosystem data:

• Tool calls made through MCP on Anthropic's Claude AI have now surpassed approximately 1 billion;
• MCP SDK monthly downloads exceed 500 million;
• Companies like Vercel and Linear consider MCP Server the fastest-growing part of their product lines;
• Across the industry — from Anthropic to competitor OpenAI — MCP tool call volumes are "off the charts."

This "small project" from two years ago is becoming core infrastructure for the industry. And as the industry grows more dependent on MCP, the protocol itself must keep evolving.

MCP's Evolution: Toward True Statelessness

David walked through MCP's iteration history: after launching in 2024, it added remote connectivity (currently the most widely used version), authorization mechanisms, and the concept of applications introduced last year.

The most significant change this year is making MCP truly stateless. He revealed this was the result of collaborative discussions among industry leaders including Microsoft, Google, Anthropic, and OpenAI — with the goal of supporting agent-specific interaction patterns while maintaining statelessness, since some of those patterns are beyond what plain HTTP can handle.

One pattern mentioned is called "short MRTR" (multi-round trip request). Alongside the stateless core, MCP is also introducing cacheable results and beginning to deprecate parts that are no longer needed.

---

Stateless architecture means the server stores no client session information between requests — each request is fully self-describing. By contrast, stateful architectures require the server to maintain session state, which creates complex synchronization challenges when scaling horizontally. Early versions of MCP relied on persistent connections (such as SSE) to maintain sessions, limiting flexibility for large-scale deployments. By going stateless, MCP Servers can be load-balanced and horizontally scaled like ordinary HTTP APIs, dramatically reducing operational complexity for enterprise deployments.

Cacheable results is a complementary mechanism for stateless architecture — for tool calls that produce deterministic outputs given the same input, clients or intermediate layers can cache results to reduce redundant computation and network round trips. Short MRTR (multi-round trip request) is a complementary solution for scenarios that are "stateless but require multiple interactions": it allows a limited number of round trips within a single logical operation, preserving the architectural benefits of statelessness while supporting interactive agent workflows such as confirmation and authorization steps.

---

The Next 12 Months: Tasks, Skills, and Identity Authorization

David outlined three major focus areas for the MCP community over the next roughly 12 months:

First: Agentic Messaging. The goal is to make MCP the default protocol for agent messaging and orchestration. This introduces the concept of MCP Tasks, which support long-running operations — you can invoke an MCP Server as an Agent and have it proactively return results when it's ready. Unlike ordinary tool calls, MCP Tasks can handle work that takes minutes, hours, weeks, or even months.

Second: Expanding Semantic Expressiveness. David sees limitations in pure tool calling, which is why the extension he's personally most excited about is Skills over MCP — delivering agent skills via MCP Server. This goes beyond bundling a set of tools together; it helps others better understand what your MCP Server offers, and enables enterprises to build central skill registries in ways that were previously impossible, because the distribution channel becomes MCP itself rather than a complex marketplace system.

Third: Authorization & Identity.

David acknowledged this may not be the most technically interesting area, but it's one of the most conceptually important for agent systems. As agents increasingly take on tasks autonomously, identifying them, clarifying who they're acting on behalf of, and establishing observability and policy mechanisms becomes critical. He noted this is also where the MCP community is currently investing the most effort.

---

MCP Tasks differ fundamentally from traditional synchronous tool calls. Ordinary tool calls are like a function call — the caller waits for a return value, and the whole process completes in milliseconds to seconds. MCP Tasks are more like an async job queue: the caller submits a task and can disconnect, while the MCP Server (now acting as an autonomous agent) continues executing in the background and pushes results when finished. This pattern is especially valuable for long-running workflows that involve calling external APIs, executing complex reasoning chains, or waiting for human approval.

Skills over MCP attempts to solve the semantic poverty of current "tool discovery" — existing MCP Servers can only expose a list of tools and parameter descriptions, but cannot convey higher-order semantics like "what business capability does this set of tools collectively deliver." Through Skills, an MCP Server can declare capabilities such as "financial reconciliation" or "code review," enabling orchestration layers to route tasks more accurately and allowing enterprises to govern their AI capability assets at the skill level rather than the tool level.

---

The Open Community Is MCP's Core

David closed by emphasizing that the most important part of MCP has always been the community itself. He called for three modes of participation: building and sharing high-quality, thoroughly evaluated MCP Servers; exchanging enterprise challenges and needs at conferences like this one (he specifically mentioned wanting to understand the unique characteristics of the Japanese market); and directly joining this always-open-source project by contributing perspectives from different regions through Discord or working groups.

His closing point was clear: MCP's goal is to become the default open standard for agent interaction — and that requires participation from a global community.

Closing Thoughts

David's talk offers a valuable shift in perspective: in an industry fixated on "how powerful is the next model," he redirects attention to the more engineering-grounded and practically relevant question of "how does the model reach real-world systems." When model capability growth plateaus or becomes commoditized, connectivity and open standards may well become the true deciding factor in whether agent systems scale successfully.