The Creators of Model Context Protocol

30:48And like I've used them a lot in developing APIs and consumers of APIs. I think fundamentally, or we think that they're just like too granular for what you want to 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 the purpose built or purpose design tools, resources, prompts, and the other primitives than just kind of like, here's our REST API, go wild.

31:22I do think there's another aspect. I think that, and I'm not an open API expert, so everything might not be perfectly accurate, But I do think that we're like, there's been, and we can talk about this a bit more later. There's a deliberate design decision to make the protocol somewhat stateful because we do really believe that AI applications and AI-like interactions will become inherently more stateful. and that the current state of need for statelessness is more a temporary point in time that will, to some degree, that will always exist. But I think more statefulness will become increasingly more popular, particularly when you think about additional modalities that go beyond just pure text-based interactions with models.

32:12It might be video, audio, whatever other modalities exist out there already. And so I do think that like having something a bit more stateful is just inherently useful in this interaction pattern. I do think they're actually more complementary OpenAPI and MCP than if people wanted to make it out. Like people look for these like, you know, A versus B and like, you know, have all the developers of these things go in a room and fistfight it out. But that's rarely what's going on. I think it's actually they're very complementary and they have their little space where they're very, very strong. And I think, you know, just use the best tool for the job.

32:48And if you want to have a rich interaction between an AI application, it's probably like it's probably MCP that's the right choice. And if you want to have like an API spec somewhere that is very easy and like a model can read and interpret and that's what worked for you, then open API is the way to go. One more thing to add here is that we've already seen people. I mean, this happened very early. People in the community built like bridges between the two as well. So like if what you have is an open API specification and no one's, you know, building a custom MCP server for it, there are already like translators that will take that and re-expose it as MCP and you could do the other direction too.

33:25Awesome. Yeah. I think there's the other side of MCPs that people don't talk as much about because it doesn't go viral, which is building the servers. So I think everybody does the tweets about, well, I connect the cloud desktop to X MCP. It's amazing. how would you guys suggest people start with building servers i think the spec is like so there's 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 like going back to our discussion before like just take the data and then let the model manipulate it later do you have any suggestions for people i i think there i have a few suggestions i think that one of the best things i think about mcp and something that we got right very early is that it's just very very easy to build like something very simple that might not be amazing but it's pretty it's good enough because models are very good and get this going within like half an hour you know and so i think that the best part is just like pick the language of you know of your choice that you love the most pick the sdk for it if there's an sdk for it and then just go build a tool of the thing you that matters to you personally and that you want to see the model like interact with build the server throw the tool and don't even worry too much about the description just yet like do a bit of like write your little description as you think about it and just give it to the model and just throw it to standard IO protocol transport wise into like an application that you like and see it do things.

34:49And I think that's part of the magic that, or like, you know, empowerment and magic for developers to get so quickly to something that the model does something that you care about that I think really gets going and gets you into this flow of like, okay, I see this thing can do cool things. Now I go and can expand on this and now I can go and like really think about like which are the different tools I want which are the different resources and prompts I want okay now that I have that okay now do I what what do my evals look like for how I want this to go how do I optimize my prompts for the evals using like tools like that this is infinite depth that you can do but just start as simple as possible and just go go build a server in like half an hour in the language of your choice and and how the model interacts with the things that matter to you and I think that's that's where the fun is that?

35:38And I think people, I think a lot of what MCP makes great is it just adds a lot of fun to the development piece to just go and have models do things quickly. I also, I'm quite partial again to using AI to help me do the coding. Like I think even during the initial development process, we realized it was quite easy to basically just take all the SDK code. But 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.

36:20And like the results I think are astounding. Like, I mean, it might not be perfect around every single corner or whatever, and you can refine it over time. But like, it's a great way to kind of 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 lms doing it too we often find that like really getting started is like you know 100 200 lines of code in the language of your choice it's really quite easy yeah but if you don't have an sdk again give that like give the subset of the spec that you care about to the model and like another sdk and just have it build you an sdk and it usually works for like that subset building a full sdk is a different story but like to get a model to tool call in Haskell or whatever like language you like, it's probably pretty straightforward.

37:11Yeah, sorry. No, I was gonna say I co-hosted a hackathon at the AGI house on personal agents and one of the personal agents somebody built was like an MCP server builder agent where they will basically put the URL of API spec and it will build an MCP server for them. Do you see that today? It's kind of like, yeah, most servers are just kind of like a layer on top of an existing API without too much opinion and how yeah do you think that's kind of like how it's going to be going forward just like AI generated exposed the API that already exists or are we going to see kind of like net new mcp experiences that you couldn't do before I think go for it I think both like I think there there will always be value in like oh I have you know I have my data over here 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 kind of 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 you know or for mcp servers that kind of do interesting things in and of themselves and aren't just adapters.

38:30Some 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 who's a close coworker built the, how I should 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 way of thinking for a model. I guess either way, though, I think AI authorship of the servers is totally possible.

39:10I've had a lot of success in prompting just being like, hey, I want to build an MCB server that 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. Yeah, I do think that the, to add to that, I do think that a good part of what MCP servers will be, will be these like just API wrapper 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 like in exploring what you can do. I mean, I think as client support for like certain primitives get better, like we can talk about sampling with my favorite topic and greatest frustration.

39:51at the same time. I think you can just see it very easily see like way, way, way richer experiences. And we have built them internally for as prototyping aspects. And I think you see some of that in the community already. But there's just, you know, things like, hey, summarize my, you know, my favorite subreddits for the morning MCP server that nobody has built yet. But it's very easy to envision and the protocol can totally do this. And these are like slightly richer experiences. And I think as people like go away from like the oh i just want to like i'm just in this new world where i can hook up the things that matter to me to the llm to like actually want a real workflow a real like like more richer experience that i i really want to expose to the model i think then you will see these things pop up but again that's a there's a little bit of a chicken and egg problem at the moment with like what a client support versus you know what servers like authors want to do yeah that that was kind of my next question on composability like how how do you guys see that do you have plans for that what's kind of like the import of mcps so to speak into another mcp like if i want to build like the subreddit one there's probably going to be like the reddit api mcp and then the summarization mcp and then how do i how do i do a super mcp yeah so so this is an interesting topic and i think they're so there are there are two aspects of it i think that the one aspect is like how can I build something agentically that you requires an LLM call in like a one form or fashion like for summarization or so but I'm staying model independent and for that that's where like part of this by directionality comes in in this more rich experience where we do have this facility for servers to ask the client again who owns the LLM interaction right like we talk about cursor who like runs the loop with the LLM for you there that for the server author to ask the client for a completion and basically have it like summarize something for the server and return it back.

41:52And so now what model summarizes this depends on which one you have selected in cursor and not depends on what the author brings. The author doesn't bring an SDK, doesn't have you had an API key. It's completely model independent how you can build this. This is one aspect to that. The second aspect to building richer systems with MCP is that you can easily envision an mcp server that serves something to like something like cursor or windsurf or a cloud desktop but at the same time also is an mcp client at the same time and itself can use mcp servers to create a rich experience and now you have a recursive property which we actually quite carefully in design principles try to retain you you know you see it all over the place and authorization other aspects to the spec that we retain this like recursive pattern and now you can think about like okay i have this little bundle of applications both a server and a client and i can add these in chains and build basically graphs like dags out of mcp servers that can just richly interact with each other agentic mcp server can also use the whole ecosystem of mcp servers available to themselves and i think that's a really cool environment cool thing you can do and people have experimented with this and i think you see hopefully more of this particularly when you think about like auto selecting auto installing there's a bunch of these things you can do that make and make a really fun experience 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 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 like 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.

43:40Okay. This is very exciting and very, I'm sure a lot of people get a lot of ideas and inspiration from this. Is an MCP server that is also a client, is that an agent? What's an agent? There's a lot of definitions of agents. Because in some ways you're requesting something and it's going off and doing stuff that you don't necessarily know. It's like a layer of extraction 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.

44:16I think there's a difference. And I think the difference might be in, you know, for example, using a sample loop to create a more richer experience, to have a model call tools while like inside that MCP server through these clients. I think then you have an actual agent. Yeah. 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 will make the ergonomics of it better.

44:53And we should make that part of MCP. That's one possibility. Another is maybe MCP makes sense as kind of like 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 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 God box, I think one thing that we have to be very careful about in designing a protocol and kind of curating or shepherding an ecosystem is like trying to do too much.

45:28I think 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. And so I think the key question, which is still unresolved, is like, to what degree are agents really naturally fitting into this existing model and paradigm? Or to what degree is it basically just like orthogonal? It should be something. I think once you enable two-way and once you enable client server to be the same in delegation of 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 on this one.

46:03Cool. I'm happy to move on there. I mean, 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. So the first one is just a simple how many MCP things can one implementation support? So this is the sort of wide versus deep question. And this is direct relevance to the nesting of MCPs that we just talked about. In April 2024, when Cloud was launching one of its first context, the first million token context example, they said you can support 250 tools. And, you know, so to me, that's wide in the sense that you don't have tools that call tools.

46:42You just have the model and a flat hierarchy of tools. But then obviously you have tool confusion. It's going to happen when tools are adjacent, you call the wrong tool, you're going to get the bad result. Right. Do you have a recommendation of like a maximum number of MCP servers that are enabled at any given time? I think, to be honest, like, 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.

47:23This 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 it. 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 tool set. Or like maybe 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 so we're wary of like constraining anything and preventing that that sort of long yeah obviously it highly it highly depends on the overlap of the description right?

48:14Like if you have like very separate servers that do very separate things and the tools have very clear unique names, very clear, well-written descriptions, you know, your mileage might be more higher than if you have a GitLab and a GitHub server at the same time in your context. And then the overlap is quite significant because they look very similar to the model and confusion becomes easier. There's different considerations too, depending on the AI application. If you're trying to build something very agentic, Like 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.

48:51But if you're building other applications, you're building an IDE or you're building a chat application or whatever. Like, I think it's totally reasonable to have affordances that allow the user to say, like, at this moment, I want this feature set or at this different moment, I want this different feature set or something like that. And maybe not treat it as like always on the full list, 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, right? Or application control.

49:20And 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 like, at the end of the day, 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 think the client application or the user deciding to like filter out things that mcb servers are offering totally reasonable or even like transform them.

50:13Like you could imagine a client application that takes tool descriptions from an MCB server and like enriches them, makes them better. We really want the client applications to have full control in the MCB paradigm. That in addition though, like I think there, one thing that's very, very early in my thinking is there might be an addition to the protocol where you want to give the server author the ability to like logically group certain primitives together potentially to inform that because they might know some of these logical groupings better and that could like encompasses prompts, resources and tools at the same time.

50:46I 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 users should be able to compose them together. But we can figure it out. Is there going to be like a MCP standard library, so to speak, of like, hey, these are like the canonical servers. Do not build this. We're just going to take care of those. And those can be maybe the building blocks that people can compose or... Do you expect people to just rebuild their own MCP servers for like a lot of things? I think we will not be prescriptive in that sense.

51:17I think there will be inherently, you know, there's a lot of power. Well, let me rephrase it. Like I have a long history in open source and I feel the bizarre approach to this problem is somewhat useful, right? And I think so that the best and most interesting option wins. And I don't think we want to be very prescriptive. I do. We'll definitely foresee and this already exists that there will be like 25 GitHub servers and like 25, you know, Postgres servers and whatnot. And that's all cool and that's good. And I think they all add in their own way. But effectively, eventually over months or years, the ecosystem will converge to like a set of very widely used ones who basically, I don't know if you call it winning, but like that will be the most used ones.

52:01And I think that's completely fine because be prescriptive about this. I don't think it's any useful, any use. I do think, of course, that there will be like MCP servers and you see them already that are driven by companies for their products. And, you know, they will inherently be probably the canonical implementation. Like if you want to work with Cloudflow workers and use an MCP server for that, you'll probably want to use the one developed by Cloudflare. Yeah. I think there's maybe a related thing here too, just about like one big thing we're thinking about. We don't have any like solutions completely ready to go.

52:34is 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 kind of good and safe ones to use, regardless of if there are an implementations of GitHub MCP servers, that could be totally fine, but you want to make sure that you're not using ones that are really like sus, right? And so trying to think about like how to kind of endow reputation or like, you know, if hypothetically anthropic is like we've vetted this it meets our criteria for for secure coding or something how can that be reflected in in kind of this open model where everyone in the ecosystem can benefit don't really know the answer yet but that's very much toppled out but i think that's like a great design choice of ncps which is like language agnostic like already and there's not to my knowledge an anthropic official ruby sdk nor an open ai sdk and alex rudal that are great does a great job building those but now with mcps it's like you don't actually have to translate an sdk to all these languages you just do one one interface and kind of bless that interface as as anthropic so yeah that was that was nice i have a quick answer to this thing so like obviously there's like five or six different registries already popped up you guys announced your official registry that's gone the way and a registry is very tempting to offer download counts, likes, reviews, and some kind of trust thing.

53:57I think it's kind of brittle. Like 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? So abusing the trust system is like setting up a trust system creates the damage from the trust system. And so I actually want to encourage people to try out MCP Inspector, because all you got to do is like actually just look at the traffic and like i think that's that goes for a lot of security issues yeah absolutely i think it's like this very classic just supply chain problem that like all registries effectively have and the you know there are different approaches to this problem like you can take the apple approach and like vet things and like have a like an army of of both system and review teams to do this and then you effectively build an app store right that's that's one approach to this type of problem.

54:48It kind of works in a very certain set of ways, but I don't think it works in an open source kind of ecosystem for which you always have a registry kind of approach, like similar to NPM and Packagist and PyPy. And they all have inherently these, like, these supply chain attack problems, right? Yeah, yeah, totally. Quick time check. I think we're going to go for another, like, 20, 25 minutes. Is that okay for you guys? Okay, awesome. Cool. I wanted to double click, take the time. So I'm going to sort of, we previewed a little bit on like the future coming stuff. So I want to leave the future coming stuff to the end, like registry, the stateless servers, remote servers, all the other stuff.

55:23But 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. So let me just pull them up already. So for example, you mentioned memory, you mentioned sequential thinking. And I think I really, really encourage people to look at these, what I call special servers. Like 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. And so I'll highlight the memory one first, just because like I think there are a few memory startups, but actually you don't need them if you just use this one.

56:02It's also like 300 lines of code. It's super simple. And obviously then if you need to scale it up, you should probably do some more battle tested thing. But if you're interested, if you're just introducing memory, I think this is a really good implementation. I don't know if there's like special stories that you want to highlight with, with some of these. I think, no, I don't think there's a particular 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 Anthropik who wanted to have memory or like wanted to play around with the idea.

56:39could quickly now prototype something using MCP 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. You don't have to have access to this like private, you know, proprietary code base. You can just now extend Claude 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? Totally. And I think that is partially why it made your launch successful because you launch with a sufficiently spanning set of here's examples and then people just copy paste and expand from there i would also highlight the file system mcp server only because it has edit file and basically i think people were very excited when we had eric who built your sort of sweet bench projects on the podcast as well and people were very interested in this sort of like file editing tool that is basically open source via this project and and i think a lot of there's some libraries out there there's some other implementations that like you know this is core ip for them and now it's just you guys just put it out there it's just really cool yeah i i really i mean honestly the file system server is one of my favorites because i think it really speaks to like a limitation that i was feeling you know i was like hacking on a game as a side project and really wanted to connect it to like Claude and artifacts like David talked about before just giving Claude or like suddenly being able to give Claude the ability to like actually interact with my local machine was huge I really love that sort of capability yeah I mean this is this is the classic example of like this server directly comes out of the frustration that both created MCP and that server there was a very clear direct path of like here's the frustration we're currently having to mcp plus the server that that we both have felt and justin in particular so that regard is close to our heart as like as as a spiritual inception point of the protocol itself so okay and then i think the last thing i'll highlight is sequential thinking which you already talked about this is this gives like branching which is kind of interesting it gives sort of you know i need more need more space to write which is kind of super interesting and i think one thing i also wanted to clarify was anthropic this week well this past week put out a new engineering blog with a think tool and there's a bit of community confusion how sequential thinking overlaps with the think tool i just think that it's just different teams doing similar things in different parts of the world but i just want to let you guys clarify i think I mean, there's definitely like, sorry, let me start over.

59:27As 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 hallucinating less or whatever it might be to kind of like express these different dimensions more fully or more reliably. And I don't know, 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 products 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 different results.

1:00:08So I don't know. I think I guess don't know that there will be like one ideal prescribed method like 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? Yeah, I think in addition, there's also like the way that the approach to this, that some of the MCP servers, they're filling a gap that existed at a point in time that the models later catch up to by themselves. Because, you know, they have this training time and preparation, at least research that goes into making models do things natively. so to speak.

1:00:50And you can get a lot of mileage of something as simple as a sequential thinking tool like server. It's not simple, but it's like it's doable within a few days, which is definitely not the time frame you look at adding thinking to a model natively. 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, tries like three times to answer a query with the model and then picks the best one or something like that.

1:01:27Like you could get this kind of like recursive and composable LLM interactions with MCP. Awesome. Okay, cool. I think so, you know, sorry, thanks for indulging on like some of the servers. I just wanted to double click on these. I think we have time for just like future roadmap things people were most excited about this recent update moving from stateful to stateless servers you guys picked sse as your sort of launch protocol and transport transport and obviously transport is pluggable the behind the scenes of that like was it jared palmer's tweet that caused it or were you already working on it no we have we have github discussions going back like you know in public going back months really talking about this this dilemma and the trade-offs involved.

1:02:11We do believe that 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 statefulness. So we had a lot of I think honestly this is one of the most contentious topics we've discussed as the core MCP team and 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 want to 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.

1:03:09It's just like not 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 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.

1:03:50And 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 can still be the stateful interaction and stateful server but allows you to like horizontally scale more easily or like deal with spotty network connections or whatever the case may be yeah yeah and yet as you mentioned session id how do you think about auth going forward for some mcps i just need to like paste my api key in the command is there kind of like a but yeah what do you see as the future of that Is there going to be like the.m equivalent of like for MCPs or?

1:04:28Yeah. We do have authorization as a specification in the current draft of the next provision of the protocol. It's mostly at the moment focused on user to server authorization using like OAuth 2.1 or like, you know, a subset of modern OAuth basically. And I think that has seems to be working well for people and people building on top of that. And that will solve a lot of these issues because you don't really want to have people bring API keys, particularly when you have like when you think about a world, which I truly believe will happen, where the majority of servers will be remote servers. So you need some sort of authorization with that server.

1:05:07Now, for the local case, because the authorization is defined on the transport layer and so requires framing, which means like headers effectively. This does not work in Santa.io. But in Cynna.io, you run locally and you can do whatever you want anyway. And you might just pop open a browser and deal with it that way. And then there's also like some thinking that is somewhat not fully decided on about, you know, even using HTTP locally, which would solve that problem. And Justin is laughing because he's very much in favor of this, where I'm very much not in favor of this. So there's some debate going on there.

1:05:44But like authorization, I think, you know, we have something. I think it's like it's as everything in the protocol is like fairly minimal, like trying to solve a very practical problem. It tries to be very minimal in what it does. And then we go from there and add based on practical pain points people have on top of the protocol and don't try to overdesign it from the beginning. So we'll just see how far our current aspect gets us basically. Yeah, I want to build on that a bit because I think that last point is really important. And like, you know, when you're designing a protocol, you have to be extremely conservative.

1:06:16because 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 kind of do ad hoc extensions until maybe there's more like consensus that something is worth adding to the core thing and like supporting indefinitely going forward. And with auth in particular, and this example of API keys, I think this is really illustrative because 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?

1:06:52And 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 authorized 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 wary about like adding too much other too many other options that both then clients and servers need to think about yeah have you guys gave scopes any thought if it's like we had an episode with dermesh shai yesterday from hnai and hubspot and he was given the example of like email like he has all of his emails and you know he would like to have more granular scope for, hey, you can only access these types of emails or like emails to this person.

1:07:42Today, most scopes are like rest driven, basically. It's like what endpoints can you access? Do you see a future in which the model kind of access like the scope layer, so to speak, and kind of dynamically limits the data that passes through? I think the, I think there is a potential need for scopes. That goes back to like, we have discussions around this, but what we're currently trying to do is just like rooting them in very specific example and like have a good set of like, these are actual problems that you cannot currently solve with the current implementations. And that's like the bar we set to add to the protocol.

1:08:17And I think that, and then, you know, based on that prototype, using that extensibility that we have at the moment where every structure that's returned is extensible and then build on top of that and prove that this will have a good user experience and then we put it at the protocol. That's usually been for the most part the case. It's actually not quite the case for authorization in general. That's been a bit more top-down. But I can totally see why people want it. It's just a matter of like showcasing the specific examples and like what the potential solutions would be so that we don't accidentally run into this like, yeah, this approach where like it sounds roughly right and we put it in and it was actually not really right.

1:08:54And now you're back to this like adding, it's easy, removing as hard in protocol design. And so we're just a little bit, we're just a little bit, you know, careful around this, so to speak. That being said, you know, every time I hear it, like in the rough description, it makes sense. I would love to have a very practical end-to-end user example of this and where it falls apart at current implementation, then we can have a discussion. There's a little bit of wariness 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.

1:09:25But I do think, you know, 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 kind of 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 that's not what the server should be doing. And maybe it shouldn't be connecting to 20 different things.

1:09:57Maybe those should be separate servers that combine up somehow. Lots of discussion there. Where should people go if they want to get involved in these debates? Is it just the specification repo discussion page? That's a good start. I want to caveat it slightly that on the internet, it's very easy to be part of a discussion and having an opinion without then actually doing the work. And so I think there, we're, both Jensen and I are very old school open source people that like, it's, it's merit driven in the sense that if you have done work and if you, if you showcase this with like practical examples and work in SDKs towards the extensions you want to make, you have a good chance that it gets in.

1:10:41If 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 much discussion points we can read. Of course, we value the discussion and we want to have the discussion. But we also need to manage our time and our engagement. And we obviously select for the people who are 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 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 as the kind of like maintainers or like shepherds or whatever believe 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 i think that's a very interesting and quite good point is like they're like a like a project like mcp is an entry into like into a solution space of the problems in that in the general like space and it's it is one of many entries in a way.

1:12:28And if you do not like the direction, you know, that we and like people that are very close, you know, in the development of the protocol choose, then there's always place for more, right? That's the beauty of open search, right? The good old, you know, for Git approach. We do always want to hear the feedback and we need to make it scalable, I think, but also just the recognition that like, sometimes we will be going with our intuition about what is the right choice. There might be a lot of flame in the open source discussions about it, but that's just the nature of projects like this sometimes.

1:13:03Yeah, 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? And both of you, if you weren't directly involved, you know everyone who was directly involved. I would say React, we eventually started, because I was obviously deeply part of the React ecosystem, we eventually started working groups where it was open, it was 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 a significance they weren't like sort of drive-by people with no skin in the game and i think that was helpful for a while i'm not sure it's like an actively managed thing because of react's own issues with the multi-company situation they're in the other thing that actually is to me is more interesting is graphql because mcp where like currently has the hype that graphql had and i lived through that one and eventually you know Facebook donated GraphQL to an open source foundation.

1:13:56And I think that there's a question of like, do we want to do that? There's trade-offs, right? It's not a clear yes or no. I would say that most people are happy with Anthropic and you guys, obviously, because you created it, you guys being the stewards. But at some point, at some scale, you're going to hit some ceiling there where you're like, okay, like, you know, this is owned by one company. And, you know, eventually people want to like, the truly open standard is a nonprofit. There's multiple stakeholders. is a good governance process, all of which is governed by like Linux Foundation, Apache, whatever.

1:14:26So I want to ask like any thoughts there? I personally would say it's too early. You know, like what are your thoughts? Yeah, I think governance in general is a super interesting problem in the open source space. I think there are two things. On one side, we really, really want to make this and have this be an open standard and open protocol and open project with, you know, participation from everyone who wants to be Partake. And I think that actually is working quite well so far. If you look at the pull request, if you look, for example, a lot of the inputs on the streamable HTTP thing came from companies like Shopify and others that had discussed and worked on this and brought proposals to the table.

1:15:11And I think that works really well. The thing that we are a bit wary about is any type of official standardization, particularly going through an actual standardization body or any type of like 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. And so we're trying to find this nice middle ground of like, how can we have participation? that we luckily do have from everyone, work towards everyone's, you know, everyone's like problems that they have potentially with the governance model and figure the right path forward out without accidentally slowing down the project.

1:16:03I think that's what we're trying to do. But yeah, we genuinely, we are very genuine in our desire to have this be an open project. And like, yes, it was initiated by Anthropic and David and I work at Anthropic, But like, we don't want it to be seen as like, this is anthropics protocol. I think it's very important for the whole ecosystem that this is something that like any AI lab could have a stake in or contribute to or make use of. But yeah, it's just, 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.

1:16:38I think most of the delicacies are really around like, you know, sort of corporate sponsorship 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. That being said, I want to highlight this, that at the moment, as we speak, there's plenty of people that are not Anthropic employees who have commit access and admin access to the repositories right there. You know, some of the people from Pydantic have commit access to the Python SDK because they did a lot of really good work there. And we had a lot of contributions from block and others to the specifications.

1:17:10SDKs like the Java SDK and the C Sharp SDKs, they're completely done by different companies. Like the C Sharp one is done by Microsoft. It's a very recent addition last week and they do everything there. They have full admin rights over that. The same goes with JetBranch doing the Kotlin one and Spring AI doing the Java one. So it is actually, if you really look at it, it's already like a multi-company big project with everyone. And there was a lot of people beyond just us to having commit access to and rights to the project as is. Yeah. Awesome, guys. This was great. Just to wrap up, do you have any MCP server wish list?

1:17:48What do you want people to build you that is not there yet? Or client. Client or server. I want more sampling clients. That's all I want. I want cool. I want someone to build a client that is sampling and someone else that builds me a server that does summarize my Reddit threads or summarize. right? Like I'm an old EVE Online player. Summarize what happened in EVE Online in the last week for me. I wish that someone would do that. But for that, I want a sampling client. I want this model independent. Not because I wanted 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.

1:18:27Justin, what about you? Well, I'll echo that and just even broadly say, like, I think just more clients that support the full breadth of the spec would be amazing. I mean, we kind of designed 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 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 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 have 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 to have claude already built your 3d model from now on with blender right but yeah i mean honestly even like 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 cloud place pokemon hackathon with David Hershey.

1:19:30So I'd be able 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. Keep up the good work. Thank you both. This was fun. Yeah. Thank you. I really appreciate it. Cheers.