MCP Creator on the Origins, Architectural Advantages, and Future of MCP
TechFlow Selected TechFlow Selected
MCP Creator on the Origins, Architectural Advantages, and Future of MCP
The most worthwhile read about MCP.
Navigating Web3 tides with focused insightsAuthor: FounderPark
The MCP protocol, released last year by Anthropic, has suddenly become the hottest protocol in the AI field this year due to the surge of interest in Manus and Agents. Major players like OpenAI, Microsoft, and Google have all jumped on board, with domestic companies such as Alibaba Cloud's Bailian and Tencent Cloud quickly following suit by launching rapid development platforms.
However, controversies abound. Many question whether MCP is significantly different from APIs, criticize Anthropic engineers for lacking deep expertise in internet protocols, and raise concerns about security issues stemming from the protocol’s simplicity.
Who better than the creators of MCP to answer these questions?
In a recent episode of the Latent Space podcast, they invited Justin Spahr-Summers and David Soria Parra—the engineers behind Anthropic’s MCP protocol—to discuss the origins of MCP and their broader vision: why MCP was created, how it differs from existing APIs, and how tools can be better leveraged within MCP. The conversation is rich with insights—definitely worth saving and reading carefully.
Guests:
-
Alessio Fanelli (Host): Partner & CTO at Decibel
-
swyx (Host): Founder of Small AI
-
David Soria Parra: Engineer at Anthropic
-
Justin Spahr-Summers: Engineer at Anthropic
TLDR:
-
The "aha moment" for MCP came from an internal project at Anthropic inspired by LSP (Language Server Protocol). Drawing inspiration from LSP, the two engineers wondered if they could create something similar to standardize communication between AI applications and extensions.
-
The core design principle of MCP is that the concept of a tool isn't isolated—it's deeply tied to the client application and thus closely linked to the user. Through MCP operations, users should retain full control. When we say tools are controlled by the model, we mean only that the model invokes them—not that users manually specify which tool to use (except for prompting purposes).
-
OpenAPI and MCP are not opposing forces—they’re complementary. The key is choosing the right tool for the job. If your goal is rich interaction between AI applications, MCP is more suitable; if you want models to easily read and interpret API specs, OpenAPI is the better choice.
-
Using AI-assisted coding is an excellent way to rapidly build MCP servers. In early development stages, placing MCP SDK code snippets into an LLM’s context window allows the LLM to help construct the server effectively. Details can be refined later—a great method for quickly achieving basic functionality and iterating. Anthropic’s MCP team places strong emphasis on simplifying server creation so LLMs can actively participate.
-
The future direction of AI applications, ecosystems, and Agents will trend toward Statefulness—a topic of intense debate even within Anthropic’s core MCP team. After extensive discussion and iteration, the conclusion was clear: while Statefulness holds promise, we must balance innovation against deviating too far from current paradigms, finding equilibrium between forward-thinking ideals and practical complexity.
Founder Park is building a developer community. We invite developers and entrepreneurs who actively experiment with and test new models and technologies to join. Please scan the QR code to fill out detailed information about your product/project. Once approved, our staff will add you to the group.
By joining the group, you’ll gain access to:
-
High-signal discussions on mainstream models (e.g., DeepSeek);
-
Resource connections—opportunities to directly communicate and provide feedback to API providers, cloud vendors, and model companies;
-
Promotion of useful and interesting products/case studies—Founder Park will proactively highlight selected projects.
01 How Was MCP Born?
swyx (Host): First, what exactly is MCP?
Justin: Model Context Protocol (MCP) is essentially a framework we designed to help AI applications extend themselves or integrate plugin ecosystems. Specifically, MCP provides a communication protocol enabling AI applications (“clients”) and external extensions (“MCP servers”) to collaborate. These “extensions” can be plugins, tools, or other resources.
The purpose of MCP is to make it easy for developers to incorporate external services, functions, or data sources when building AI apps, thereby enriching their capabilities. Our naming includes a “client-server” concept mainly to emphasize the interaction pattern, but fundamentally, it's about creating a universal interface that makes AI applications easier to extend. We often liken MCP to a USB-C port for AI applications—an interoperable connector for the entire ecosystem.
It's important to clarify that MCP focuses on AI applications, not the models themselves—a common misconception.
swyx (Host): The client-server nature implies bidirectional communication, much like USB-C—that’s fascinating. Many people are researching and building open-source projects around it. It feels like Anthropic is more proactive than other labs in engaging developers. Was this driven externally, or did you two just have a flash of inspiration in a room somewhere?
David: Honestly, it mostly started with the two of us having a eureka moment in a room. It wasn’t part of any grand strategy. I joined Anthropic in July 2024, focusing on internal developer tools. As I worked, I kept thinking: how do we get more employees to deeply integrate our powerful models? They’re great—and getting better—so naturally, we wanted everyone using them internally.
Given my background in developer tools, I quickly became frustrated. On one hand, Claude Desktop had limited extensibility; on the other, IDEs lacked some of Claude Desktop’s useful features. So I constantly copied content back and forth between them—very cumbersome. Over time, I realized this was an MxN problem: multiple applications needing integration with multiple systems. A standardized protocol would solve this neatly. At the time, I was also working on an internal project related to LSP (Language Server Protocol), which wasn’t going anywhere. Combining these thoughts over a few weeks led me to a realization: Could we create something like LSP? Standardize communication between AI applications and extensions.
I shared the idea with Justin, who fortunately found it exciting, and together we began building.
From initial idea to first integration took about six weeks. Justin did most of the heavy lifting integrating with Claude Desktop, while I built proof-of-concepts in IDEs to demonstrate its use. Before launch, anyone looking through the codebase would see many traces of this journey—that’s roughly how MCP came to be.
Alessio (Host): What was the timeline? I know November 25 was the official release date. When did you actually start working on the project?
Justin: Around July, shortly after David proposed the idea, I got excited and joined him in building MCP. For the first few months, progress was slow because setting up the foundational elements—client, server, SDK, communication layer—required substantial groundwork. But once things could communicate via the protocol, it became thrilling—we could build all sorts of novel applications.
We then held an internal hackathon where colleagues built servers to control 3D printers or implement “memory” features. These prototypes were wildly popular and convinced us the idea had real potential.
swyx (Host): Back to building MCP—we only see the final result now, clearly inspired by LSP, which you both acknowledge. Can you talk about the workload involved? Was it mostly coding, or heavy on design work? I suspect design played a big role—like choosing JSON-RPC, how much LSP influenced you, and what parts were hardest?
Justin: We drew significant inspiration from LSP. David, coming from developer tools, had deep experience with LSP; I came more from product/infrastructure, so LSP was new to me.
From a design perspective, LSP solved the MxN problem David mentioned. Previously, every IDE/editor/language combination had siloed implementations—you couldn’t use JetBrains’ excellent Java support in Vim, nor Vim’s superior C support in JetBrains. LSP introduced a common language allowing cross-compatibility—each editor-language pair needed implementation only once. Our goal was similar, just shifted to “AI app–extension” integrations.
In terms of specifics, after adopting JSON-RPC and bidirectional communication, we diverged in certain aspects. LSP focused on functional primitives rather than semantic principles—something we applied to MCP. Then we spent considerable time designing each primitive in MCP and understanding their differences—this was major design effort. Initially, we aimed to support TypeScript, Python, and Rust (for Zed integration), building SDKs with clients and servers, establishing an internal test ecosystem, and stabilizing local MCP concepts (like spawning subprocesses).
We reviewed criticisms of LSP and tried to improve upon them in MCP—for example, avoiding overly complex uses of JSON-RPC. With MCP, we made a conscious decision to innovate in specific domains while borrowing mature patterns elsewhere. Choosing JSON-RPC wasn’t critical—we prioritized innovation in primitives instead. Leveraging prior art helped immensely.
swyx (Host): I’m fascinated by protocol design—there’s so much depth here. You mentioned the MxN problem, which anyone in developer tools knows well—it’s essentially the “Universal Box” problem.
At the infrastructure engineering level, the solution is often simple: connect everything to N things via a “universal box.” Companies like Uber, GraphQL, Temporal (where I worked), and even React face this. Did either of you tackle NxN problems during your time at Facebook?
David: To some extent, yes. That’s a great example. I dealt with version control systems and similar challenges—essentially consolidating interactions into a shared read-write system, building a “universal box” to solve it. This kind of issue is everywhere in developer tools.
swyx (Host): Interestingly, builders of “universal boxes” always run into similar issues—composability, remote vs local, etc. Justin mentioned presentation abstraction—how identical underlying concepts need distinct representations depending on context.
02 Core Concepts of MCP: Tools, Resources, and Prompts Are All Essential
swyx (Host): Reading the MCP docs raised a question: Why distinguish these two things? Many treat tool calling as a silver bullet, yet different types of calls serve different purposes—sometimes resource access, sometimes action execution. Which concepts did you group together, and why emphasize their importance?
Justin: We approached each primitive from the perspective of application developers. Whether building an IDE, Claude Desktop, or Agent UI, thinking from the user’s needs clarifies what functionality they’d expect from integrations. Tool calling is necessary—but differentiating use cases matters.
Thus, MCP’s original core primitives (later expanded):
-
Tool: Central to MCP. Directly adds tools callable by the model, which decides autonomously when to invoke them. For app developers, this resembles a “function call,” initiated by the model.
-
Resource: Refers to data or contextual background information added to the model’s context, controllable by the application. For instance, the model might automatically search and retrieve relevant resources to include in context. Alternatively, the app may expose a UI element (dropdown, paperclip menu) letting users explicitly attach resources as input to the LLM.
-
Prompt: Deliberately designed as text or message initiated or substituted by the user—like slash commands in editors or macros inserted directly into code completion.
MCP offers opinions on how these should be presented, but ultimately leaves decisions to application developers. Having distinct conceptual representations helps developers craft unique experiences and differentiate their apps. Uniformity isn’t desirable—developers don’t want cookie-cutter applications. When connecting to open ecosystems, unique approaches enable superior user experiences.
I see two aspects here. First, currently over 95% of integrations use tool calls—I hope more clients adopt resource and prompt calls. Prompt functionality was implemented first and proves highly practical, enabling traceable MCP servers based on user-driven interactions, where users control input timing—better than waiting for model processing. Also hoping more MCP servers use prompts to showcase tool usage.
Second, resources hold huge potential. Imagine an MCP server exposing documents, databases—clients could build full indexing around them. Since resource content exceeds what fits in context windows, modeling such access as resources makes sense. I look forward to seeing richer experiences emerge as clients better leverage these primitives.
Alessio (Host): When you have a hammer, everything looks like a nail—using tool calls to solve everything. People use it for database queries instead of resource calls. Curious—given an API (e.g., DB), what are the pros/cons of using tools vs resources? When should SQL queries be tools? When should data handling be via resources?
Justin: We distinguish tools and resources like this: tools are invoked by the model, which autonomously determines when to use them. If you want the LLM to run SQL queries, making it a tool makes sense.
Resources offer more flexibility, though complexity arises since many clients don’t support them yet. Ideally, schema metadata for database tables should be accessed via resources. Users could signal this info to start conversations, or AI apps could auto-discover resources. Any need to list entities or read structured data lends itself well to resource modeling. Resources are uniquely identified by URI and act as universal converters—e.g., an MCP server interpreting user-input URIs. In Zed editor, a prompt library interacts with an MCP server to populate prompts—both sides agreeing on URI format and data structure. This cross-use case is a cool illustration of resource utility.
Back to the app developer view: consider your app’s existing features—could any be offloaded to an MCP server? Nearly any IDE with attachment menus can naturally model those as resources. These patterns already exist.
swyx (Host): Yes, when I saw the @ symbol in Claude Desktop, I immediately thought of Cursor’s feature—now available to others. That design goal is brilliant because the function already exists and is intuitive. I showed that diagram—you surely agree it’s valuable. I think it should go on the doc homepage. Great suggestion.
Justin: Would you submit a PR for that? We’d love it.
swyx (Host): Sure, I’ll do it.
As someone in developer relations, I focus on giving people clear guidance—list key points first, then dive deep. A single diagram capturing core ideas is extremely helpful. I appreciate your emphasis on prompts. Early in ChatGPT and Claude’s evolution, many tried building GitHub-style prompt libraries or managers, but none gained traction.
There’s definitely room for innovation here. People want dynamic prompts, and you’ve enabled that possibility. I strongly endorse your concept of multi-step prompts—acknowledging that sometimes models require staged inputs or constraint-breaking steps. Prompts aren’t just single messages—they can be conversational sequences.
swyx (Host): This seems like where resources and tools begin to overlap—you mentioned wanting user/app control in some cases, model control in others. So are we just selecting subsets of tools now?
David: Yes, that’s a valid concern. Ultimately, it reflects a core design principle of MCP: the tool concept isn’t standalone—it’s tightly coupled with the client application and therefore the user. Through MCP operations, users must retain full control. By saying tools are model-controlled, we mean only that invocation is done by the model—not that users manually select tools (except for prompting, which shouldn’t be a regular UI feature).
That said, it’s perfectly reasonable for client apps or users to filter or optimize content offered by MCP servers—for example, a client could fetch tool descriptions and refine their presentation. Clients should have full authority in the MCP paradigm. Additionally, we have an early idea: adding protocol features allowing server developers to logically group primitives—prompts, resources, tools. These groups could represent separate MCP servers, combinable by users based on their needs.
03 MCP vs OpenAPI: Competition or Complement?
swyx (Host): Let’s discuss MCP versus OpenAPI—clearly a hot topic.
Justin/David: Fundamentally, OpenAPI spec is a powerful tool—I use it frequently when developing APIs and clients. However, for LLM use cases, OpenAPI is too low-level. It lacks higher-order, AI-specific abstractions like the MCP primitives we discussed earlier and doesn’t align with how application developers think. Compared to simply exposing a REST API and letting the model figure it out, models benefit far more from tools, resources, prompts, and other primitives specifically designed for them.
On the other hand, we intentionally designed MCP to allow some statefulness. AI applications and interactions are inherently trending toward Statefulness. While Stateless designs will always have their place, increasing modalities (video, audio) make stateful interactions increasingly appealing—thus, stateful protocols become valuable.
In reality, OpenAPI and MCP aren’t rivals—they’re complementary. Each excels in different areas and enhances the other. The key is picking the right tool for the task. If your goal is rich interaction between AI applications, MCP is better suited; if you want models to easily parse and understand API specs, OpenAPI wins. Already, bridges exist—one can convert OpenAPI specs into MCP and vice versa—which is fantastic.
Alessio (Host): I co-hosted a hackathon at AGI Studio. As an individual agent developer, I saw someone build a personal agent that generates MCP servers: feed it an API spec URL, and it outputs a corresponding MCP server. What do you think? Does this imply most MCP servers are just wrappers over existing APIs without unique design? Will this continue—mainly AI bridging legacy APIs—or will entirely new, unprecedented MCP experiences emerge?
Justin/David: Both scenarios will exist. First, there will always be value in “connecting data into apps.” Currently, tool calls dominate, but other primitives may prove better suited. Even if it remains an adapter layer, adapting across different concepts adds value.
Second, genuinely novel MCP servers beyond mere adapters are possible. For example, a memory MCP server lets LLMs remember info across conversations; a sequential thinking server improves reasoning. These don’t integrate external systems—they give models new ways to think.
Regardless, using AI to build servers is viable. Even for original functionality unrelated to API adaptation, models often find implementation paths. Many MCP servers will be API wrappers—it’s logical and effective, getting you far. But we’re still exploring possibilities.
As clients better support these primitives, richer experiences will emerge. An MCP server summarizing Reddit threads hasn’t been built yet, but the protocol fully supports it. I believe innovation kicks in when demand shifts from “I just want to connect my stuff to LLMs” to “I want a real workflow, a truly rich experience where the model deeply engages.” Right now, there’s a chicken-and-egg gap between client capabilities and server ambitions.
04 How to Quickly Build MCP Servers: Use AI Programming
Alessio (Host): Another under-discussed aspect of MCP is server construction. For developers wanting to start building MCP servers, what advice do you have? As a server developer, how do you balance providing detailed descriptions (for model understanding) versus raw data (left for model post-processing)?
Justin/David: Here’s my advice. One strength of MCP is how easy it is to build simple functions—about half an hour gets you something usable, albeit imperfect. Best starting point: pick your preferred language, use the SDK if available; define a tool you want the model to interact with; set up an MCP server; add the tool; write a brief description; connect it via stdin/stdout to your favorite app; observe how the model uses it.
For developers, seeing the model interact with something they care about is incredibly motivating. It sparks ideas about additional tools, resources, prompts—and how to evaluate and optimize them. It’s a loop of exploration, but starting small is fun and rewarding. MCP makes development playful, letting models act fast.
I also advocate AI-assisted coding. Early on, we found that feeding MCP SDK snippets into an LLM’s context often yielded solid server scaffolding—details refined later. It’s a fast way to prototype and iterate. From day one, we focused on simplifying server setup so LLMs could participate. In recent years, spinning up an MCP server takes 100–200 lines of code—very straightforward. Without an SDK, feed specs or other SDKs to the model to generate partial implementations. Function calls in your favorite language are usually direct.
Alessio (Host): Server builders largely determine returned data formats and content. Take Google Maps: which attributes return depends on the builder. Missing attributes can’t be overridden by users. Similar to my frustration with some SDKs: when API wrapper SDKs omit new parameters, I lose access to new features. How do you view this? How much intervention should users have, or is it fully up to server designers?
Justin/David: Regarding Google Maps, we bear some responsibility—it’s one of our reference servers. Generally, at least for now, we intentionally avoid requiring tool call results to be strictly structured JSON or conform to schemas. Instead, results appear as plain text or images—direct inputs to the LLM. We favor returning abundant data, trusting the LLM to extract what it needs. We’ve invested heavily here, believing in maximizing LLM flexibility rather than over-constraining outputs, which could hinder scalability as models evolve. In ideal example servers, result types pass straight through from the underlying API, preserving fidelity.
Alessio (Host): Determining boundaries here is indeed tough.
David: Let me emphasize AI’s role here. Many sample servers were written by Claude—unsurprising. Traditionally, people apply conventional software engineering practices, but we must relearn how to build systems for LLMs and trust their capabilities. With LLMs advancing yearly, delegating data processing to models adept at it is wise. This may require letting go of decades-old software engineering norms.
Viewing MCP another way, AI’s pace is astonishing—exciting yet slightly concerning. The next bottleneck for model capability gains may lie in interacting with the external world: accessing external data, performing stateful actions. At Anthropic, we prioritize secure interactions with proper controls and calibrations. As AI evolves, expectations grow for these abilities—bridging models to the outside world is key to boosting AI productivity. MCP represents our bet on this future trajectory and its significance.
Alessio (Host): Absolutely. I think any API property labeled “formatted” should be removed. We should pull raw data from all interfaces. Why pre-format? Models are smart enough to format addresses themselves. End users should decide.
05 How Can MCP Better Leverage More Tools?
swyx (Host): One more question: how many related functions can an MCP implementation support? This touches breadth vs depth and relates directly to nested MCPs.
When Claude debuted million-token context in April 2024, it claimed support for 250 tools, yet in practice, models struggle to use many effectively. It’s a breadth issue—no tool-to-tool calling, just flat layers—leading to confusion. When tools overlap, wrong ones get called. Any recommendations on max active MCP servers at once?
Justin: Honestly, no absolute answer. It depends on your model and clarity of tool names/descriptions—overlaps cause confusion. Ideally, feed all info to the LLM and let it handle everything—MCP’s long-term vision. Practically, client apps may need supplementary work: filtering tool sets, using a small fast LLM to pre-select relevant tools before passing to large models, or routing through proxy MCP servers.
For Claude, supporting hundreds of tools is safe. Other models? Unclear. Over time, performance should improve—so caution against premature constraints that stifle growth. Supported count heavily depends on description overlap. Diverse servers with clear, unique names/descriptions allow more tools than similar ones (e.g., both GitLab and GitHub servers).
Also depends on app type. Highly intelligent apps may reduce user queries and configurability; for IDEs or chat apps, letting users toggle desired toolsets per session—rather than keeping all active—is perfectly fine.
swyx (Host): Finally, let’s highlight the Sequential Thinking MCP Server. Its branching and “more writing space” features are fascinating. Also, Anthropic released a new engineering blog last week on their Thinking Tool, causing community confusion about overlap. Actually, different teams solving similar problems differently—many valid approaches.
Justin/David: As far as we know, the Sequential Thinking Server shares no direct lineage with Anthropic’s Thinking Tool. But it reflects a broader truth: numerous strategies exist to make LLMs think more thoroughly, reduce hallucinations, or achieve goals—approaches that show effects across dimensions reliably. That’s MCP’s power—you can build diverse servers or embed varied tools in one server to guide model thinking in specific ways for different outcomes.
There’s no single prescribed way for LLMs to think.
swyx (Host): Different apps will have different needs, and MCP enables that diversity, right?
Justin/David: Exactly. Some MCP servers fill gaps in model capabilities. Model training, preparation, research take time to incrementally improve. A sequential thinking server might seem simple, but implementing such complex reasoning inside a model takes far longer than days to build externally via MCP.
For example, if my model feels unreliable, or someone finds current outputs generally untrustworthy, I could imagine building an MCP server that tries generating three responses to a query and picks the best. With MCP, recursive, composable LLM interactions become feasible.
06 What’s the Difference Between Complex MCP and Agents?
Alessio (Host): Next, composability. How do you view embedding one MCP within another? Any plans? Say I want an MCP to summarize Reddit threads—it might need a Reddit API MCP plus a summarization MCP. How would I build such a “super MCP”?
Justin/David: Fascinating topic—two perspectives.
One, consider building components like summarization. While it may call an LLM, we aim to keep it model-agnostic. This leverages MCP’s bidirectional communication. Take Cursor: it manages the LLM interaction loop. Server developers can request tasks from the client (the user’s app)—e.g., ask the client to perform summarization using the user’s chosen model and return the result. Thus, model selection rests with Cursor—server devs avoid adding extra SDKs or API keys, achieving model independence.
Two, building more complex systems via MCP is absolutely possible. Imagine an MCP server supporting Cursor or Windsurf, itself acting as an MCP client calling other MCP servers for richer experiences. This reflects recursion—supported in spec authorization. You can chain apps serving dual roles, even build DAGs (Directed Acyclic Graphs) for complex flows. Intelligent MCP servers can tap into the entire MCP ecosystem. Experiments already exist. Add auto-selection, installation, and more becomes possible.
Our SDKs need enhancements to make building recursive client-server apps easier—reusing behaviors across multiple MCP servers. These are future improvements, but already hint at feasible, underutilized patterns.
swyx (Host): Sounds exciting—I’m sure many will draw inspiration. So, is such a dual-role MCP a kind of Agent? In a sense, an Agent receives a request and performs opaque lower-level operations. There’s abstraction between you and raw data sources. Do you have unique views on Agents?
Justin/David: Yes, you can certainly build an Agent via MCP. Key distinction: an MCP server plus client acting as an Agent vs. a true Agent. For example, within an MCP server, you could use the client’s sample loop to enhance experience and let the model call tools—building a genuine Agent is relatively straightforward this way.
Regarding MCP-Agent relationship, we have several angles:
First, MCP may be an excellent way to express Agent capabilities, though perhaps missing some UX-enhancing features worth incorporating into the protocol.
Second, MCP could serve as a foundational communication layer for building Agents or composing interactions between Agents. Alternatively, MCP might focus more on AI application integration rather than Agent-centric design. This remains debated—each path involves tradeoffs. Returning to the “universal box” analogy, when designing protocols and managing ecosystems, we must avoid feature bloat. Trying to do everything risks doing nothing well. The real question is how naturally Agents fit within existing models and paradigms—or whether they should stand as independent entities. This remains unresolved.
swyx (Host): I think once bidirectional communication allows clients and servers to merge, delegate work to other MCP servers, it starts feeling like an Agent. I appreciate your commitment to simplicity—avoiding the trap of solving every problem.
07 MCP’s Next Step: Making the Protocol More Reliable
swyx (Host): Recent updates shifting from stateful to stateless servers sparked interest. Why choose Server-Sent Events (SSE) as the publish protocol and transport, and support pluggable transport layers? Influenced by Jared Palmer’s tweets, or already in motion?
Justin/David: No, this had been publicly discussed on GitHub months ago—we’d been weighing statefulness vs statelessness. We believe the future of AI apps, ecosystems, and Agents leans toward Statefulness. This was one of the most contentious topics within the MCP core team, undergoing multiple rounds of debate and iteration. Final consensus: while we believe in Statefulness, we cannot abandon existing paradigms—we must balance stateful ideals with operational complexity. Requiring MCP servers to maintain persistent connections creates massive deployment and operational hurdles. Initial SSE transport assumed indefinite client-server connections—unrealistic for large-scale operations.
Hence, we sought balance: maintaining Statefulness benefits while ensuring operability. Our streamable HTTP transport—including SSE—follows incremental enhancement. Start with a regular HTTP server POSTing results. Gradually add streaming, then server-initiated requests. With Session Resumption (reconnect and resume after disconnection), you gain stateful interaction with scalable, network-resilient deployment.
Alessio (Host): Yes, including session IDs. Any plans for future authentication? Currently, for some MCPs, I just paste my API key in CLI. What’s the roadmap? Will there be MCP-specific config files managing credentials?
Justin/David: The next draft revision includes an authentication spec. Focus is on user-to-server auth using OAuth 2.1 or modern subsets. Works well—people are already building on it. Solves real issues—you don’t want users pasting API keys everywhere, especially as most servers move remote, requiring secure auth.
Locally, since auth lives in transport layer (headers), stdin/stdout can’t directly handle it. But locally running stdin/stdout programs remain flexible—even opening browsers for auth flows. Whether to use HTTP for local auth is still debated internally—Justin favors it, I don’t—so no consensus yet.
For auth design, like the rest of the protocol, we aim minimalism—solve real pain points, keep features lean, expand only when validated by demand. Protocol design demands caution—mistakes are irreversible without breaking backward compatibility. So we only accept well-vetted additions. Community experiments via extension mechanisms come first—only when broad consensus emerges and sustainable support is ensured do we integrate into core—making evolution safer and more robust.
Take auth and API keys—we brainstormed extensively. Current approach (OAuth 2.1 subset) covers API key use cases. An MCP server can act as OAuth provider—with its “/authorize” page simply showing a text box for API key entry. Not ideal, but acceptable given alignment with existing patterns. We worry that adding too many options increases complexity for both clients and servers.
Alessio (Host): Have you considered scopes? Yesterday we interviewed Dharmesh Shah, founder of Agent.ai. He gave an email example: he owns all his emails and wants fine-grained scope control—“you can only access these email types” or “only emails sent to this person.” Today, scopes are mostly REST API-based—access to specific endpoints. Could models someday understand and use scopes to dynamically limit transmitted data?
Justin/David: We recognize potential demand for scopes and have discussed it, but adding it to the protocol requires extreme caution. Our bar: identify real problems unsolvable with current methods, prototype on MCP’s extensibility, prove good UX—then consider formal inclusion. Auth differs—it was top-down designed.
Every scope story sounds compelling, but we need concrete end-to-end user cases showing current limitations. Given composability and logical grouping, we typically recommend designing smaller MCP servers—separating functionalities into discrete, independent servers, composed at the application layer. Some oppose single servers handling auth for multiple services—arguing each service deserves its own server, combined at app level.
08 Security Issues in MCP Server Distribution
Alessio (Host): One standout design of MCP is its language agnosticism. As I understand, Anthropic has no official Ruby SDK, nor does OpenAI. Though developers like Alex Rudall excel at building such kits, MCP eliminates the need for per-language SDKs—just create a standard interface recognized by Anthropic. Brilliant.
swyx (Host): About the MCP Registry—five or six unofficial registries exist, and the original official one is defunct. Registry models—offering downloads, likes, ratings, trust mechanisms—feel like traditional package repos (npm, PyPI)—but I find them unreliable. Even with social proof, next update could compromise a trusted package. Abusing trust systems feels like being harmed by the very mechanism meant to protect. Hence, I encourage using MCP Inspector—it inspects traffic flow, potentially revealing many security issues. Your thoughts on registry security and supply chain risks?
Justin/David: Spot on. This is a classic supply chain security risk all registries face. Industry solutions vary. Apple App Store model: strict review via automated systems and human teams. Viable for specific contexts. But in open-source ecosystems, decentralized or community-driven models (like MCP registry, npm, PyPI) are more typical and likely unsuitable for centralized approval.
swyx (Host): These repositories inherently face supply chain attacks. Some core servers published in official repos—especially memory server, inference/thinking server—are notable. They’re not just API wrappers—often simpler and more convenient than direct API use.
Take the memory server—though startups specialize in memory features, this MCP version is ~200 lines—extremely simple. For advanced scaling, mature solutions may be needed. But for quick memory integration, it’s excellent—possibly eliminating reliance on third-party products. Any special stories behind these non-API-wrapper specialty servers?
Justin/David: Not really. Most stem from the hackathon we mentioned. Interest in MCP grew—engineers at Anthropic wanting memory or related features used MCP to prototype previously impractical ideas. You no longer need to be an end-to-end expert or possess private codebases/resources to add advanced capabilities like memory. Many servers emerged this way. We also considered showcasing functional range at launch.
swyx (Host): I completely agree. This partly fueled your launch success—providing rich examples people could copy-paste and extend. Highlight the file system MCP server—it enables file editing. I recall Eric demoing his excellent bench project on a podcast—community loved the open-sourced file editing tool. Some companies treat this capability as core IP, yet you open-sourced it. That’s awesome.
Justin/David: File system server is one of my favorites. It solved a real limitation I faced—an indie game project I wanted to link with cloud services and “artifacts” David mentioned. Enabling cloud-local machine interaction is huge—I love this feature.
This is a classic case—born from frustrations during MCP creation and the need for such functionality. The journey—from hitting a wall, to creating MCP and this server—is direct and meaningful. Justin felt this deeply. It holds special significance—almost spiritual origin of the protocol.
09 MCP Is Now a Multi-Company Effort
swyx (Host): Discussion around MCP is vibrant. Where should people engage in these debates? Directly in the spec repo’s discussion section?
Justin/David: Voicing opinions online is easy—but real impact comes from action. Jason and I are traditional open-source believers: actual contribution matters. If you build concrete examples, invest effort in extending SDK functionality you desire, your ideas are more likely to be adopted. Opinion-only voices may be ignored. We value discussion, but with limited time, we prioritize those investing real work.
MCP-related discussions and notifications are overwhelming—we need scalable architectures to engage the community meaningfully. Running a successful open-source project sometimes requires tough decisions that disappoint some. As maintainers, we must uphold the project’s true vision and push forward decisively—even if disagreed with—because alternatives aligned with others’ visions may exist.
MCP is just one of many solutions addressing general domain problems. If you disagree with core maintainers’ direction, open-source empowers you to fork. We welcome feedback and strive to scale feedback mechanisms, but we’ll also follow our instincts on what’s right. This may spark controversy in open-source discourse—but that’s inherent to fast-moving open projects.
swyx (Host): Fortunately, you two seem comfortable making hard choices. Facebook’s open-source projects offer lessons—even without direct involvement, observing participant behavior helps. I deeply engaged with React’s ecosystem, once forming a working group with public processes. Every member spoke up—those with real work and contributions. Helped for a while. GraphQL evolved similarly to today’s MCP hype cycle. I lived through GraphQL’s journey—eventually Facebook donated it to an open foundation.
This raises a question: Should MCP do the same? Not a simple yes/no—tradeoffs exist. Most are happy with Anthropic’s stewardship—you created and manage it. But at scale, bottlenecks appear—realizing it’s company-led. Eventually, people expect true open standards driven by nonprofits, with multi-stakeholder governance like Linux or Apache Foundations. Maybe it’s early, but what are your thoughts?
Justin/David: Governance in open source is complex and nuanced. On one hand, we’re committed to making MCP an open standard, open protocol, open project—welcoming all interested parties. Progress is good—ideas like streamable HTTP came from Shopify and others—cross-company collaboration works. But we fear official standardization—traditional bodies or processes could severely slow down rapid AI innovation. We need balance: sustain broad participation and contribution while addressing governance concerns, finding the right future path without constant organizational upheaval.
We genuinely want MCP to be a true open project. Though initiated by Anthropic and developed by us while employed there, we don’t want it seen merely as “Anthropic’s protocol.” We hope AI labs and companies join or adopt it. Challenging—but requires balancing interests, avoiding committee-driven stagnation. Open source has many successful governance models—most nuances involve corporate sponsorship and influence in decision-making. We’ll navigate these carefully. We absolutely want MCP to become a true community project.
In fact, many non-Anthropic contributors already have commit and admin rights. Pydantic team maintains Python SDK; Block and others contributed to spec; Java, C#, Kotlin SDKs led by Microsoft, JetBrains, Spring AI—all with full ownership. Look closely—it’s already a large, multi-company project. Many contribute—not just us two holding permissions.
Alessio (Host): Any “wishlist” items for future MCP servers or clients? Anything you particularly hope people build but haven’t yet?
Justin/David: I’d love to see more clients supporting sampling. Also hope someone builds specific servers—like one summarizing Reddit threads, or fetching last week’s EVE Online activity. Especially keen on the former (sampling client) being model-agnostic—not that I dislike models beyond Claude (Claude is best now), but purely want a sampling-capable client framework.
More broadly, more clients supporting full MCP spec would be great. We designed for gradual adoption—if these carefully crafted primitives gain wide use, that’d be amazing. Reflecting on my initial motivation for MCP and excitement about the file system server—
I’m an indie game developer in my spare time—would love to see an MCP client/server integrated with Godot Engine (which I used for game dev). Integrating AI into games would become effortless—or let Claude play-test my game. Like, have Claude play Pokémon. Foundations exist. Going further—have Claude generate 3D models in Blender for you?
swyx (Host): Frankly, even shader code theoretically possible. Beyond my expertise, but given tools and support, developers achieve astonishing things. We’re planning a “Claude Plays Pokémon” hackathon with David Hersh. Didn’t plan to include MCP initially—but maybe now I should.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
