Back to Podcast Digest
AI Engineer··18m

The Future of MCP — David Soria Parra, Anthropic

TL;DR

  • MCP is moving from toy integrations to full agent infrastructure — David Soria Parra says 2025 was about experimenting with coding agents, but 2026 will be about production-grade agents for finance, marketing, and enterprise workflows that need real connectivity across SaaS apps and shared drives.

  • Anthropic sees MCP as one layer in a broader connectivity stack, not the only answer — his core framing is that strong agents will combine skills, MCP, and CLI/computer use depending on the job, instead of pretending one interface solves every integration problem.

  • Adoption has exploded to 110 million monthly downloads in roughly 18 months — he compares that pace to React, saying MCP reached that scale in about half the time, with usage now spread across OpenAI’s Agents SDK, Google’s ADK, LangChain, and thousands of downstream tools.

  • The biggest near-term fix is on the client side: stop dumping every tool into context — he pushes “progressive discovery,” where agents search and load tools only when needed, showing Claude Code sharply reducing tool-context usage after adopting this pattern.

  • He argues most MCP servers are still badly designed for agents — his blunt line is that converting REST APIs one-to-one into MCP servers is “a bit cringe,” and that builders should design around agent workflows, richer semantics, execution environments, tasks, elicitation, and MCP applications instead.

  • A major roadmap is coming in June for scale and enterprise adoption — he highlights Google’s proposed stateless transport, better async task support for agent-to-agent communication, cross-app access with identity providers like Okta and Google, server discovery via well-known URLs, and new TypeScript/Python SDKs.

The Breakdown

The opening demo: an agent ships its own interface

Soria Parra opens on what he thinks is the future of MCP: an application served directly over an MCP server, not as a plugin, SDK widget, or UI hallucinated client-side by the model. The pitch is simple and powerful — put that server in the cloud, ChatGPT, VS Code, or Cursor, and it should “just work,” because both sides share protocol-level semantics for UI, tools, and interaction.

From tiny spec to 110 million monthly downloads

He rewinds 18 months to when MCP was basically a spec doc, a few SDKs, and mostly local-only tools “written by Claude.” Since then, Anthropic added remote capabilities, centralized authorization, elicitation, tasks, and experimental MCP applications, while the ecosystem went wild building everything from WhatsApp and Blender servers to serious integrations like Linear, Slack, and Notion. His headline stat: MCP now sits at 110 million monthly downloads across OpenAI, Google ADK, LangChain, and countless hidden dependencies.

Why 2026 is about real knowledge-work agents

His timeline is sharp: 2024 was demos, 2025 was coding agents, and 2026 starts the era of general agents doing actual knowledge work. Coding agents had ideal conditions — local execution, verifiable outputs, a compiler, and a developer sitting there to fix things — but finance and marketing agents need something harder: connectivity to five SaaS tools, files, and enterprise systems.

Skills, CLI, and MCP each do different jobs

He explicitly rejects the idea that one tool solves connectivity. Skills capture reusable domain knowledge, CLI shines in local coding environments with sandboxes and pre-trained commands like Git, and MCP is the right fit when you need rich semantics, UI, long-running tasks, platform independence, authorization, governance, and enterprise-grade decoupling. His takeaway is that the best agents will use all of them together, seamlessly.

The client-side fix: progressive discovery instead of context bloat

He says people blame MCP for context bloat when the real issue is lazy client design: early systems just stuffed every tool into the prompt. The better pattern is “progressive discovery,” where the model gets a tool-search capability and only loads tools on demand; he points to Claude Code as an example where this led to a major drop in tool-context usage.

Let the model write code, not micromanage tool calls

The second big harness pattern is programmatic tool calling, or “code mode.” Instead of having the model serially call tool one, inspect output, then call tool two, he wants builders to give it an execution environment — V8 isolate, Deno-style runtime, Lua interpreter — and let it write code that composes tools directly. Structured output in MCP helps here by exposing return types, so the model can chain results cleanly and cut both latency and token use.

His blunt critique: stop wrapping REST APIs one-to-one

This is where he gets a little spicy: every new REST-to-MCP conversion tool is “a bit cringe” because it produces terrible agent experiences. Builders should design for how a human or agent actually wants to work, use server-side orchestration when appropriate, and lean into MCP-native primitives like tasks, elicitation, applications, and eventually skills over MCP.

The roadmap: stateless transport, enterprise login, discovery, and better SDKs

On the protocol side, he says streamable HTTP is too hard to scale for hyperscalers, so Google’s proposed stateless transport should make MCP servers feel more like standard cloud services; that work is expected in June. He also previews stronger async tasks for agent-to-agent communication, cross-app access so users log in once via Google or Okta, automatic server discovery through well-known URLs, and revamped SDKs — with a very human aside that FastMCP is “way better” than Anthropic’s Python SDK because, as he jokes, he wrote the old one.