The Creators of Model Context Protocol

Hey everyone, welcome back to Latent Space. This is Alessio, partner and CTO at Decibel, and I'm joined by my co-host, swyx, founder of smol.ai.

Hey, morning.

Today we have a remote recording, I guess, with David and Justin from Anthropic over in London. Welcome.

Hey, good to be here.

Welcome. You guys have created a storm of hype because of MCP, and I'm really glad to have you on. Thanks for making the time. What is MCP? Let's start with a crisp definition from the horse's mouth, and then we'll go into the origin story. What is MCP?

Sure. The Model Context Protocol, or MCP for short, is basically something we've designed to help AI applications extend themselves or integrate with the ecosystem of plugins. The terminology is a bit different—we use this client-server terminology, and we can talk about why that is and where that came from—but at the end of the day, it really is about extending and enhancing the functionality of AI applications. David, would you add anything?

Yeah, I think that's actually a good description. There are a lot of different ways people try to explain it, but at the core, what Justin said is that extending AI applications is really what this is about. The interesting bit I want to highlight is that it's AI applications, not models themselves, that this is focused on. That's a common misconception that we can talk about a bit later.

Another version that we've used and come to like is that MCP is kind of the USB-C port of AI applications. It's meant to be this universal connector to a whole ecosystem of things.

Yeah. Specifically, an interesting feature is, like you said, the client and server, and it's a sort of two-way connection, right? In the same way that USB-C is two-way, which could be super interesting.

Let's go into the origin story a little bit. Many people have tried to make standards around agents, and many people have tried to build open source. I also get the sense that Anthropic is going hard after developers in a way that other labs are not. I'm curious if there was any external influence, or was it just you two guys in a room somewhere riffing?

It was actually mostly us two guys in a room riffing. This was not part of a big strategy. If you roll back time a little bit to July 2024, I had started at Anthropic about 3 months earlier, and I was mostly working on internal developer tooling, which is what I'd been doing for years before.

As part of that, there was an effort to figure out how to empower more employees at Anthropic to integrate really deeply with the models we had. We were seeing how good they were and how amazing they would become in the future, and of course, you want to dogfood your own model as much as you can.

As part of my developer-tooling background, I quickly got frustrated by the fact that, on the one hand, I had Claude Desktop, which was this amazing tool with Artifacts that I really enjoyed, but it was limited to exactly that feature set, and there was no way to extend it. On the other hand, I worked in an IDE, which could act on the file system and a bunch of other things, but it didn't have Artifacts or something like that. So what I constantly did was copy things back and forth between Claude Desktop and the IDE, and that quickly got me very frustrated.

Part of that frustration was, “How do I fix this? What do we need?” Back to the developer focus that I have, I thought, “I know how to build all these integrations, but what do I need to do to let these applications let me do this?” Very quickly, you see that this is clearly an M×N problem. You have multiple applications and multiple integrations you want to build, so what's better to fix this than using a protocol?

At the same time, I was working on an LSP-related thing internally that didn't go anywhere. You put these things together in someone's brain and let them sit for a few weeks, and out of that comes the idea of, “Let's build some protocol.”

So, back to this little room, it was literally just me going to a room with Justin and saying, “I think we should build something like this. This is a good idea.” Justin, lucky for me, took a real interest in the idea and took it from there to build something together with me.

That's the inception story. From then on, it was just the two of us building it over the course of about a month and a half: building the protocol and building the first integrations. Justin did a lot of the heavy lifting for the first integrations in Claude Desktop, and I did a lot of the first proof of concept for how this could look in an IDE.

We could talk about some of the tidbits you could find way before the inception—before the official release—if you were looking at the right repository at the right time. But there you go. That's the rough story.

What was the timeline? I know November 25th was the official announcement date. When did you guys start working on it?

Justin, when did we start working on that?

I think it was around July. As soon as David pitched the initial idea, I got excited pretty quickly, and we started working on it almost immediately after that conversation.

It was a couple—maybe a few—months of building the really unrewarding bits, if we're being honest. For establishing something that's a communication protocol with clients, servers, and SDKs everywhere, there's just a lot of groundwork you have to lay. So it was a pretty slow couple of months, but afterward, once you get some things talking over that wire, it really starts to get exciting, and you can start building all sorts of crazy things.

I think this really came to a head approximately a month before release. There was an internal hackathon where some people got excited about MCP and started building all sorts of crazy applications. I think the coolest one was an MCP server that could control a 3D printer or something.

Suddenly, people were feeling the power of Claude connecting to the outside world in a really tangible way. That added some juice to the release.

Yeah. We'll go into the technical details, but I want to wrap up here. You mentioned that you could have seen some things coming if you were looking in the right places. We always want to know where to get alpha. How could someone find MCP early?

I'm a big Zed user. I like the Zed editor. The first MCP implementation in an IDE was in Zed. It was written by me, and it was there about a month and a half before the official release because we needed to do it in the open, since it's an open source project.

It was named slightly differently because we hadn't settled on the name yet, but it was there.

Anthropic also had some preview of a model with Zed, right? Some kind of fast-editing model. I'm a Cursor and Windsurf user, I confess, and I haven't tried Zed. What's your unsolicited, two-second pitch for Zed?

It's a good question. It really depends on what you value in editors. For me, I wouldn't even say I like or love Zed more than the others. I like them all in one way or another; they're complementary. I do use Windsurf, and I do use Zed.

My main pitch for Zed is that it's a low-latency, super-smooth editor with a decent enough AI integration.

Got it. I think that's all it is for a lot of people. A lot of people are obviously very tied to the VS Code paradigm and the extensions that come along with it.

I wanted to go back a little bit to some of the things that you mentioned, Justin, which was building MCP on paper. Obviously, we only see the end result. It seems inspired by LSP, and I think both of you have acknowledged that. How much is there to build? When you say “build,” is it a lot of code or a lot of design? I feel like it's a lot of design, right? You're picking JSON-RPC. How much did you base it off of LSP, and what were the hard parts?

Yeah, absolutely. We definitely took heavy inspiration from LSP. David had much more prior experience with it than I did, working on developer tools. I've mostly worked on product or infrastructural things, so LSP was new to me.

From a design-principles perspective, it really makes a ton of sense because it solves this M×N problem that David referred to. In the world before LSP, you had all these different IDEs and editors, and then all these different languages that each wanted to support—or that their users wanted them to support. Everyone was just building one-off integrations.

You might use Vim and have really great support for C, and then switch over to JetBrains and have Java support. But you don't get to use the great JetBrains Java support in Vim, and you don't get to use the great C support in JetBrains.

LSP largely solved this problem by creating a common language that they could all speak. Then you can have some people focus on really robust language-server implementations, while the IDE developers can focus on their side, and they both benefit.

So that was our key takeaway for MCP: that same principle and that same problem in the space of AI applications and extensions to AI applications. In terms of concrete particulars, we did take JSON-RPC and this idea of bidirectionality, but I think we quickly took it down a different route after that.

I guess there is one other principle from LSP that we try to stick to today, which is this focus on how features manifest more than the semantics of things, if that makes sense. David refers to it as being presentation-focused, where you’re thinking about and offering different primitives not because the semantics of them are necessarily very different, but because you want them to show up differently in the application. That was a key insight about how LSP was developed, and that’s also something we try to apply to MCP.

But, like I said, from there we spent a lot of time—and we could go into this more separately—thinking about each of the primitives that we wanted to offer in MCP and why they should be different, and why we wanted to have all these different concepts. That was a significant amount of work. That was the design work, as you allude to.

Then, out of the gate, we had 3 different languages that we wanted to support to some degree. That was TypeScript, Python, and then, for the Zed integration, Rust. So there was some SDK-building work in those languages, a mixture of clients and servers to build out, to try to create this internal ecosystem that we could start playing with.

Then, just trying to make everything robust—the whole concept we have for local MCP, where you launch subprocesses and stuff—and making that robust took some time as well.

Yeah, maybe adding to that, I think the LSP influence goes even a little bit further. We took quite a close look at criticisms of LSP—things that LSP didn’t do right and things that people felt they would love to have done differently—and really took that to heart to see what were some of the things we wished we could do better.

We took a lengthy look at their very unique approach to JSON-RPC, I might say, and decided that this was not what we wanted to do. So there are these differences, but it’s clearly very inspired. I think when you’re trying to build something like MCP, you want to pick the areas you want to innovate in, but you also want to be boring about the other parts.

Pattern-matching LSP to the problem allows you to be boring in a lot of the core pieces that you want to be boring in. The choice of JSON-RPC is very noncontroversial to us because it doesn’t matter at all what the actual bytes on the wire are that you’re speaking. It makes no difference to us. The innovation is in the primitive you choose and these types of things, so we wanted way more focus on that. Having some prior art is good there, basically.

It does. I wanted to double-click on this. There are so many things you can go into. I’m passionate about protocol design, and I wanted to show you guys this. I think you guys know this, but you already referred to the N×N problem. Anyone working in developer tools has faced this exact issue, where you see the god box—the fundamental problem and solution of all infrastructure engineering is that you have N things going to N things, and then you put in the god box and they’ll all be better, right?

Here is one problem from Uber, one problem from GraphQL, one problem from Temporal, where I used to work, and this is from React. I was curious: did you solve N×N problems at Facebook? It sounds like, David, you did that for a living, right? This is just N×N for a living.

Yeah, to some degree, for sure. I can give a good example of this. I did a bunch of this kind of work on source control systems and these types of things, and there were a bunch of these kinds of problems as well. You just shove them into something that everyone can read from and everyone can write to, and you build your god box somewhere and it works.

But, yeah, in developer tooling, you’re absolutely right. In developer tooling, this is everywhere. It shows up everywhere.

What’s interesting is I think everyone who makes the god box then has the same set of problems. You now have composability, and remote versus local, and there’s this very common shared set of problems. I kind of want to make a meta-lesson on how to do the god box, but we can talk about the development stuff later.

I wanted to double-click again on the presentation that Justin mentioned—how features manifest and how some things are the same, but you just want to reify some concepts so they show up differently. I had that sense when I was looking at the MCP docs. I was thinking, why do these 2 things need to be different? In other paradigms, they’re basically the same.

I think a lot of people treat tool calling as the solution to everything, right? Sometimes you can view different kinds of tool calls as different things. Sometimes they’re resources, sometimes they’re actually taking actions, and sometimes they’re something else that I don’t really know yet. What are some things that you mentally group as adjacent concepts, and why were they important for you to emphasize?

Yeah, I can chat about this a bit. Fundamentally, every primitive that we thought through, we thought through from the perspective of the application developer first. If I’m building an application, whether it’s an IDE, a cloud desktop, some agent interface, or whatever the case may be, what are the different things that I would want to receive from an integration?

Once you take that lens, it becomes quite clear that tool calling is necessary but very insufficient. There are many other things you would want to do besides just get tools and plug them into the model, and you want to have some way of differentiating what those different things are.

The core primitives that we started MCP with—we’ve since added a couple more—but the core ones were really tools, which we’ve already talked about. That’s adding tools directly to the model, or function calling, as it’s sometimes called. Resources are basically bits of data or context that you might want to add to the model context.

This is the first primitive where we decided this could be application-controlled. Maybe you want a model to automatically search through and find relevant resources and bring them into context. But maybe you also want that to be an explicit UI affordance in the application, where the user can pick through a drop-down or a paperclip menu or whatever, find specific things, and tag them in. Then that becomes part of their message to the LLM. Those are both use cases for resources.

The third one is prompts, which are deliberately meant to be user-initiated or user-submitted text or messages. The analogy here would be if you’re in an editor, like a slash command or an @-autocomplete type of thing, where I have this kind of macro that I want to drop in and use.

We have expressed opinions through MCP about the different ways that these things could manifest, but ultimately it is for application developers to decide how to use these different concepts. It’s very useful as an application developer because you can decide the appropriate experience for each, and this can actually be a point of differentiation, too.

We were also thinking from the application developer’s perspective: application developers don’t want to be commoditized. They don’t want their application to end up the same as every other AI application. What are the unique things they could do to create the best user experience, even while connecting up to this big, open ecosystem of integrations?

Yeah, and I think there are 2 aspects to that that I want to mention. The first one is that, interestingly enough, while nowadays tool calling is probably 95% or more of the integrations, I wish there were more clients supporting resources and prompts.

The very first implementation in Zed was actually a prompt implementation. It didn’t deal with tools, and we found this quite useful because it allows you to build an MCP server that takes a backtrace from Sentry or any other online platform that tracks your crashes and lets you pull this into the context window beforehand.

It’s quite nice that way. It’s a user-driven interaction, where you decide when to pull this in and don’t have to wait for the model to do it. It’s a great way to craft the prompt.

Similarly, I wish more MCP servers today would bring prompts as examples of how to even use the tools they’re providing. At the same time, the resources part is quite interesting as well, and I wish we would see more usage there because it’s very easy to envision, yet nobody has really implemented it.

A system where an MCP server exposes a set of documents that you have in your database, or whatever you might want to, as a set of resources. Then a client application would build a full RAG index around this. This is definitely an application use case we had in mind as to why these are exposed in such a way that they're not model-driven, because you might want to have way more resource content than is realistically usable in a context window.

I hope applications will do this in the next few months and use these primitives way better, because I think there's way richer experiences to be created that way.

Yeah, I completely agree with that. I would also add that I think that's a great point, and everybody just has a hammer and wants to do tool calling on everything. I think a lot of people do tool calling to do a database query; they don't use resources for it.

What are the pros and cons, or when should people use a tool versus a resource, especially when it comes to things that do have an API interface? For a database, you can do a tool that does a SQL query. When should you do that, or a resource instead with the data?

The way we separate these is that tools are always meant to be initiated by the model. It's sort of at the model's discretion that it will find the right tool and apply it. If that's the interaction you want as a server developer—where it's like, okay, suddenly I've given the LLM the ability to run SQL queries, for example—that makes sense as a tool. But resources are more flexible, basically.

To be completely honest, the story here is practically a bit complicated today because many clients don't support resources yet. But in an ideal world, where all these concepts are fully realized and there's full ecosystem support, you would do resources for things like the schemas of your database tables and stuff like that. That's a way to either allow the user to say, “Okay, Claude, I want to talk to you about this database table. Here it is. Let's have this conversation,” or maybe the particular AI application that you're using—something agentic like Claude Code—is able to agentically look up resources and find the right schema of the database table you're talking about. Both those interactions are possible.

Anytime you have a situation where you want to list a bunch of entities and then read any of them, that makes sense to model as resources. Resources are also uniquely identified by a URI, always. You can think of them as general-purpose transformers: if you want to support an interaction where a user just drops a URI in and then you automatically figure out how to interpret that, you could use MCP servers to do that interpretation.

One of the interesting side notes here, back to the Zed example of resources, is that it has a prompt library that people can interact with. We exposed a set of default prompts that we want everyone to have as part of that prompt library, and resources were part of it for a while. You boot up Zed and it will just populate the prompt library from an MCP server, which was quite a cool interaction. That was, again, very specific: both sides needed to agree upon the URI format and the underlying data format. But that was a nice and neat little application of resources.

Going back to that perspective of, as an application developer, what are the things that I would want, we applied this thinking to what existing features of applications could conceivably be factored out into MCP servers if you were to take that approach today. Basically, any IDE where you have an attachment menu naturally models as resources. Those implementations already existed.

Yeah. I think the immediate thing, when you introduced it for Claude Desktop and I saw the @ sign there, I was like, “Oh, yeah, that's what Cursor has, but this is for everyone else.” I think that's a really good design target because it's something that already exists and people can map onto pretty neatly.

I was actually featuring this chart from Mahesh's workshop, which presumably you guys agreed on. I think this is so useful that it should be on the front page of the docs. It probably should be.

I think that's a good suggestion. Do you want to do a PR for this?

I love it. Yeah, do a PR. I've done a PR for Mahesh's workshop in general.

I approve it.

Yeah, thank you. I think for me, as a developer relations person, I always insist on having a map for people: here are all the main things you have to understand; we'll spend the next 2 hours going through this. So one image that covers all this is pretty helpful.

I like your emphasis on prompts. In the early days of ChatGPT and Claude, a lot of people came up with, “Oh, you can't really follow my screen, can you?” In the early days of ChatGPT and all that, a lot of people started talking about GitHub for prompts. Like, we'll do prompt manager libraries.

I've also seen prompt files from Humanloop as other ways to standardize how people share prompts. But I agree that there should be more innovation here, and I think people probably want some dynamism, which I think you allow for. I like that you have multistep prompting. That was the main thing that got me: these guys really get it.

You may have published some research that says that sometimes, to get the model working the right way, you have to do multistep prompting or jailbreaking to behave the way that you want. I think prompts are not just single conversations; they're sometimes chains of conversations.

Another question I had when I was looking at some server implementations: the server builders decide what data eventually gets returned, especially for tool calls. For example, the Google Maps one: if you look through it, they decide what attributes get returned, and the user cannot overwrite that if there's a missing one.

That has always been my gripe with SDKs in general, when people build API-wrapper SDKs and then they miss one parameter that maybe is new, and I cannot use it. How do you think about that? How much should the user be able to intervene in that versus just letting the server designer do all the work?

I think we probably bear responsibility for the Google Maps one, because I think that's one of the reference servers we've released. In general, for tool results in particular, we've actually made the deliberate decision, at least thus far, for tool results to be not structured JSON data, not really matching a schema, but as text or images—or basically as messages that you would pass into the LLM directly.

The corollary from that is you really should just return a whole jungle of data and trust the LLM to sort through it, sift it, and extract the information it cares about, because that's exactly what they excel at. We really try to think about how to use LLMs to their full potential and not overspecify, then end up with something that doesn't scale as LLMs themselves get better and better.

So, yeah, I suppose what should be happening in this example server—which, again, pull requests are welcome—is that all these result types should literally just be passed through from the API that it's calling, and then the LLM can do whatever it wants with the data.

Yeah. That, to me, is the USB-C part of this, which is, hey, this is kind of the file, so to speak, on the server, which is what the API returns, and then you're funneling it through without doing too much in the middle.

At the same time, you need to do some work on some of the pieces because sometimes they have weird encoding or all these different things that maybe the server should handle. But, yeah, it's a hard design decision about where to draw the line.

I'll maybe throw AI under the bus a little bit here and just say that Claude wrote a lot of these example servers, as no surprise at all. But I do think there's an interesting point in this: people at the moment still mostly just apply their normal software engineering and API approaches to this.

I think we still need a little bit more relearning of how to build something for LLMs and trust them, particularly as they are getting significantly better year over year. Two years ago, maybe that approach would have been very valid, but nowadays, just throw data at that thing that is really good at dealing with data. That's a good approach to this problem.

I think this is just unlearning 20, 30, 40 years of software engineering practices that go a little bit into this, to some degree.

If I could add to that real quickly, just one framing as well for MCP is thinking in terms of how crazily fast AI is advancing. It's exciting; it's also scary. The biggest bottleneck to the next wave of capabilities for models might actually be their ability to interact with the outside world—to read data from outside data sources or take stateful actions.

Working on a topic that we absolutely care about means doing that safely, with the right control and alignment measures in place and everything. But as AI gets better, people will want that. That'll be key to becoming productive with AI: being able to connect it up to all those things. So MCP is also sort of a bet on the future, where this is all going, and how important that'll be.

Yeah. I would say any API attribute that says formatted_ should kind of be gone, and we should just get the raw data from all of them, because why are you formatting for me? The model is definitely smart enough to format an address, so I think that should go to the end user.

Yeah, I think Alessio is about to move on to server implementation. We're still talking about MCP design, goals, and intentions, and we've indirectly identified some problems that MCP is really trying to address. But I wanted to give you the spot to directly take on MCP versus OpenAPI, because obviously this is a top question.

I wanted to recap everything we just talked about and give people a nice little segment that they can say is a definitive answer on MCP versus OpenAPI.

I think fundamentally, OpenAPI specifications are a very great tool, and I've used them a lot in developing APIs and consumers of APIs. I think fundamentally—or we think—that they're just too granular for what you want to do with LLMs. They don't express higher-level, AI-specific concepts, like this whole mental model that we've talked about with the primitives of MCP and thinking from the perspective of the application developer.

You don't get any of that when you encode this information into an OpenAPI specification. So we believe that models will benefit more from purpose-built or purpose-designed tools, resources, prompts, and the other primitives than just, “Here's our REST API; go wild.”

I do think there's another aspect. I'm not an OpenAPI expert, so everything might not be perfectly accurate, but I do think that there's been a deliberate design decision to make the protocol somewhat stateful, because we really believe that AI applications and AI interactions will become inherently more stateful. The current need for statelessness is more a temporary point in time; to some degree, that will always exist, but I think more statefulness will become increasingly popular.

This is particularly true when you think about additional modalities that go beyond pure text-based interactions with models. It might be video, audio, or whatever other modalities exist out there already. I do think that having something a bit more stateful is inherently useful in this interaction pattern.

I do think they're actually more complementary—OpenAPI and MCP—than people want to make it out. People look for these A-versus-B comparisons and want all the developers of these things to go in a room and fistfight it out, but that's rarely what's going on.

I think they're actually very complementary, and they each have their space where they're very strong. Just use the best tool for the job. If you want to have a rich interaction between an AI application, it's probably MCP that's the right choice. If you want to have an API spec somewhere that's very easy for a model to read and interpret, and that's what works for you, then OpenAPI is the way to go.

One more thing to add here is that we've already seen people—I mean, this happened very early—build bridges between the two as well. So if what you have is an OpenAPI specification and no one's building a custom MCP server for it, there are already translators that will take that and re-expose it as MCP. You could do it the other direction, too.

Awesome. I think there's another side of MCP that people don't talk about as much, because it doesn't go viral, which is building the servers. Everybody does the tweets about, “I connected Claude Desktop to an MCP server. It's amazing.”

How would you guys suggest people start with building servers? The spec is so broad—there are so many things you can do—that it's almost like, how do you draw the line between being very descriptive as a server developer versus, going back to our discussion before, just taking the data and letting the model manipulate it later? Do you have any suggestions for people?

I think I have a few suggestions. One of the best things about MCP, and something that we got right very early, is that it's very easy to build something very simple that might not be amazing, but it's good enough because models are very good. You can get this going within half an hour.

I think the best part is to pick the language of your choice that you love the most, pick the SDK for it if there's an SDK, and just go build a tool for the thing that matters to you personally and that you want to see the model interact with. Build the server, throw the tool in, and don't worry too much about the description just yet. Do a bit of writing—write your little description as you think about it—and just give it to the model. Then throw it through the standard I/O transport into an application that you like and see it do things.

I think that's part of the magic—or empowerment and magic—for developers: getting so quickly to something that the model does, something that you care about. That really gets you going and gets you into this flow of, “Okay, I see this, and it can do cool things. Now I can expand on this, and I can really think about which different tools I want, and which different raw resources and prompts I want.”

Now that I have that, what do my evals look like for how I want this to go? How do I optimize my prompts for the evals using tools like that? This is infinite depth that you can go into, but just start as simply as possible. Go build a server in half an hour in the language of your choice and see how the model interacts with the things that matter to you.

I think that's where the fun is. A lot of what makes MCP great is that it just adds a lot of fun to the development process, letting models do things quickly.

I'm also quite partial to using AI to help me do the coding. Even during the initial development process, we realized it was quite easy to basically just take all the SDK code—again, what David suggested: pick the language you care about, and then pick the SDK—and once you have that, you can literally just drop the whole SDK code into an LLM's context window and say, “Okay, now that you know MCP, build me a server that does this, this, this.”

The results, I think, are astounding. It might not be perfect around every single corner, and you can refine it over time, but it's a great way to one-shot something that basically does what you want, and then you can iterate from there.

Like David said, there has been a big emphasis from the beginning on making servers as easy and simple to build as possible, which certainly helps with an LLM doing it, too. We often find that getting started is 100–200 lines of code in the language of your choice. It's really quite easy.

And if you don't have an SDK, give the subset of the spec that you care about to the model, along with another SDK, and just have it build you an SDK. It usually works for that subset. Building a full SDK is a different story, but getting a model to tool-call in Haskell or whatever language you like is probably pretty straightforward.

Yeah, sorry. I was going to say that I co-hosted a hackathon at the AGI House on personal agents, and one of the personal agents somebody built was an MCP server-builder agent. They would basically put in the URL of an API spec, and it would build an MCP server for them.

Do you see that today as most servers being just a layer on top of an existing API, without too much opinion about how it works? Do you think that's how it's going to be going forward—just AI-generated exposure of an API that already exists—or are we going to see net-new MCP experiences that you couldn't do before?

I think both. There will always be value in, “I have my data over here, and I want to use some connector to bring it into my application over here.” That use case will certainly remain.

I think a lot of things today are maybe defaulting to tool use when some of the other primitives would be more appropriate over time. It could still be that the connector is just that sort of adapter layer, but it could actually adapt it onto different primitives, which is one way to add more value.

But I also think there's plenty of opportunity for use cases—or for MCP servers—that do interesting things in and of themselves and aren't just adapters. Some of the earliest examples of this were the Memory MCP server, which gives the LLM the ability to remember things across conversations, and the Sequential Thinking MCP server, which gives a model the ability to really think step by step and get better at its reasoning capabilities. The latter was built by a coworker—not a close one, I should say.

This was something where it really isn't integrating with anything external. It's just providing this sort of way of thinking for a model. I guess either way, though, I think AI authorship of the servers is totally possible. I've had a lot of success prompting: “Hey, I want to build an MCP server that does this thing.” Even if this thing is not adapting some other API but is doing something completely original, it's usually able to figure that out, too.

Yeah, I do think that—to add to that—a good part of what MCP servers will be is API wrappers, to some degree. And that's good and valid because that works, and it gets you very, very far. But I think we're just very early in exploring what you can do. As client support for certain primitives gets better—we can talk about sampling, which was my favorite topic and greatest frustration at the same time—I think you can very easily see way, way richer experiences. We've built them internally as prototypes, and I think you see some of that in the community already.

But there are things like, “Hey, summarize my favorite subreddits for the morning”—an MCP server that nobody has built yet, but it's very easy to envision, and the protocol can totally do this. These are slightly richer experiences. I think as people move away from, “I'm just in this new world where I can hook up the things that matter to me to the LLM,” to, “Actually, I want a real workflow, a richer experience that I really want to expose to the model,” then you will see these things pop up. But again, there's a little bit of a chicken-and-egg problem at the moment with client support versus what authors want to do.

Yeah, that was kind of my next question on composability. How do you guys see that? Do you have plans for that? What's the import of MCPs, so to speak, into another MCP? If I want to build the subreddit one, this is probably going to be the Reddit API MCP and then the summarization MCP. How do I do a super MCP?

So this is an interesting topic, and I think there are two aspects to it. The one aspect is: How can I build something agentically that requires an LLM call in one form or fashion, like for summarization, while staying model-independent? That's where part of this bidirectionality comes in, in this richer experience. We do have this facility for servers to ask the client—again, who owns the LLM interaction? We talk about Cursor, which runs the loop with the LLM for you—for the server author to ask the client for a completion and basically have it summarize something for the server and return it back.

So now, what model summarizes this depends on which one you have selected in Cursor, not on what the author brings. The author doesn't bring an SDK or have an API key. It's completely model-independent how you can build this. This is one aspect of that.

The second aspect to building richer systems with MCP is that you can easily envision an MCP server that serves something to a client like Cursor, Windsurf, or Claude Desktop, but at the same time is also an MCP client itself and can use MCP servers to create a richer experience.

Now you have a recursive property, which we actually, quite carefully, in the design principles, try to retain. You see it all over the place in authorization and other aspects of the spec, where we chain this recursive pattern. Now you can think about, okay, I have this little bundle of an application that's both a server and a client, and I can add these in chains and build basically graphs—DAGs—out of MCP servers that can richly interact with each other.

An MCP server can also use the whole ecosystem of MCP servers available to it, and I think that's a really cool thing you can do. People have experimented with this, and I think you'll hopefully see more of this, particularly when you think about auto-selecting and auto-installing. There are a bunch of these things you can do that make for a really fun experience.

Practically, there are some niceties we still need to add to the SDKs to make this really simple and easy to execute on, like this kind of recursive MCP server that is also a client, or multiplexing together the behaviors of multiple MCP servers into one host, as we call it. These are things we definitely want to add. We haven't been able to yet, but I think that would go some way to showcasing these things that we know are already possible but not necessarily taken up that much yet.

Okay, this is very exciting, and I'm sure a lot of people get a lot of ideas and inspiration from this. An MCP server that is also a client—is that an agent? What's an agent? There are a lot of definitions of agent, because in some ways you're requesting something and it's going off and doing stuff that you don't necessarily know. There's a layer of abstraction between you and the ultimate raw source of the data. You could dispute that. I don't know if you have a hot take on agents.

I do think that you can build an agent that way. For me, I think you need to define the difference between an MCP server plus client that is just a proxy versus an agent. I think there's a difference, and I think that difference might be, for example, using a sampling loop to create a richer experience—to have a model call tools inside that MCP server through these clients. I think then you have an actual agent. I do think it's very simple to build agents that way.

Yeah, I think there are maybe a few paths here. It definitely feels like there is some relationship between MCP and agents. One possible version is: Maybe MCP is a great way to represent agents. Maybe there are some features or specific things that are missing that would make the ergonomics of it better, and we should make that part of MCP. That's one possibility.

Another is maybe MCP makes sense as a foundational communication layer for agents to compose with other agents or something like that. Or there could be other possibilities entirely. Maybe MCP should specialize and narrowly focus on the AI application side, and not as much on the agent side. I think it's a very live question, and I think there are trade-offs in every direction.

Going back to the analogy of the god box, I think one thing that we have to be very careful about in designing a protocol and curating or shepherding an ecosystem is trying to do too much. You don't want a protocol that tries to do absolutely everything under the sun, because then it'll be bad at everything, too. And so I think the key question, which is still unresolved, is: To what degree are agents really naturally fitting into this existing model and paradigm, or to what degree is it basically orthogonal and should be something else?

I think once you enable two-way communication and once you enable the client and server to be the same in delegating work to another MCP server, it's definitely more agentic than not. But I appreciate that you keep in mind simplicity and not trying to solve every problem under the sun.

Cool, I'm happy to move on there. I'm going to double-click on a couple of things that I marked out because they coincide with things that we wanted to ask you anyway. The first one is just a simple question: How many MCP things can one implementation support? This is the sort of wide-versus-deep question. This is directly relevant to the nesting of MCPs that we just talked about.

In April 2024, when Claude was launching one of its first context windows—the first 1-million-token context window—they said you can support 250 tools. To me, that's wide in the sense that you don't have tools that call tools; you just have the model and a flat hierarchy of tools. But obviously, you have tool confusion: When tools are adjacent, you're going to call the wrong tool and get the bad result, right? Do you have a recommendation for a maximum number of MCP servers that are enabled at any given time?

I think, to be honest, there's not one answer to this because, to some extent, it depends on the model you're using. To some extent, it depends on how well the tools are named and described for the model to avoid confusion. I think the dream is certainly that you just furnish all this information to the LLM and it can make sense of everything. This kind of goes back to the future we envision with MCP: All this information is just brought to the model, and it decides what to do with it.

But today, the reality or the practicalities might mean that maybe, in your client application—the AI application—you do some filtering over the tool set. Maybe you run a faster, smaller LLM to filter to what's most relevant and then only pass those tools to the bigger model. Or you could use an MCP server that's a proxy to other MCP servers and does some filtering at that level, or something like that. I think hundreds, as you referenced, is still a fairly safe bet, at least for Claude. I can't speak to the other models. But over time, we should just expect this to get better.

So we're wary of constraining anything.

Yeah, and obviously it highly depends on the overlap of the descriptions, right? If you have very separate servers that do very separate things, and the tools have very clear, unique names and well-written descriptions, your mileage might be way higher than if you have a GitLab and a GitHub server at the same time in your context. Then the overlap is quite significant because they look very similar to the model, and confusion becomes easier.

There are different considerations, too, depending on the AI application. If you're trying to build something very agentic, maybe you are trying to minimize the number of times you need to go back to the user with a question, or minimize the amount of configurability in your interface. But if you're building other applications—an IDE or a chat application or whatever—I think it's totally reasonable to have affordances that allow the user to say, "At this moment, I want this feature set," or, "At this moment, I want this different feature set," or something like that. Maybe you don't treat it as always on to the fullest, always on all the time.

Yeah, that's where I think the concepts of resources and tools get to blend a little bit, right? Because now you're saying you want some degree of user control, or application control, and other times you want the model to control it, right? So now we're choosing just subsets of tools. I don't know.

Yeah, I think it's a fair point, or a fair concern. I guess the way I think about this is still, at the end of the day—and this is a core MCP design principle—ultimately, the client application, and by extension the user, should be in full control of absolutely everything that's happening via MCP.

When we say that tools are model-controlled, what we really mean is that tools should only be invoked by the model. There really shouldn't be an application interaction or a user interaction where it's like, "Okay, as a user, I now want you to use this tool." Occasionally, you might do that for prompting reasons, but I think that shouldn't be a UI affordance.

But I think the client application or the user deciding to filter out things that MCP servers are offering is totally reasonable, or even to transform them. You could imagine a client application that takes tool descriptions from an MCP server and enriches them, makes them better. We really want the client applications to have full control in the MCP paradigm.

In addition, though, I think there's one thing that's very early in my thinking: There might be an addition to the protocol where you want to give the server author the ability to logically group certain primitives together, potentially, to inform that, because they might know some of these logical groupings better. That could encompass prompts, resources, and tools at the same time.

Personally, my take would be that those should be separate MCP servers, and then the user should be able to compose them together, but we can figure it out.

Is there going to be an MCP standard library, so to speak, of, "Hey, these are the canonical servers. Do not build this; we're just going to take care of those"? Could those be the building blocks that people can compose, or do you expect people to just rebuild their own MCP servers for a lot of things?

I think we will not be prescriptive in that sense. I think there is inherently a lot of power—well, let me rephrase it. I have a long history in open source, and I feel the bazaar approach to this problem is somewhat useful, right? I think the best and most interesting option wins, and I don't think we want to be very prescriptive.

I can definitely foresee—and this already exists—that there will be 25 GitHub servers and 25 Postgres servers and whatnot. That's all cool and good, and I think they all add in their own way. But eventually, over months or years, the ecosystem will converge to a set of very widely used ones who are basically—I don't know if you call it winning—but will be the most-used ones. I think that's completely fine, because being prescriptive about this, I don't think is of any use.

I do think, of course, that there will be MCP servers, and we see them already, that are driven by companies for their products. They will inherently probably be the canonical implementation. If you want to work with Cloudflare Workers and use an MCP server for that, you'll probably want to use the one developed by Cloudflare.

I think there's maybe a related thing here, too. One big thing we're thinking about—we don't have any solutions completely ready to go—is this question of trust, or vetting is maybe a better word. How do you determine which MCP servers are the good and safe ones to use?

There could be multiple implementations of GitHub MCP servers that are totally fine, but you want to make sure that you're not using ones that are really sus, right? We're trying to think about how to endow reputation. Hypothetically, if Anthropic says, "We've vetted this; it meets our criteria for secure coding," how can that be reflected in this open model where everyone in the ecosystem can benefit?

I don't really know the answer yet, but that's very much top of mind.

But I think that's a great design choice of MCP, which is already language-agnostic. To my knowledge, there's not an official Anthropic Ruby SDK or an OpenAI SDK, and Alex Rudall does a great job building those. But now with MCP, you don't actually have to translate an SDK to all these languages; you just do one interface and kind of bless that interface as Anthropic. So, yeah, that was nice.

I have a quick answer to this thing. Obviously, there are 5 or 6 different registries already popping up. You guys announced your official registry. A registry is very tempting to offer download counts, likes, reviews, and some kind of trust thing. I think it's kind of brittle. No matter what kind of social proof or other thing you can offer, the next update can compromise a trusted package, and actually that's the one that does the most damage, right?

Abusing the trust system is like—setting up a trust system creates the damage from the trust system. So I actually want to encourage people to try out MCP Inspector, because all you've got to do is actually look at the traffic. I think that goes for a lot of security issues.

Yeah, absolutely. I think it's this very classic supply-chain problem that all registries effectively have. There are different approaches to this problem: You can take the Apple approach and vet things, and have an army of both system and review teams to do this, and then you effectively build an App Store.

That's one approach to this type of problem. It kind of works in a certain set of ways, but I don't think it works in an open-source ecosystem, for which you always have a registry kind of approach, similar to npm packages and PyPI. They all inherently have these supply-chain attack problems, right?

Yeah, totally. Quick time check: I think we're going to go for another 20–25 minutes. Is that okay for you guys?

Okay, awesome. Cool. I wanted to double-click and take the time. We previewed a little bit of the future-coming stuff, so I want to leave that to the end—registry, stateless servers, remote servers, and all the other stuff.

But I wanted to double-click a little bit more on the launch: the core servers that are part of the official repo, and some of them are special ones, like the ones we already talked about. Let me just pull them up.

For example, you mentioned memory. You mentioned sequential thinking. I really encourage people to look at these, what I call special servers. They're not normal servers in the sense that they wrap some API, and it's just easier to interact with those than to work with the APIs.

I'll highlight the memory one first, just because I think there are a few memory startups, but actually you don't need them if you just use this one. It's also 300 lines of code. It's super simple. Obviously, if you need to scale it up, you should probably use something more battle-tested. But if you're just introducing memory, I think this is a really good implementation. I don't know if there's a special story that you want to highlight with some of these.

No, I don't think there's anything particularly special. A lot of these, not all of them, but a lot of them originated from the hackathon that I mentioned before, where folks got excited about the idea of MCP.

People internally inside Anthropic who wanted to have memory or wanted to play around with the idea could quickly prototype something using MCP in a way that wasn't possible before. You don't have to become the end-to-end expert, and you don't have to have access to some private, proprietary codebase. You can now extend Claude with this memory capability.

That's how a lot of these came about, and then also just thinking about what breadth of functionality we want to demonstrate at launch.

Totally. I think that is partially why it made your launch successful: you launched with a sufficiently spanning set of examples, and then people just copy-paste and expand from there. I would also highlight the filesystem MCP server, only because it has file editing. People were very excited when we had Eric, who built a sort of benchmark project, on the podcast as well. People were very interested in this kind of file-editing tool that is open source through this project.

There are some libraries and other implementations out there where this is core IP for them, and now you guys just put it out there. It’s really cool.

Yeah, honestly, the filesystem server is one of my favorites. I was hacking on a game as a side project and really wanted to connect it to Claude and Artifacts, like David talked about before. Suddenly being able to give Claude the ability to actually interact with my local machine was huge. I really love that sort of capability.

Yeah, this is the classic example of a server that directly comes out of the frustration that created both MCP and that server. There was a very clear, direct path from, “Here’s the frustration we’re currently having,” to MCP, plus this server that we both felt—and Justin in particular.

In that regard, it’s close to our hearts as a spiritual inception point of the protocol itself.

Absolutely. The last thing I’ll highlight is sequential thinking, which we already talked about. This gives you branching, which is kind of interesting. It gives you a sort of, “I need more space to write,” which is super interesting.

One thing I also wanted to clarify was that Anthropic put out a new engineering blog this past week with the think tool, and there’s been some community confusion about how sequential thinking overlaps with the think tool. I think there are different teams doing similar things in different parts of the world, but I wanted to let you guys clarify.

As far as I know, there is no common lineage between these 2 things, but I think it speaks to a larger thing: There are many different strategies to get an LLM to be more thoughtful or holistic, or whatever it might be, to express these different dimensions more fully or more reliably.

I think this is the power of MCP: You could build different servers that do these different things, or have different products or different tools within the same server that do these different things, and ask the LLM to apply a particular mental model or thinking pattern for different results. I don’t know that there will be 1 ideal, prescribed method—“LLM, here’s how you should think all the time.” I think there will be different applications for different purposes, and MCP allows you to do that.

Yeah. In addition, there’s also the approach where some MCP servers are filling a gap that existed at a point in time, and the models later catch up by themselves. There’s training time and preparation research that goes into making models do things natively, so to speak.

You can get a lot of mileage out of something as simple as a sequential-thinking tool server. It’s not simple, but it’s doable within a few days, which is definitely not the timeframe you’d look at for adding thinking to a model natively.

I guess, to come up with an example on the fly, if I’m working with a model that is not particularly reliable—or maybe someone considers the generation today overall not particularly reliable—I could imagine building an MCP server that gives me best of 3 tries: 3 attempts to answer a query with the model, and then it picks the best one or something like that. You could get this kind of recursive and composable LLM interaction with MCP.

Awesome. Okay, cool. I think we have time for just future roadmap things. Thanks for indulging me on some of the servers; I just wanted to double-click on these.

People were most excited about this recent update, moving from stateful to stateless servers. You picked SSE as your launch transport protocol, and obviously transport is pluggable. Behind the scenes, was it Jared Palmer’s tweet that caused it, or were you already working on it?

No. We have GitHub discussions going back months in public, really talking about this dilemma and the trade-offs involved. We do believe that the future of AI applications, ecosystems, agents—all of these things—will be stateful, or will move more in the direction of statefulness.

This is one of the most contentious topics we’ve discussed as the core MCP team. We’ve gone through multiple iterations and back-and-forth, but ultimately came back to the conclusion that if the future looks more stateful, we don’t want to move away from that paradigm completely.

Now we have to balance that against the fact that it’s been operationally complex. It’s hard to deploy an MCP server if it requires a long-lived, persistent connection. The original SSE transport design is basically: You deploy an MCP server, a client can come in and connect, and then you should remain connected indefinitely. That’s a tall order for anyone operating at scale. It’s not a deployment or operational model you really want to support.

We were trying to think about how we could balance the belief that statefulness is important with simpler operation and maintenance. The new transport, which we’re calling the Streamable HTTP transport, still has SSE in it, but it has a more gradual approach. A server could be plain HTTP, with 1 endpoint that you send HTTP POSTs to and get a result back, and then you can gradually enhance it: “Now I want the results to be streaming,” or, “Now I want the server to be able to issue its own requests.”

As long as the server and client both support resuming sessions—disconnecting and coming back later to pick up where you left off—you get the best of both worlds. It can still be a stateful interaction and a stateful server, while allowing you to horizontally scale more easily, deal with spotty network connections, or handle whatever the case may be.

As you mentioned, session IDs, how do you think about going forward? For some MCPs, I just need to paste my API key into the command. What do you see as the future of that? Is there going to be an equivalent of OAuth for MCPs?

We do have authorization as a specification in the current draft of the next revision of the protocol. At the moment, it’s mostly focused on user-to-server authorization using OAuth 2.1, or a subset of modern OAuth, basically.

That seems to be working well for people building on top of it, and it will solve a lot of these issues because you don’t really want to have people bring API keys, particularly when you think about a world—which I truly believe will happen—where the majority of servers will be remote servers. You need some sort of authorization with that server.

For the local case, authorization is defined on the transport layer and requires framing, which means headers, effectively. This does not work in stdio. But in stdio, you run locally and can do whatever you want anyway. You might just pop open a browser and deal with it that way.

There’s also some thinking, which is not fully decided, about even using HTTP locally, which would solve that problem. Justin is laughing because he’s very much in favor of this, whereas I’m very much not in favor of it, so there’s some debate going on there.

Authorization, like everything in the protocol, is fairly minimal. It tries to solve a very practical problem and be minimal in what it does. Then we go from there and add based on the practical pain points people have on top of the protocol. We don’t try to overdesign it from the beginning. We’ll just see how far our current spec gets us, basically.

I want to build on that a bit, because I think that last point is really important. When you’re designing a protocol, you have to be extremely conservative, because if you make a mistake, you basically can’t undo that mistake, or you break backward compatibility.

It’s far easier to only accept—or only add—things that you’re extremely certain about, and let people do ad hoc extensions until maybe there’s more consensus that something is worth adding to the core thing and supporting indefinitely going forward.

With OAuth in particular, and this example of API keys, I think this is really illustrative. We did a lot of brainstorming: “Okay, if I have this use case, could I accomplish that with this version of OAuth?” I think the answer is yes for the API key example. You can have an MCP server that is an OAuth authorization server, and at the authorization webpage it just has a text box for you to put in an API key. That would be a totally valid OAuth flow for the MCP server.

Maybe not the most ergonomic, or not what people would ideally like, but because it fits into the existing paradigm and is possible today, why worry about adding too many other options that both clients and servers need to think about?

Have you guys given scopes any thought? We had an episode with Dharmesh Shah from Agent.ai and HubSpot yesterday, and he gave the example of email. He has all of his emails, and he would like to have more granular scopes—for example, you can only access certain types of emails or emails to a particular person. Today, most scopes are REST-driven; they define which endpoints you can access. Do you see a future in which the model acts as the scope layer, so to speak, and dynamically limits the data that passes through?

I think there is a potential need for scopes. We have had discussions around this, but what we're currently trying to do is root them in very specific examples and have a good set of actual problems that you cannot currently solve with the existing implementations. That's the bar we set for adding something to the protocol.

Then, based on that, we prototype using the extensibility that we have at the moment, where every structure that's returned is extensible. We build on top of that, prove that it will have a good user experience, and then put it into the protocol. That's usually been the case, for the most part. It has not quite been the case for authorization in general; that has been a bit more top-down.

But I can totally see why people want it. It's just a matter of showcasing the specific examples and what the potential solutions would be, so that we don't accidentally run into an approach where it sounds roughly right, we put it in, and it turns out not to be right. Now you're back to this idea that adding is easy and removing is hard in protocol design, so we're just a little bit careful around this.

That being said, every time I hear the rough description, it makes sense. I would love to have a very practical, end-to-end user example of this and where the current implementation falls apart. Then we can have a discussion.

There's a little bit of weariness from my perspective, too. Maybe not with scopes specifically—I think those could make a lot of sense as long as we have the use cases in mind. But I do think, when thinking about composability and logical groupings of things, it often makes sense for MCP servers to be quite small.

If you want lots of collections of functionality, those should be discrete servers that you combine together as a user or in the application layer. Some of the pushback about OAuth has been, “If I need to authorize with 20 different things on the other side, how can I do that?” Maybe that's not what the server should be doing. Maybe it shouldn't be connecting to 20 different things; maybe those should be separate servers that combine somehow.

Awesome. Lots of discussion there. Where should people go if they want to get involved in these debates? Is it just the specification repository's discussion page?

That is a good start. I want to caveat it slightly: on the internet, it's very easy to be part of a discussion and have an opinion without actually doing the work. We are both very old-school open-source people, and it's merit-driven in the sense that if you have done the work and showcase it with practical examples and work in SDKs toward the extensions you want to make, 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, because there's a limit to how many discussion points we can read. Of course, we value the discussion and want to have it, but we also need to manage our time and engagement. We obviously select for the people who are doing the most work.

We're trying to figure out how to make this scalable. Even compared to open-source work I've done in the past, the sheer volume of conversation and notifications around MCP is extraordinary, which is great on one hand. But I think we do need to figure out more scalable structures to engage with the community while also keeping conversations high-signal and effective.

Something else to be aware of, related to David's point, is that I do believe a big part of running a successful open-source project is sometimes making hard decisions that people will be unhappy about. You just have to figure out the actual vision for the project: where do we, as the maintainers or shepherds, believe it's going?

You have to commit to that and understand that some people won't agree with the vision, and that's totally fine. Maybe there will be other projects that are more in line with what they're hoping for.

Yeah, fortunately neither of you are new to that. I would also say there's a lot of history to be drawn from Facebook open source, right? Both of you, if you weren't directly involved, know everyone who was directly involved.

I would say React—we eventually started working groups because I was obviously deeply part of the React ecosystem. We eventually started working groups where it was open and conducted in discussions, and each member of the working group had a voice that represented a significant part of the community but also showed that they did the work. They had significance; they weren't drive-by people with no skin in the game. I think that was helpful for a while.

I'm not sure it's an actively managed thing because of React's own issues with the multi-company situation they're in. The other thing that's more interesting to me is GraphQL, because MCP currently has the hype that GraphQL had. I lived through that one, and eventually Facebook donated GraphQL to an open-source foundation.

I think there's a question of whether you want to do that. There are trade-offs; it's not a clear yes or no. Obviously, most people are happy with Anthropic and with you guys because you created it and are the stewards. But at some point, at some scale, you're going to hit a ceiling where you're thinking, “This is owned by one company, and eventually people want a truly open standard: a nonprofit, multiple stakeholders, and a good governance process, governed by the Linux Foundation, Apache, or whatever.”

So I want to ask: any thoughts there? I personally would say it's too early. What are your thoughts?

Yeah, I think governance in general is a super interesting problem in the open-source space. There are 2 things. On the one hand, we really, really want to make this—and have this be—an open standard, an open protocol, and an open project, with participation from everyone who wants to partake. I think that is working quite well so far.

If you look at the pull requests, for example, a lot of the input on the Streamable HTTP work came from companies like Shopify and others that had discussed and worked on this and brought proposals to the table. I think that works really well.

The thing that we're a bit worried about is any type of official standardization, particularly going through an actual standardization body, or any type of foundational work that starts having processes as part of this to stay somewhat fair to everyone. That can add process that, in a fast-moving field like AI, can be detrimental to the project, and that's what we worry about. We worry about processes that are slowing us down.

We're trying to find this nice middle ground: how can we have participation—which we luckily do have from everyone—work toward everyone's problems with the governance model and figure out the right path forward without accidentally slowing down the project? I think that's what we're trying to do.

We genuinely want this to be an open project. Yes, it was initiated by Anthropic, and David and I work at Anthropic, but we don't want it to be seen as Anthropic's protocol.

I think it’s very important for the whole ecosystem that this is something that any AI lab could have a stake in, contribute to, or make use of. But it’s balancing that against avoiding death by committee, basically. I think there are a lot of models for doing this successfully in open source. Most of the difficulties are really around corporate sponsorship and corporate say, and we’ll navigate that as it comes up. But we absolutely want this to be a community project.

That being said, I want to highlight this: At the moment, as we speak, there are plenty of people who aren’t Anthropic employees who have commit access and admin access to the repositories. Some people from Pydantic have commit access to the Python SDK because they did a lot of really good work there. We had a lot of contributions from Block and others to the specification SDKs, like the Java SDK and the C# SDKs. They’re completely done by different companies. The C# one is done by Microsoft. It’s a very recent addition from last week, and they do everything there. They have full admin rights over it.

The same goes for JetBrains doing the Kotlin one and Spring AI doing the Java one. So if you really look at it, it’s already a big, multi-company project with everyone involved. There are a lot of people beyond just the two of us who have commit access and write access to the project as is.

Awesome, guys. This was great. Just to wrap up, do you have any MCP server wishlist? What do you want people to build that isn’t there yet—or a client or server?

I want more sampling clients. That’s all I want. I want someone to build a client that does sampling, and someone else to build me a server that summarizes my Reddit threads or summarizes what happened in EVE Online in the last week for me. I wish someone would do that. But for that, I want a sampling client. I want this to be model-independent—not because I want to use any other model than Claude, because Claude is by far the best, but I just want to have a sampling client for the sake of having a sampling client. Just another video.

I’ll echo that and just broadly say that I think more clients that support the full breadth of the spec would be amazing. We designed things so that they could be adopted incrementally anyway, but it would still be great if all these primitives that we put this thought into got manifested somehow. That would be amazing.

Going back to some of my initial motivation for working on MCP and my excitement about the filesystem server, I like hacking on a game as a side project. I would really love to have an MCP client and/or MCP server with the Godot engine, which I was using to build the game, and just have really easy AI integration with that. Or have Claude run and play-test my game or something, like Claude Plays Pokémon. Who knows?

Hey, at least you have them already built. Has Claude already built your 3D model by now with Blender, right?

But yeah, honestly, even shader code and stuff already—I was just like, “This is not my wheelhouse.” It’s amazing what you can do when you enable builders.

Yeah, we’re actually working on a Claude Plays Pokémon hackathon with David Hershey to bring MCP into that.

I had no plans, but if he wants to, he can.

Awesome, guys. Well, thank you for the time.

Yeah, and keep up the good work.

Thank you both. This was fun.

Yeah, thank you. I really appreciate it. Cheers.