Latent Space: The AI Engineer Podcast
Episode: The Creators of Model Context Protocol
Date: April 3, 2025
Guests: Justin Sparr Summers and David Soria Para (Anthropic)
Overview
This episode delves into the Model Context Protocol (MCP), the emergent standard for extending and integrating AI applications with the broader ecosystem of tools, plugins, and data sources. The hosts, Alessio and Zwicks, interview MCP co-creators Justin Sparr Summers and David Soria Para, uncovering the origin, technical design, ecosystem impact, future plans, and practical guidance for developers integrating MCP.
Key Points & Discussion Breakdown
1. What is MCP? [01:37]
-
Definition: MCP (Model Context Protocol) is a universal, bidirectional protocol for extending AI applications—not just models themselves—via plugins, tools, resources, and more.
-
Analogy: MCP is “kind of like the USB-C port of AI applications—meant to be this universal connector to a whole ecosystem of things.”
– Justin Sparr Summers [02:44] -
Clarification: Focus is on AI applications, not raw models. “A common misconception” is assuming MCP is "for models," but it's for "extending AI applications.”
– David Soria Para [02:21]
2. Origin Story and Motivation [03:31]
-
Frustration-Driven Invention: David faced pain integrating models with various developer tools at Anthropic—copying data between Cloud Desktop and IDEs.
– “As part of that, I quickly got frustrated... and out of that comes the idea—let's build some protocol.”
– David Soria Para [04:28] -
Timeline:
- July 2024: Sparked the idea
- November 25, 2024: Official announcement [06:23]
- Early hackathons validated potential, leading to internal excitement (e.g., controlling a 3D printer via MCP).
– Justin Sparr Summers [07:09]
3. Technical Foundations: Inspiration, Challenges, and Primitives [09:33]
-
LSP Inspiration: MCP draws heavily from LSP (Language Server Protocol)—both aim to solve the 'M x N' integration problem: multiple clients × multiple servers.
- "The key takeaway: the same principle and that same problem in the space of AI applications and extensions to AI applications."
– Justin Sparr Summers [09:33] - MCP retains LSP’s presentation focus: primitives are exposed so applications can choose different UI/UX affordances.
- "The key takeaway: the same principle and that same problem in the space of AI applications and extensions to AI applications."
-
Design Work & Language Support:
- Major effort in defining primitives and SDKs in TypeScript, Python, Rust.
- The choice of JSON RPC was pragmatic: “be boring in a lot of core pieces... innovation [is] on the primitives.”
– David Soria Para [12:16]
-
Learning from LSP’s Flaws:
- Incorporated lessons from LSP criticisms, e.g., its unique JSON-RPC usage.
- Emphasis on being ‘boring’ where possible, and focusing on flexible, app-driven experiences.
4. MCP Primitives: Tools, Resources, Prompts [15:57]
- Tools: Model-initiated function calls—think database queries, API access, etc.
- Resources: Contextual data or artifacts for the model/application to use. Can be surfaced as user-selectable attachments, not just for model discovery.
- “Resources are more flexible … you want to list a bunch of entities and then read any of them—that makes sense to model as resources.”
– Justin Sparr Summers [20:53]
- “Resources are more flexible … you want to list a bunch of entities and then read any of them—that makes sense to model as resources.”
- Prompts: Macro/insertion points for interactive user-driven prompts or slash-commands.
- First IDE implementation (Zed) was entirely prompt-driven—“a user-driven interaction that you as a user decide when to pull this in and don’t have to wait for the model.”
– David Soria Para [18:21]
- First IDE implementation (Zed) was entirely prompt-driven—“a user-driven interaction that you as a user decide when to pull this in and don’t have to wait for the model.”
- Design for Developer Differentiation:
- “Application developers don’t want to be commoditized … what unique things could they do to create the best user experience, even while connecting up to this big open ecosystem?”
– Justin Sparr Summers [17:53]
- “Application developers don’t want to be commoditized … what unique things could they do to create the best user experience, even while connecting up to this big open ecosystem?”
5. Tool vs. Resource Design Choices [20:25]
- Tools are for model-initiated actions. Resources offer more flexibility and can be explicitly previewed or selected by users/applications.
- Practical Tip: Use tools when you want the model to decide to take API actions; use resources for presenting lists or attaching data for dialogue context (schemas, docs, URIs, etc.).
6. Developer Guidance: Building MCP Servers [33:59]
- Getting Started: “Just start as simple as possible … pick the language you love, the SDK, and build the tool you want. In half an hour, you can get something usable.”
– David Soria Para [33:59] - Let LLMs Help Build Servers:
- "Once you have that, you can … drop the whole SDK code into an LLM’s context window and say… build me a server that does this.”
– Justin Sparr Summers [35:50]
- "Once you have that, you can … drop the whole SDK code into an LLM’s context window and say… build me a server that does this.”
- Reality Check: Most servers wrap existing APIs now, but both AI-generated and net-new experiences are foreseen as maturity increases.
7. Composability & Agentic Patterns [40:46]
- Recursive Composition: “An MCP server that serves something … but at the same time also is an MCP client … now you have a recursive property”
– David Soria Para [41:10] - Emergence of Agentic Behavior:
- “Is an MCP server that is also a client an agent?”
– Zwicks [43:40] - Team’s answer: You can build agents this way, but there’s a distinction between proxying and richer, agentic behavior (e.g., sampling loops, stepwise reasoning).
- “Is an MCP server that is also a client an agent?”
- Design Philosophy: Don’t overcomplicate the protocol—“You don’t want a protocol that tries to do everything under the sun.”
– Justin Sparr Summers [44:35]
8. Scaling, Limits, and Control [46:53]
- How many servers/tools is too many?
- No fixed number—depends on overlap, model, descriptions, and application.
- Hundreds may work, but application filtering or tool grouping may be needed.
- “Ultimately, the client application and by extension the user, should be in full control of absolutely everything that’s happening via MCP.”
– Justin Sparr Summers [49:27]
- Future Directions: Logical grouping of primitives could help orchestrate larger/complex systems.
9. Community, Ecosystem, Governance [51:15]
-
Standard Library?: No prescriptive canonical servers—ecosystem will converge on popular implementations over time (e.g., “the best and most interesting option wins”).
-
Trust and Vetting:
- Challenge is akin to npm/PyPI: supply chain risks, package trust, etc.
- “Trying to think about how to endow reputation … how can that be reflected in this open model?”
– Justin Sparr Summers [52:24]
-
Open Governance Balancing Act:
- Anthropic are current stewards, but the protocol is already multi-company and open to maintainers outside Anthropic (Pydantic, Microsoft, JetBrains, etc.).
- “We want this to be a community project … but it’s balancing that against avoiding death by committee.”
– Justin Sparr Summers [76:05]
-
Future Foundation?: Possibly—once pace stabilizes, but currently focused on agility and not standard body bureaucracy.
10. Technical Roadmap: Statelessness, Auth, Scopes [62:01]
-
Transport Evolution:
- Moved from stateful (SSE/long-lived connections) to flexible HTTP streaming (“streamable HTTP transport”) for easier deployment and scaling.
- Supports both persistence and horizontal scaling.
-
Authentication/Authorization:
- OAuth2 is being integrated; local vs. remote server authentication varies.
- “Trying to solve a very practical problem. It tries to be very minimal in what it does... go from there based on user pain points.”
– David Soria Para [64:27]
-
Scopes and Permissions:
- Open to supporting granular access controls (“scopes”) if concrete needs and use cases appear.
- Cautious to avoid protocol bloat: “adding is easy, removing is hard.”
11. Notable Quotes & Memorable Moments
-
On MCP’s Design Philosophy:
“You kind of want to pick the areas you want to innovate in, but you kind of want to be boring about the other parts…pattern matching LSP…allows you to be boring in a lot of the core pieces.”
– David Soria Para [12:16] -
On Ecosystem Growth:
“Ecosystem will converge to a set of very widely used [MCP servers]…let the best and most interesting option win.”
– David Soria Para [51:15] -
On Protocol Overreach:
“You don’t want a protocol that tries to do absolutely everything under the sun because then it’ll be bad at everything too.”
– Justin Sparr Summers [44:35] -
On Community Input:
“It’s merit driven…if you have done work and you showcase this with practical examples and work in SDKs, you have a good chance that it gets in. If you’re just there to have an opinion, you’re very likely just being ignored, to be frank…”
– David Soria Para [70:08]
12. Future MCP Wish List [77:51]
- Sampling Clients: “I want more sampling clients. That’s all I want.”
– David Soria Para [77:54] - Breadth of Spec Support: “More clients that support the full breadth of the spec would be amazing”
– Justin Sparr Summers [78:28] - Game Integration: “Would really love to have an MCP client/server with Godot engine…Claude run and playtest my game…”
– Justin Sparr Summers [79:13]
13. Getting Involved
- Spec discussion & contributions: MCP spec repo’s discussion page.
- Advice: Hands-on contributors are prioritized over passive commenters; practical PRs, SDK work, and prototypes welcomed.
Timestamps of Major Segments
- [01:37] — What is MCP?
- [03:31] — The Origin Story
- [09:33] — LSP Influence and Technical Choices
- [15:57] — MCP Primitives: Tools, Resources, Prompts
- [20:25] — Tool vs. Resource
- [33:59] — Building MCP Servers: Where to Start
- [40:46] — Composability & Agents
- [46:53] — Scaling, Nesting, and Control
- [51:15] — Ecosystem, Trust, and Standardization
- [62:01] — Stateless Protocols, Transport, and Roadmap
- [70:08] — Community Voice, Governance
- [77:51] — MCP Server and Client Wish List
Tone and Language
The episode maintains a thoughtful, occasionally technical, yet playful tone. Speakers balance philosophical protocol design debates with grounded, developer-centric advice. Community, open ecosystem innovation, and pragmatism in protocol design emerge as recurring themes.
Useful Links
This summary is intended to provide a comprehensive yet accessible overview for AI engineers, developers, and open source contributors interested in MCP’s rapidly-growing ecosystem and real-world usage.
