Summary

MCP’s foundational bet is that the AI application—not the model—should become the universal integration layer. David and Justin describe it as the “USB-C port of AI applications”: a common protocol through which IDEs, chat products, and agents can consume tools, context, and reusable prompts. The distinction matters strategically because MCP can span models and applications rather than depending on one model vendor’s function-calling interface.
The project began as a bottom-up solution to an M×N integration problem, not an Anthropic master plan. In July 2024, David was frustrated by copying work between Claude Desktop’s artifacts and IDEs that could manipulate local files; his developer-tooling reflex was to insert a protocol between many applications and many integrations. David and Justin spent several months on the “really unrewarding bits,” then launched November 25 after an internal hackathon demonstrated everything from memory across conversations to a 3D-printer controller.
MCP’s differentiation from generic API specifications lies in application-facing semantics and control. Tools are intended for model-initiated actions, resources expose addressable data that users or applications may select and index, and prompts provide user-initiated workflows or multistep message sequences. OpenAPI remains useful—and translators can bridge it into MCP—but it cannot naturally express this higher-level presentation model or MCP’s deliberately stateful, bidirectional interactions.
Tool calling probably represents “95% or more” of current integrations, leaving much of MCP’s designed surface economically underexploited. David wants clients to turn resources into full RAG indexes, servers to ship prompts that teach users how their tools work, and sampling clients that let servers request completions without embedding a model SDK or API key. His recurring frustration is that richer workflows are already protocol-compatible, but client support has not caught up.
Server creation is cheap enough to drive rapid supply, intense duplication, and new categories beyond API wrappers. A basic server can take roughly half an hour and 100–200 lines, while an LLM can often generate one after receiving an SDK or the relevant slice of the specification. The guests expect both conventional connectors and model-enhancing servers such as memory, sequential thinking, potential “best of three” reasoning, and recursive servers that consume other MCP servers.
Bidirectionality makes MCP a plausible substrate for agent composition, but its creators refuse to declare that agents belong inside the protocol. A server can ask its client for model sampling, operate as a client of other servers, and form recursive DAG-like systems; adding an internal model/tool loop could make such a component an agent. Justin’s restraint is the important signal: a “god box” that attempts everything may become “bad at everything too,” so agent support remains a live design question.
Remote deployment, authorization, and trust—not basic server construction—are the major adoption constraints. The proposed streamable HTTP transport preserves stateful interactions and server-initiated requests while supporting session resumption and horizontal scaling; the authorization draft uses OAuth 2.1 for remote servers. Meanwhile, multiple competing implementations are expected to converge through use, but registries cannot eliminate supply-chain attacks: “the next update can compromise a trusted package,” making inspection, reputation, and governance continuing ecosystem risks.

Deep dive

1. MCP extends AI applications rather than models

Justin’s crisp definition: Model Context Protocol helps AI applications “extend themselves” into an ecosystem of integrations. MCP uses client-server terminology, but its practical purpose is familiar—adding capabilities and external connections to products that host models.
David’s crucial boundary is that MCP targets “AI applications and not models themselves.” Calling it the “USB-C port of AI applications” captures the ambition: one universal, bidirectional connector between an application and a broad ecosystem of functionality.
The two-way property matters because an MCP server need not merely answer requests. It can expose tools and context, initiate requests back toward the application, or ask the client—which controls the model interaction—to perform a completion.

2. Product friction, not corporate strategy, created the protocol

David said MCP was “not part of a big strategy.” After joining Anthropic in 2024 to work on internal developer tooling, he wanted employees to dogfood the models more deeply but found each application trapped inside its own feature set.
His concrete frustration carried the design: Claude Desktop had artifacts but could not be extended, while an IDE could act on files but lacked artifacts. Constantly copying material between them led to the question, “What do we need?” Multiple applications multiplied by multiple integrations made the answer a protocol.
An abandoned internal LSP-related project supplied another ingredient. After letting those ideas “wait for like a few weeks,” David walked into a room and told Justin they should build a protocol; Justin immediately saw the potential and joined him.
Work began around July 2024 and culminated in the November 25 announcement. Justin remembered months of “laying the groundwork” before an internal hackathon added energy, including an MCP server capable of controlling a 3D printer.

3. LSP let the team stay boring where novelty added no value

Language Server Protocol supplied the core analogy: before LSP, every editor needed one-off integrations with every language. A common protocol separated robust language-server implementations from IDE work, allowing both sides of the M×N market to improve independently.
MCP borrowed JSON-RPC, bidirectionality, and LSP’s emphasis on how features manifest in applications. The team also studied criticisms of LSP, including its “very unique approach to JSON-RPC,” and deliberately declined to reproduce every design choice.
David’s protocol rule was to choose where to innovate and “be boring about the other parts.” Bytes on the wire were not the breakthrough; the valuable design work lay in selecting AI-native primitives and defining the interaction between applications and integrations.
Implementation was still substantial: the launch needed TypeScript and Python SDKs, Rust support for Zed, clients, servers, and reliable local subprocess communication over standard I/O. Zed’s open-source implementation appeared roughly a month and a half before launch under a different name, providing early public “alpha.”

4. Tools, resources, and prompts encode who controls an interaction

Justin said the primitives were designed from the application developer’s perspective: what distinct things might an IDE, chat product, or agent receive from an integration? From that lens, tool calling was “necessary but very insufficient.”
Tools place an action at the model’s discretion. Resources represent data or context, always identified by a URI, that an application might surface through an attachment menu, let a user select explicitly, or search agentically before adding relevant material to the context window.
Prompts are deliberately user-initiated messages or macros, analogous to slash commands or autocomplete. The discussion also highlighted multistep prompting rather than one static prompt, while the application decides exactly how that workflow appears.
David noted that tool calling probably accounts for “95% or more” of integrations, although Zed’s first implementation used prompts rather than tools. One useful pattern pulled a Sentry backtrace into context before the model ran, allowing the user—not an autonomous tool loop—to decide when it belonged.

5. Resources could support RAG and reusable application features

David’s unrealized resource example is a server exposing a document collection or database as addressable resources while the client builds a complete RAG index around it. The resource corpus may be far larger than a context window, making application-controlled retrieval more suitable than dumping everything into tools.
For databases, David separated the pieces cleanly: executing a SQL query can be a model-invoked tool, while table schemas naturally fit resources. A user could attach a particular schema, or an agentic application such as Claude Code could locate the appropriate one itself.
Zed offered another specific implementation: an MCP server populated its built-in prompt library with shared default prompts. Both sides agreed on URI and data formats, but the example showed how an existing application feature could be factored into an interoperable server.
David’s broader test was to inspect current applications for detachable features. An IDE’s attachment menu already behaves like a resource browser; MCP makes that capability open to external providers while preserving room for each application to differentiate its user experience.

6. LLM-native interfaces should return more data, not less

A host challenged the Google Maps reference server for selecting which API attributes reached the model, recreating the familiar SDK problem where a missing or newly added parameter becomes inaccessible. David accepted responsibility and said pull requests would be welcome.
MCP tool results deliberately need not conform to rigid structured schemas; they can be text, images, or messages sent directly to the model. David’s preference was to return “a whole jungle of data” and trust the LLM to find what matters, potentially passing underlying API results through almost intact.
David argued that developers still apply conventional API instincts to LLM interfaces and must relearn where abstraction helps. With models improving quickly, “just throw data at that thing that is really good at dealing with data” may outperform preformatting fields such as addresses, though servers should still normalize awkward encodings.

7. MCP complements OpenAPI by adding AI-specific semantics and state

David’s answer to “MCP versus OpenAPI” was that OpenAPI remains excellent for describing APIs but is too granular for rich model interactions. A REST specification does not convey whether something should appear as a user-selected resource, model-controlled tool, or reusable prompt.
David added statefulness as another dividing line. The team expects AI interactions to become more stateful as text expands into audio, video, and other modalities; today’s preference for stateless APIs may be “more a temporary point in time” than a permanent architecture.
Neither guest framed the protocols as mutually exclusive. Community members quickly built translators that expose an OpenAPI specification through MCP, and the reverse transformation is conceivable: use OpenAPI for conventional service description and MCP where an application needs richer AI-native behavior.

8. Server abundance begins with half-hour prototypes

David’s recommended starting point was intentionally unsophisticated: choose a language and SDK, build one personally useful tool, write a basic description, connect it through standard I/O, and watch the model act. A developer can reach that moment in “like half an hour” before investing in evaluations or refined prompts.
Justin estimated that an initial server often requires only 100–200 lines. His preferred accelerator is to place the SDK code in an LLM context and ask it to build the server; the result may need refinement, but it can “oneshot something that basically does what you want.”
Even without an SDK, David suggested supplying the relevant specification subset and an SDK in another language. Generating a production-grade SDK is different, but getting model tool calls working in Haskell or another unsupported language can be straightforward.
The guests expect both generated API adapters and genuinely new MCP-native experiences. Memory persists information across conversations; sequential thinking provides an explicit reasoning process; a hypothetical server might make three attempts at an answer and select the best.

9. Sampling and recursive servers open a path toward agents

Sampling lets a server request a completion from its client, which already owns the model loop. A summarization server therefore needs neither a model SDK nor an API key, and its behavior remains model-independent: it uses whichever model the user selected in Cursor or another client.
David described a richer component that is simultaneously an MCP server and an MCP client. It can serve an application while consuming other servers itself, preserving a recursive property that allows developers to assemble chains or DAG-like graphs of MCP components.
That pattern could power a morning workflow that reads and summarizes selected subreddits. The current constraint is a chicken-and-egg problem: server authors hesitate to build against sampling and other primitives until more clients implement them, while clients see little demand without compelling servers.
On whether such a recursive component is an agent, David distinguished a simple proxy from a component running its own sampled model-and-tool loop. Justin kept the protocol boundary unsettled: MCP might represent agents, connect agents, or remain narrowly focused on AI applications.

10. Tool scale depends more on semantic overlap than raw count

A host recalled an April 2024 example claiming support for 250 tools and asked whether MCP should favor one flat, wide tool set or nested servers. David said “hundreds” remained a reasonably safe estimate for Claude, while warning that no universal maximum exists.
Tool descriptions, names, and model capability determine the ceiling. Separate servers with distinct purposes may coexist comfortably, while GitHub and GitLab tools can confuse the model because their operations and language overlap heavily.
Applications can filter tools, use a smaller model to choose a relevant subset, or place a filtering proxy in front of other servers. An IDE may also let users enable different feature sets for different tasks instead of keeping every integration active.
Justin preserved MCP’s control hierarchy: “model controlled” means the model invokes a tool, not that the application surrenders authority. Clients and users remain in full control and may filter, transform, or enrich descriptions; David is separately considering server-declared logical groupings across tools, prompts, and resources.

11. Reference servers demonstrate capabilities that models may later absorb

The memory and sequential-thinking servers emerged partly from Anthropic’s prelaunch hackathon. They were not merely wrappers: MCP let coworkers prototype capabilities without becoming end-to-end experts or needing access to proprietary code.
The filesystem server was especially personal. It directly addressed the original frustration by allowing Claude to interact with and edit local project files; Justin used the capability while hacking on a game, and David called it a “spiritual inception point” for the protocol.
Sequential thinking has no known common lineage with Anthropic’s later “think tool.” David treated both as entries in a broader design space of reasoning aids, while Justin observed that MCP servers can fill capability gaps within days before similar behavior becomes native to a future model.

12. Remote operation forces compromises among state, security, and openness

The original SSE transport assumed a long-lived connection, preserving state but creating an operational burden at scale. After months of contentious discussion—not one viral tweet—the team proposed streamable HTTP: a server can begin with ordinary request-response HTTP, then add streaming and server-initiated requests.
Session resumption is the bridge between statefulness and practical infrastructure. If both sides support disconnecting and continuing later, servers can retain rich interactions while horizontally scaling and tolerating unreliable network connections.
The authorization draft for the next protocol revision focuses on user-to-server access through OAuth 2.1. David said users ideally should not have to paste API keys into commands; a server could even collect an API key inside an OAuth authorization page while preserving one interoperable client flow.
Governance follows the same conservative principle: “adding is easy, removing is hard” in protocol design. Anthropic wants genuine multi-company stewardship without “death by committee”; Microsoft, JetBrains, Spring AI, Pydantic, Block, Shopify, and others were already contributing implementations or specification work, while maintainers prioritize working prototypes over drive-by opinions.
David expects a bazaar of competing GitHub and likely Postgres servers rather than one mandated standard library, with usage eventually selecting winners. Vendor-built servers, such as one for Cloudflare Workers, may become de facto canonical, but the protocol itself should remain open.
Trust remains unsolved because download counts, reviews, or prior vetting cannot secure a later release. The discussion warned that “the next update can compromise a trusted package”; swyx urged people to use MCP Inspector to inspect actual traffic, while any registry inherits the supply-chain problems familiar from npm and PyPI.
The guests’ closing wish list exposed the unfinished product surface: David wants sampling clients and a model-independent digest of favorite Reddit threads or what happened in EVE Online over the last week; Justin wants clients implementing the full specification and an integration with the Godot engine so Claude could work with shader code, run, or play-test his game.

20VC Daily Deal: CoreWeave IPO, Scale at $25BN, Sequoia's 25x Wiz The Trump Tariff Dump