The Creators of Model Context Protocol

Hey. Glad to be here. Welcome.

applications extend themselves or, like, integrate with, you know, an ecosystem of of plugins, basically. 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 that.

But yeah. Another version that we've used and gotten to like is, like, MCP is kinda like the USB c port of AI applications, and that it's meant to be this universal connector to a whole ecosystem of things.

I think. Yeah. I I as soon as David pitched this initial idea, I got excited pretty quickly, and we started working on it, I think, almost immediately after that conversation.

And then, I don't know, it was a couple, maybe a few months of building the really unrewarding bits, if we're being honest, because for establishing something that's like this communication protocol, has clients and servers and SDKs everywhere, There's just like a lot of like laying the groundwork that you have to do, so it was a pretty that was a pretty slow couple months. But then 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. And I think this really came to a head.

I don't remember exactly when it was. Maybe, like, approximately a month before release, there was an internal hackathon where some folks really got excited about MCP and started building all sorts of crazy applications. I think the coolest one of which was like an MCP server that can control a three d printer or something.

And so, like, suddenly, people are feeling this power of, like, Claude connecting to the outside world in a really tangible way, and that that really added some some juice to us and to the release.

Yeah. Absolutely. I mean, we we definitely did take heavy inspiration from LSP.

David had much more prior experience with it than I did, but working on developer tools. So, you know, I've mostly worked on products or sort of infrastructural things, so LSP was new to me. But as a as a, like, or from design principles, it really makes a ton of sense, because it does solve this m times n problem that David referred to, where, you know, in the world before LSP, you had all these different IDEs and editors, and then all these different languages that each wants to support, or that their users want them to support, and then everyone's just building like one off integrations.

And so, like, you use Vim, and you might have really great support for like, honestly, I don't know, C or something. And then like, you switch over to JetBrains, and you have the Java support. But then like, you don't get to use the great JetBrains Java support in Vim, and you don't get to use the great C supported JetBrains or something like that.

So LSP largely, I think, solved this problem by creating this common language that they could all speak, and then, know, you can have some people focus on really robust language server implementations, and then the IDE developers can really focus on that side, and they both benefit. So that was our key takeaway for MCP, is that same principle and that same problem in the space of AI applications and extensions to AI applications. But in terms of concrete particulars, I mean, we did take JSON RPC, and we took 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, like, basically, thinking and like, offering different primitives not because necessarily the semantics of them are very different, but because you want them to show up in the application differently. Like, that was a key sort of insight about how LSP was developed, and that's also something we try to apply to MCP.

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

But then also, already out of the gate, we had three different languages that we wanted to at least support to some degree. That was TypeScript, Python, and then for the Zed integration, it was 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, like, internal ecosystem that we could start playing with.

And then, yeah, I guess just just trying to make everything, like, robust over, like, I don't know, this whole, like, concept that we have for local MCP where you, like, launch subprocesses and stuff and making that robust, that took some time as well.

or, you know, call it desktop or some agent interface or or whatever the case may be, what are the different things that I would want to receive from, like, an integration? And I think once you take that lens, it becomes quite clear that that tool calling is necessary but very insufficient. Like, 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.

So, the kind of core primitives that we started MCP with, we've since added a couple more, but the core ones are really tools, which we've already talked about, is like adding tools directly to the model, or function calling is sometimes called, resources, which is basically bits of data or context that you might want to add to the context, excuse me, to the model context. And this is the first primitive where it's like, we decided this could be application controlled. Like, maybe you want a model to automatically search through and 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, like, you know, pick through a drop down or, like, a paper clip menu or whatever and find specific things and tag them in, and then that becomes part of, like, their message to the LLM.

Like, those are both use cases for resources. And then the third one is prompts, which are deliberately meant to be, like, user initiated or, like, user substituted text or messages. So, like, the analogy here would be, like, if you're an editor, like a slash command or something like that or, like, an at, you know, autocompletion type thing, where it's, like, I have this kind of macro effectively that I wanna drop in and use.

And we have sort of expressed opinions through MCP about the different ways that these things could manifest, but ultimately, it is for application developers to decide, okay, you you get these different concepts expressed differently. And it's very useful as an application developer because you can decide the appropriate experience for each. And actually, this can be a point of differentiation too.

Like, we were also thinking, you know, from the application developer perspective, they you know, application developers don't want to be commoditized. They don't want their application to end up the same as every other AI application. So, like, what are the unique things that they could do to like create the best user experience, even while connecting up to this big open ecosystem of integration?

I yeah.

So so our like, the way we separate these is, like, tools are always meant to be initiated by the model. It's sort of, like, at the model's discretion that it will, like, find the right tool and apply it. So if that if that's the interaction you want as a server developer, where it's like, okay.

This, you know, suddenly I've given the LLM the ability to run SQL queries, for example, that makes sense as a tool. But resources are are more flexible, basically. And I I think, to be completely honest, the story here is practically a bit complicated today because many clients don't support resources yet.

But, like, I think in an ideal world where all these concepts are fully realized and there's, like, full ecosystem support, you would do resources for things like the schemas of your database tables and stuff like that as a way to, like, either allow the user to say, like, okay, now, you know, Claude, I wanna 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, like, you know, it could be something agentic like Cloud Code, is able to just, like, agentically look up resources and find the right schema of the database table you're talking about. Like, both those interactions are are possible. But I think, like, anytime you have this sort of, like, you wanna list a bunch of entities and then read any of them, that makes sense to model as resources.

Resources are also they're uniquely identified by a URI always. And so you can also think of them as, like, you know, sort of general purpose transformers even. Like, if if you wanna support an interaction where a user just, like, drops a u a URI in and then you, like, automatically figure out how to interpret that, you could use MCP servers to do that interpretation.

There's also going back to that perspective of, like, as an application developer, what are the things that I would want? We also apply this thinking to, like, what existing features of applications could conceivably be kind of, like, factored out into MCP servers if you were to take that approach today. And so, like, basically, any IDE where you have, like, an attachment menu, that I think naturally models as resources.

It's just, you know, those implementations already existed. Yeah.

I I think we probably bear responsibility for the Google Maps one, because I think that's one of the reference servers we've released. I mean, in general, for things like, for tool results in particular, we've actually made the deliberate decision, at least thus far, for tool results to be not, like, sort of structured JSON data, not matching a schema, really, but as, like, a text or images or basically, like, messages that you would pass into the LLM directly. And so I guess the the corollary from that is you really should just return a whole jumble of data and trust the LLM to, like, sort through it and sift and, like, you know, extract the information it cares about because that's what that's exactly what they excel at.

And we really try to think about, like, yeah, how how to, you know, use LLMs to their full potential and not maybe over specify and then end up with something that doesn't scale as LLMs themselves get better and better. So really, yeah, I suppose what should be happening in this example server, which, again, will request welcome. That'd be great.

It's like, if all these result types were literally just passed through from the API that it's calling, and then the LLM can can do whatever it wants with the data.

throw AI under the bus a little bit here and just say that Claude wrote a lot of these example servers as well.

If I could add to that real quickly, just one framing as well for MCP is thinking in terms of, like, how crazily fast AI is advancing. I mean, it's exciting. It's also scary.

Like, thinking, us thinking that the biggest bottleneck to, you know, 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, we absolutely care about doing that safely and with the right control and alignment measures in place and everything. But also, as AI gets better, people will want that.

That'll be key to, like, becoming productive with AI is, like, being able to connect them up to all those things. So MCP is also sort of like a a bet on the future and where this is all going and how important that'll be.

OpenAPI specifications are a very great tool. I've used them a lot in developing APIs and consumers of APIs. I think, fundamentally, we think that they're just too granular for what you wanna do with LLMs.

Like, 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. Like, you don't get any of that when you encode this information into an open API specification. So we believe that models will benefit more from what the purpose built or purpose designed tools, resources, prompts, the other primitives than just kind of like, here's our REST API, wild.

between the two as well. So, like, if what you have is an open API specification and no one's building a custom MCP server for it, there are already translators that will take that and reexpose it as MCP, and you could do it the other direction too. Awesome.

I I also, I'm quite partial, again, to using AI to help me do the coding. Like, I think even even during the initial development process, we realized it was quite easy to to basically just take all the SDK code. Again, you know, what David suggested, like, you know, 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. And it like, the results, I think, are astounding. Like, I mean, it might not be perfect around every every single corner or whatever, and you can refine it over time, but, like, it's a great way to kinda, like, one shot something that basically does what you want, and then you can iterate from there.

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

Yeah. I sorry.

I I think Go for it. I think both. Like, I I think there there will always be value in, like, oh, I have, you know, 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, you know, this this kinda goes back to, like, I think a lot of things today are maybe defaulting to tool use when some of the other primitives would be maybe more appropriate over time. And so it could still be that connector.

It could still just be that sort of adapter layer, but could, like, actually adapt it onto different primitives, which is one one way to add more value. But then I also think there's plenty of opportunity for use cases, which, like, do, or for MCP servers that kinda do interesting things in and of themselves and aren't just adapters. Some of the earliest examples of this were, like, you know, the memory MCP server, which gives the LLM the ability to remember things across conversations, or, like, someone's close coworker built the sorry.

I shouldn't have said not a close coworker. Someone built the sequential thinking MCP server, which gives a model the ability to, like, really think step by step and get better at its reasoning capabilities. This is something where it's like, it really isn't integrating with anything external.

It's just providing this sort of, like, way of thinking for a model. I guess either way, though, I I think AI authorship of the servers is totally possible. Like, I've had a lot of success in prompting, just being like, hey.

I wanna build an MCP server that, like, does this thing. And 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.

I I think, practically, there are some niceties we still need to add to the SDKs to make this really simple and, like, easy to execute on, like this kind of recursive MCP server that is also a client or, like, kind of multiplexing

feels like there's some relationship between MCP and agents. One possible version is, like, maybe MCP is a great way to represent agents. Maybe there are some, like, you know, 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, like, maybe MCP makes sense as kinda like a foundational communication layer for agents to, like, compose with other agents or something like that. Or there could be other possibilities entirely.

Maybe MCP should specialize and narrowly focus on kind of 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 sort of trade offs in every direction. Going back to the analogy of the godbox, I think one thing that we have to be very careful about when designing a protocol and kind of curating or shepherding an ecosystem is, like, trying to do too much.

I think it's it's a very big yeah. You know, you don't want a protocol that tries to do absolutely everything under the sun, because then it'll be bad at everything too.

to be honest, like, I I think there's not one answer to this, because to some extent, it depends on the model that you're using. To some extent, it depends on, like, how well the tools are named and described for the model and stuff like that to avoid confusion. I mean, I think that the dream is certainly, like, you just furnish all this information to the LLM, and it can make sense of everything.

This kind of goes back to, like, the future we envision with MCP is, like, all this information is just brought to the model, and it decides what to do with But today, the reality or the practicalities might mean that, like, yeah, maybe you maybe in your client application, like the AI application, you do some filtering over the toolset, or, like, maybe you you run, like, a faster, smaller LLM to like filter to what's most relevant, and then only pass those tools to the bigger model, or you could use an MCP server, which is 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, yeah. I don't know. I think over time, we should just expect this to get better.

There's different considerations too, depending on the AI application. If you're if you're trying to build something very agentic, maybe you are trying to minimize the amount of times you need to go back to the user with a question, or, you know, minimize the amount of, like, configurability in your interface or something.

Yeah. I think it's a fair point or or a fair concern. I I guess the way I think about this is still, like, at the end of the day, and and this is a core MCP design principle, is, like, ultimately, the client application and, by extension, the user, ultimately, they 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, like, tools should only be invoked by the model. Like, 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.

I mean, occasionally, you might do that for prompting reasons, but, like, I think that shouldn't be, like, a UI affordance. But I I think the client application or the user deciding to, like, filter out things that MCP servers are offering, totally reasonable, or even, like, transform them.

I mean, personally, we can have a design discussion on there. I mean, 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.

I think there's maybe a a related thing here too, just about, like, one big thing worth thinking about, we don't have any, like, solutions completely ready to go, is this question of, like, trust or, like, you know vetting is maybe a better word. Like, how do you determine which MCP servers are, like, the kinda good and safe ones to use? Regardless of if there are any implementations of GitHub MCP servers, that could be totally fine, but you wanna make sure that you're not using ones that are really, like, sus.

Right? And so trying to think about, like, how to of endow reputation, or, like, you know, if, hypothetically, Anthropic is, like, we've vetted this, it meets our criteria for secure coding or something, How can that be reflected in in kind of this open model where everyone in the ecosystem can benefit?

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

People internally inside Anthropic who wanted to have memory or, like, wanted to play around with the idea could quickly now prototype something using MCPE in a way that wasn't possible before. Someone who's not, like, you know, you don't have to become the end to end expert. You don't have access to this, like, private, you know, proprietary code base.

You can just now extend Cloud with this memory capability. So that's how a lot of these came about. And then also just thinking about, like, you know, what is the breadth of functionality that we want to demonstrate at launch.

Yeah. I I really I mean, honestly, the file system server is one of my favorites, because I I think it really speaks to, like, a limitation that I was feeling. You know, I was, like, hacking on a a game as a side project, and really wanted to connect it to like Cloud and artifacts, like David talked about before.

Just giving Cloud or like, suddenly being able to give Cloud the ability to like, actually interact with my local machine was huge. I really love that sort of capability.

I mean, there's there's definitely, like sorry. Let me start over. As far as I know, there is no common lineage between these two things, but I think it just speaks to a larger thing that, like, there are many different strategies to get an LLM to be more thoughtful or holistically less or whatever it might be, to to kind of, like, express these different dimensions more fully or more reliably.

And I don't know. I I think this is, like, the power of MCP, that, like, you could build different servers that do these different things, or have, like, you know, different prompts or different tools within the same server that do these different things, and, like, ask the LLM to apply a particular, like, mental model or thinking pattern or whatever for for different results. So I I don't know.

I I think I I I guess don't know that there will be, like, one 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. Right?

I guess to come up with an example on the fly, like I could imagine building, you know, if I'm working with a model that is not particularly reliable, or, you know, maybe someone considers the generation today overall not particularly reliable. Like, I could imagine building an MCP server that gives me, like, best of three, you know, like, three times to answer a query with the model and then picks the best one or something like that. Like, you could get this kind of, like, recursive and composable LLM interactions with MC Awesome.

Okay. Cool. I I think so, you know, we sorry.

Thanks for indulging on on, like, some of the the the service. We just wanted to double click on these. I think we have time for just, like, future roadmap things.

No. We have we have GitHub discussions going back, like, know, in in public going back months, really, talking about this this dilemma and the the trade offs involved. You know, we do believe that, like, the future of AI applications and ecosystem and agents, all of these things, I think, will be stateful or will be more in the direction of faithfulness.

So we we had a lot of I I think, honestly, this is one of the most contentious topics we've discussed as, like, the core MCP team and, like, gone through multiple iterations on and back and forth. But ultimately just came back to this conclusion that, like, if the future looks more stateful, we we don't wanna move away from that paradigm completely. Now we have to balance that against it's it's been operationally complex, or, like, it's hard to deploy an MCP server if it requires this, like, long lived persistent connection.

This this is the original, like, SSE transport design is basically, you deploy an MCP server, and then a client can come in and connect. And then, basically, you should remain connected indefinitely, which is that's like a tall order for anyone operating at scale. It's just like not a a deployment or operational model you really want to support.

So we were trying to think, like, how can we balance the belief that statefulness is important with sort of simpler operation and maintenance and stuff like that. And the new sort of we're we're calling it the streamable HTTP transport that we came up with still has SSE in there, but it has a more, like, a gradual approach, where, like, a server could be just plain HTTP, like, you know, have one endpoint that you send HTTP posts to, and then, you know, get a result back. But then you can, like, gradually enhance it with, like, okay, now I want the results to be streaming, or, like, now I want the server to be able to issue its own requests.

And as long as the server and client both support the ability to, like, resume sessions, like, you know, to disconnect and come back later and pick up where you left off, then you get kind of the best of both worlds, where it could still be the stateful interaction and and stateful server, but allows you to, like, horizontally scale more easily or, like, deal with spotty network connections or or whatever the case may be.

you know, when 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 backwards compatibility. So it's far easier to, like, only accept things or, like, only add things that you're extremely certain about and let people kinda do ad hoc extensions until maybe there's more, like, consensus that something is worth worth adding to the core thing and, like, supporting indefinitely going forward.

And and with auth in particular, and this example of API keys, think this is really illustrative because we we did a lot of this sort of, like, brainstorming, like, okay. If I have this use case, could I accomplish that with this version of auth? And I think the answer is yes for, like, the API key example.

Like, you can have an MCP server, which is an OAuth authorization server, and at the, like, slash authorize web page, it just has, like, a text box for you to put in an API key. Like, 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 does fit into the existing paradigm and is possible today, we're worried about, like, adding too much other too many other options that both then clients and servers need to think about.

description, it makes sense. I would love to have a very practical end to end user example of this and where falls apart the current implementation, then we can have a discussion. There's a little bit of weariness from my perspective too.

Maybe not with scope specifically. I think those could make a lot of sense as long as we have the the use cases in mind. But I do think, you know, in in thinking about composability and logical groupings of things, I think it does often make sense for MCP servers to be quite small things, and if you want lots of collections of functionality for those to be discrete servers that you kinda combine together as a user or in the application layer, and so some of the pushback about auth has been like, well, if I need to authorize with like 20 different things on the other side, how can I do that?

It's like, well, maybe maybe that's not what the server should be doing, and maybe it shouldn't be connecting to 20 different things. Maybe those should be separate servers that combine up somehow. Awesome.

Lots of discussion there. Where should people go if they wanna get involved in these debates?

doing the most work. We're trying to figure out, you know, that honestly, like, I think, even compared to open source work I've done in the past, just the sheer volume of conversation and notifications around MCP stuff is extraordinary, which is great on one hand. But I think we do need to figure out more scalable structures to both engage with the community, but also keep, you know, conversations high signal and, like, effective.

And I guess there's something else to be aware of related to David's point is, like, I do believe that a big part of running a successful open source project is sometimes making hard decisions that people will be unhappy about. And you kind of just have to, like, you know, learn to to, like, figure out, like, what what are the things what what is, like, the actual vision for the project? Where where do we, the kind of, like, maintainers or, like, shepherds or whatever believes that it's going?

And just commit to that, and like understand that some people won't agree with that vision, and that's totally fine. But then maybe maybe there will be other projects that are more in line with what they're hoping for or something like that.

We we do always wanna hear the feedback, and we need to make it scalable, I think, but also just the recognition that, like, sometimes we we will be going with our intuition about what is the right choice. There might be a lot of of, like, flame in the open source discussions about it, but that's just the nature of projects like this sometimes.

we are very genuine in our desire to have this be an open project. And, like, yes, it's it was initiated by Anthropic, and and David and I work at Anthropic. But, like, we don't want it to be seen as, like, this is Anthropic's protocol.

I think it's very important for for the whole ecosystem that this is something that, like, any AI lab could have a stake in or contribute to or or make use of. But, yeah, it's it's just it's it's balancing that against avoiding death by committee, basically. And so, like, I think there are a lot of models for doing this successfully in open source.

I think most of the delicacies are really around, like, you know, sort of corporate sponsorship and and corporate say, and we'll kind of navigate that as it comes up. But we absolutely want this to be like a community project.

more clients that support the full breadth of the spec would be amazing. I mean, we we kinda design things so that things could be adopted incrementally anyway, but, like, still, it would be great if, you know, all these primitives that we've put this this thought into do get manifested somehow. That would be amazing.

But going back to, you know, some of my initial motivation for working on MCP and, like, excitement about the file system server, you know, like, I I like hacking on a game as a side project, so I would really love to have an MCP client and or MCP server with, like, the Godot engine, which I was using to build the game, and just, like, really easy, like, AI integration with that or, like, have, you know, Claude run and play test my game or something. Like, Claude plays Pokemon. Who knows?

Hey, at least you have them already built have Claude already built your three d model from now on with Blender. Right? But yeah.

I mean, honestly, even like shader code and stuff already, was just like, this is not my wheelhouse. It's amazing what you can do when you enable builders. Yeah.

We're we're actually working on Cloudplace Pokemon hackathon with David Hershey.