The Future of MCP — David Soria Parra, Anthropic

An MCP application allows a server to deliver an interface alongside tools. Rather than hard-coding that interface into a particular product, generating it on the client, or distributing it through a plug-in or SDK, the server provides something that compatible clients can understand and render. David Soria Parra identifies Claude, ChatGPT, VS Code, and Cursor as examples of environments in which such a server can work. 0:15

The important architectural ingredient is shared semantics: both client and server need to understand that an interface exists, how it should be presented, and how interaction should proceed. Combining an application with tools also creates two complementary modes of access: a person can use the interface directly, while a model can operate through the associated tools. 0:15

Soria Parra describes MCP as having evolved from a local-only specification with a few SDKs and basic tools into a protocol with remote operation, centralized authorization, elicitation, tasks, and experimental applications. He reports approximately 110 million monthly downloads, attributing that reach not only to direct usage but also to dependencies across OpenAI's agents SDK, Google's ADK, LangChain, and other frameworks. Public examples include integrations with WhatsApp, Blender, Linear, Slack, and Notion, although he says most servers connect private company systems to agents behind closed doors. 1:34

Coding agents benefit from unusually favorable operating conditions: they often work locally, can verify results with a compiler, and have a developer nearby to intervene when something breaks. Soria Parra argues that broader knowledge-work agents face a different problem. A financial analyst or marketing professional may need an agent that can connect several SaaS applications and a shared drive, making connectivity central to the product rather than incidental to it. 3:59

His proposed connectivity stack has three broad categories: Skills for reusable domain knowledge, MCP for protocol-level interoperability and richer semantics, and CLIs or Computer Use when those approaches fit the environment. No single method should be treated as a universal answer; the appropriate choice depends on the agent, available execution environment, and task. 5:06

CLIs are especially useful for local agents because they compose naturally in bash, expose capabilities a model can discover, and align with familiar tools such as GitHub and Git. Their strengths depend on assumptions that do not always hold, including access to a sandbox and code execution. MCP becomes more compelling when an application needs platform independence, interfaces for long-running work, resources, authorization, governance, policies, or richer features such as MCP applications and Skills over MCP. 6:02

Soria Parra argues that excessive context usage should not automatically be blamed on MCP itself. A protocol transfers information between systems; the client or agent harness decides how that information enters the model's context. Early implementations often loaded every available tool immediately, creating unnecessarily large context windows as the number of integrations grew. 7:12

The proposed alternative is Progressive Discovery. Rather than placing every tool definition in context at startup, the client gives the model a mechanism such as Tool Search and loads individual tools only when they become relevant. This effectively replaces an always-present catalog with an on-demand discovery process driven by the model's current needs. 8:20

Soria Parra says this pattern is available in Anthropic's product and API, can also be used through competing APIs, and can be implemented directly by application builders. He describes an example showing a substantial reduction in tool-context usage after the pattern was introduced, but the transcript does not provide a numerical measurement. The broader lesson is that scalable connectivity depends on deliberate client design, not merely on attaching more servers. 7:12

A second client-side pattern is Programmatic tool calling, also described as Code Mode. When a model calls one tool, reads its response, calls another, and repeats the cycle, inference becomes part of every orchestration step. Soria Parra argues that this adds latency and can be less effective than having the model write a script that coordinates the necessary operations directly. 9:36

One implementation provides an execution environment such as a V8 Isolate, Monty, or a Lua interpreter, allowing generated code to compose tools, filter results, and continue processing without repeatedly routing every intermediate decision through the model. MCP's Structured Output can describe return values and provide type information that makes composition easier. When that information is unavailable, Soria Parra suggests using a cheaper model to extract output into an expected structure. 10:33

These ideas also change how servers should be built. Soria Parra discourages mechanically converting REST endpoints one-for-one into MCP tools; instead, server authors should design capabilities around how an agent or person would actually accomplish a task. Programmatic execution can exist on the client or the server, with the Cloudflare MCP server offered as an example of providing an execution environment rather than only isolated tools. He associates this approach with lower token usage, reduced latency, and stronger composition, while also encouraging server authors to use applications, Skills, Task, and Elicitations where those semantics genuinely help. 11:45

Soria Parra identifies several protocol-level limitations that still need work. He says the current HTTP streaming approach is difficult to scale for large hyperscalers and describes a Google-backed proposal for a Stateless Transport Protocol that would make MCP servers behave more like familiar stateless REST services deployable on Cloud Runs or Kubernetes. He also describes asynchronous tasks as an experimental foundation for agent-to-agent communication, noting that few clients currently support the capability and that broader client adoption remains necessary. 13:49

The SDK and enterprise roadmap includes TypeScript SDK version 2 and Python SDK version 2, incorporating lessons from the previous year. Soria Parra specifically credits FastMCP as a stronger Python SDK experience than the one his team shipped. He also outlines Cross App Access, intended to let users authenticate through a company identity provider such as Google or Okta and then access MCP servers without repeatedly logging in. 14:52

A proposed Server Discovery mechanism would define how agents, browsers, and crawlers find MCP servers through well-known URLs instead of relying solely on ordinary website parsing. Extensions introduce an explicit compatibility tradeoff: not every client can support every capability, and web-rendered MCP applications are poorly suited to CLI interfaces. Another planned extension, Skills over MCP, would let server authors distribute and continuously update the domain knowledge needed to use complex servers. Soria Parra notes that rudimentary versions can already be approximated with a tool that loads Skills, even before shared protocol semantics are finalized. 14:52

The overall direction is therefore not to replace CLIs, Computer Use, or Skills with MCP, but to make these methods interoperable within a more capable agent stack. Soria Parra presents the protocol's evolution as an open-community effort that depends on continued feedback, while acknowledging that current agents, harnesses, client support, and protocol details still require substantial improvement. 7:12