One Year of MCP — with David Soria Parra and AAIF leads from OpenAI, Goose, Linux Foundation

Hey, everyone. Welcome to the Latent Space Podcast. This is Alessio from the Recurrental Labs, and I'm joined by Swicks, editor of Latent Space. Hey, and here we are joined finally in the studio for the first time. Welcome back, David, from Anthropic slash MCP. Yeah, hey. Well, nice to finally talk to you in Perth, then. Last time, like a year ago, it was over VC, and this is way fun. I watched it back, it was eight months. It's been a crazy eight months, and I think we just celebrated, like, the one year anniversary of MCP. Yes, at least the public announcement. Yeah. And also, last night or yesterday was the Agentic AI launch. Yeah, that was nice. It was nice to see the Anthropic office. Yeah, you like it? Yeah, it's very good food. I would say, in terms of my food bench, Anthropic does rank over OpenAI. Yeah, at least that's what we have going for us.
Awesome, man. Do you want to give just a quick overview of what's happening with MCP? And now you're donating it to the foundation, and then we'll do kind of like a one-year recap of the protocol itself, and then we'll have the rest of the leads from the foundation join us to do more of the high level. Yeah, that sounds good. Yeah, I mean, where we're at at the moment, we have done like a year ago, we launched it, and then we had this like crazy adoption over the last year now, which it feels like an eternity, honestly. But we have this like crazy growth and like adoption, you know, through initially through like Thanksgiving and Christmas, very early with a lot of like builders building MCP. And then, you know, you had like the first big clients coming in, like Cursor and VS Code. And then like you had this like inflection point around April with like Sam Altman and Satya and Sundar and all. I'm posting about like MCP and that they're going to adopt MCP at Microsoft, at Google, at OpenAI. And that was really like the big inflection point. So, yeah. But in all of the time, you also had to do a lot of work on the protocol itself. We like, we moved, we launched originally as like basically local only. We could like build local MCP servers for cloud desktop. But then we like in March this year, we moved into like, how can you do remote MCP servers to connect like really about like to a remote server and introduced like the first iteration of authentication. And then in June, we revisited that and like improved it quite a little bit so that it works better for, you know, for enterprises in particularly. And we were very, very lucky that in that time from March to like June, we're like able to like have absolute industry leading experts that literally work on OAuth itself to help us with some of the pieces, right, and how to get it right. And then we focused a lot of on like security best practices and this type of work. And now we're like, I feel we have a really solid foundation and we're doing we just launched like in our end of like November, then the recent iteration of the protocol. Finally, like the next bigger improvement of the protocol, which is like long running tasks to really allow for like, you know, deep research type of task and like, you know, maybe even agent to agent communication. And so I think we're just stepping into like this territory now with like, okay, we have really solid foundations, we have like one more big permit if you want to add, we want to make like a little bit more scalability, things work. And then we're, you know, going to get into a phase where it's probably becomes a bit more stable. And so yeah, it's been just been absolutely crazier, man. You did say the agent to agent. So there is a A2A protocol. I'm curious when the Agentic Engineering Foundation got formed, or just the Agentic AI Foundation, was there any discussion about any of these other protocols being a part of it or, you know, Sean wrote a post called YMCP1 already. So I think my favorite post of the year was already in the go with that. It was and it was before Zemlin and all the other guys. Yeah, yeah, you're right.
But what I mean, I think it was just obvious that was going to happen. Yeah. So yeah. So we did we of course have conversations around like what is else was in the market, like the payment protocols that are interesting and so on. But when we wanted to start a foundation, we wanted to make sure first of all, two things, we wanted to start small and make sure that the group that is founding this like for us, it's the first time we at Anthropic have an open source foundation. So this is all new to us. We really want to start small and making sure we're learning along the ways and being able to like shepherd this and the way we feel is best for the industry together with OpenAI and Block. But the second part of that is also like we really felt like we wanted to see things that have a lot of adoption are de facto like, at least on the protocol side, like a de facto standard. And I don't think any of the other protocols, it feels like they're not just there yet. But of course, if they get there, then we're like super open as long as they're like complimentary to what's in the foundation. On the application side, we're a little bit more flexible and we're like more open. But on the protocol side, I think we really want to make sure that we're not like offering like, that the foundation doesn't encompasses like five protocols for the same like communication there. And so, yeah, there was discussion, but I think for now we just want to start small. Is there a role, like a double hat that you have now with the foundation, or are you more focused on MCP? I am still mostly focused on MCP. It's a bit of a double hat, so there is this like, I think people need to understand like the foundation part is mostly just an umbrella to make sure the projects under it stay always neutral. And I think that's really the most important part you want to get a lot, you know, want to understand, because the rest of it is like, okay, how do we use the budget of the foundation for events and things that are like, quite dry. And then the technical parts to like MCP, they stay actually the same, like on the on the way we govern MCP, nothing has really changed. And so that's really still my job as the lead core maintainer of like, shepherding the processes, shepherding the protocol forward. And then beyond that, now the additional double role is like, I'm also going to be on the technical steering committee of the foundation, which will like, make sure to like figure out what are the projects we want to have in the foundation. So if someone comes with a project to us, the people that have projects in it will decide, is this something we would want? Is this something that we feel is like well maintained, has a lot of adoption, is not going to go away, we want to make sure the foundation is, have like super interesting and important projects, and not like a dumping ground like have, you know, some foundations might have ended up with. That's true. So we're going to meet some of the others later, but maybe we'll just focus back on the sort of MCP development. You covered a lot. There's been four spec releases. That's a lot. Yeah, so people may have missed some of them, that's what I'm saying, right? And I think it's really interesting how we've continued to work on really important parts. I always think it's very hard to follow up a major success with a sequel, because the sequel is usually hard to repeat that impact. But I think every single time you've actually managed to focus on something important. So maybe we can cover, I guess, maybe we'll start with the March-May one, which is HTTP streaming, which is good, and the OSPEC, right? Any other, I don't know if you want to highlight any others, but we'll just catch people up on that stuff. Yeah, so that was, I think that was really a, that was such an important one. Like it was the number one requested thing. Yeah, it was like, it really opened up this like remote thing. And we were, we already knew actually in December and November that the next big thing will be like, how can you do this over the, over remote? And authentication is quite important. One of the things I think people very rarely noticed when it comes to MCP, MCP is very, very prescriptive in like each layer. Like other protocols are not like that, for example. Like we like, you want to do authentication. If the client and the server don't know each other, you need to do all, right? And so we were very early, we wanted to have like one way to do something. And so we really focused on like, what does this mean? Like, how do we get it over? How do we build a protocol that has this like these streaming properties that we require? And then how do we do authentication very early? For authentication, in the first iteration, I think we did an okay job, but we got some aspects wrong. And most of them, honestly, were just me not understanding enterprises well enough. But then again, I think the strengths that we have with MCP, I think the one thing, if anything, I'm proud of is building a community of people that can come together and help me figure shit out. Because I have my set of experiences of what I'm good at. And enterprise authentication, it turns out, is not one of them. But they're way better suited people for that. And so that's when we like, after that march. I saw you post that, but I didn't really dig into the details. Was it the typical SAML type of authentication issue? The main issue we did is, in OAuth, there are two components. There is an authentication server who gives you the token, and then there's the resource server. It takes the token and gives you the resource in return. And in the first iteration of our authentication spec, we combined them together into the MCP server. Which if you were building... Unusable, yeah. It's kind of usable if you build like an MCP server, as like a public server, as a, you know, you're a startup, you're building a server for yourself. You want to bind this to the accounts you already have. That is completely usable. The reality in enterprises is you don't authenticate, you authenticate with some central entity. Like, you know, you have some IDP provider or an IDP. And you go up to... And also, yeah. For most people, they don't even notice that it's happening. All they know is like, oh, in the morning, I'm gonna go log in with Google for and they're gonna access to all my work stuff, right? But that's effectively the IDP, right? And if you combine these into the same server, you just can't do this anymore. And so all we needed to do is like, okay, we are a resource server. The MCP server is a resource server. How you get the token from the authentication server, we have opinions on how you should do it, but it's kind of separated. And that's what happened then in the June spec where we separated this out and worked with a lot of these like, okay, now how do you do dynamic client registration and other aspects, which also were part of the March spec. We can talk about that. That's a whole other story of like, we are actually pushing the boundaries of what OAuth can do with MCP, because we're trying something very unique with MCP. But yeah, that was the big part in March, which was that authentication spec, the first iteration, then fixing it in June. Yeah. What's the state of agents authenticating on my behalf? Because even today with the OAuth, I still have to log in to Linear and whatnot. Yeah. OAuth itself is for the most part, a very human-centric protocol. It just tells you how you obtain a token if you don't have a token. Once you have a token, actually, it doesn't matter. You just put it into the bearer token. And so we are not very prescriptive of what agent to agent authentication would look like or on behalf of agents. There are ideas that we are looking into, and I don't have all the specifics, but we are not prescriptive in the same way we are prescriptive as with OAuth. But you can technically, the moment you have a token that might be like bound to like a workload identity or something like that, then you just can pass that still to the MCP server. We're just not telling you how to obtain it just yet. And so we're not prescriptive. And so people do this, and they can do it, particularly when they're within like an enterprise and have a somewhat closed ecosystem. But if the client and the server don't know each other, we just don't have a good solution for now. And then, yeah, on the remote thing, you went from local servers like SSC and then Streamable HTTP. Any learnings you want to call out there? Any regrets or learnings for others? And transport. The one discussion that has never stopped from the very beginning of the last years about transport. And we literally just spent the last two days at the Google offices with a bunch of like senior engineers from Google, Microsoft, AWS, Anthropic, OpenAI. Just like, what do we need to do here to really make this solid? When we looked into MART, we wanted to get a transport going that basically retains a lot of the properties we had from standard IO. Because you really... And I still believe just until today that MCP should also enable agents and agents are inherently somewhat stateful and there's some form of like long-term communication going between like the client and the server. And so we always looked for something like that. We also knew that we looked into alternatives like, okay, what happens if we do WebSockets, for example, and we have found a lot of issues with doing a proper bi-directional stream. And we're like, okay, what is the right middle ground between having something that can be used in the simplest form that people do, like where they just want to provide a tool, but then is able to be upgraded to like a full bi-directional stream if you need it, because you really have like complex agents communicating with each other. That's where Streamable HTTP was born with that intent. And I think there's some things that in retrospective, we got right and something that we got wrong. I think we got right that we are really leaning just on standard HTTP in that regard. We got wrong that we made a lot of things optional for the clients to do, like you can, the client can connect and open this return stream from the server, but it doesn't have to.