Anthropic and the Model Context Protocol with David Soria Parra

0:00The Model Context Protocol, or MCP, is a new open standard that connects AI assistants to arbitrary data sources and tools, such as codebases, APIs, APIs, and content repositories. Instead of building bespoke integrations for each system, developers can use MCP to establish secure, scalable connections between AI models and the data they need. By standardizing this connection layer, MCP enables models to access relevant information in real time, leading to more accurate and context-aware responses. David Soria Parra is a member of the technical staff at Anthropic, where he co-created the Model Context Protocol.

0:39He joins the podcast to talk about his career and the future of context-aware AI. This episode of Software Engineering Daily is hosted by Jordy Mon Companies. Check the show notes for more information on Jordy's work and where to find him.

1:05David, welcome to Software Engineering Daily. Hi, Jordy. How are you doing? I'm doing well. So why don't you introduce yourself? Yeah, happy to. I'm David. I'm a member of technical staff at Anthropic. And before that, I've worked roughly like 10 years at Facebook and had like a little stinch in a venture capital called Sutter Hill. And yeah, I've been out since a year I'm at Anthropic as a software engineer. So that is the meat of the conversation, your work at Anthropic, which I'm sure goes beyond MCP, which would be the core of the conversation. But I really want to go back, even before your days at Meta?

1:40Because you started your career as a PHP developer, as a Mercurial contributor. Walk us through, what got you engaged, I guess, in computer science, in programming? And what was your first project? What were your first steps in this world? Yeah, well, thank you. That I have been doing software engineering or like programming probably since I'm 14. It started very simple. Like I've like, I got access to the web and wanted to build my own little websites. And at the time, you know, you had guest books and forums and you're like, eventually you're going to be like, how do you build one of those? And that's how you discover things like PHP and others.

2:16And then how I started learning PHP at like the age of like 14, 15 and I'm doing it since then. And then over the years, I was very lucky enough that some people in the local PHP community took a liking to me and like had me work for them. And through that, I actually started engaging not just with PHP as a language that I'm using, but also with the wider community. Just as you know, eventually you ended up on adding your first patches to the actual language. Instead of writing PHP, you're suddenly writing C. That quite early, around the early 2000s, I started contributing to PHP itself and worked in that field.

2:54And I was just very lucky enough that I had a bunch of mentors along the way that helped me getting engaged into the open source community. And then from there on, I think I was just hooked on open source and the ability to just go to a big project and find a bug, fix it myself and, you know, help move this thing a little bit forward. And, you know, that's how I've approached a lot of the projects over the years. And that's how I got from PHP to Mercurial, you know, dabbled a little bit into Git and other things. And so that's a bit of like the early, early days for me. Yes, exactly. So PHP is programmed in C, and so is Git, right?

3:32I didn't know about Mercurial. So is it programmed in C? How did you fall into Mercurial and not Git? Because it feels that even back in the day, I mean, we're talking about ancient, quote unquote, ancient times in terms of the internet, at least. I was there, so I'm dating myself here too. I think it already seemed that Git was inevitable, or was it not? Was it Mercurial that was the hype back in the day? So actually Mercurial is written in Python. There are some key parts to that that are written in C, the most important parts that require performance. All of this actually came out of the work on PHP.

4:05So I was quite interested in source control systems in general. And I was looking into like, what's the next version control system for the PHP product itself? And at the time it was like CVS, it was just old dated version control system that had a lot of issues. and I was looking around and someone was pointing me towards these decentralized version control systems and they were pointing me towards Git. And at the time, and I'm not sure you remember this, but at the time, these version control systems, it was not quite clear which one is the dominating one and there were plenty of those. And there was Bazaar, there was Mercurial, and then there was Git.

4:39And it was a bit like the editor work from the early 90s between Vim and Emacs. There was a bit of the decentralized version control system wars. I love BigQuery for two reasons. I think it was much easier to reason and contribute to it because it was written in Python. And it was very easy to write an extension, for example, an ability that you did not have in Git. You had to contribute to the core Git project. But in BigQuery, you could write an extension and contribute that. And that was a way lower bar and way easier to do. And really took a liking to that. And then the second of all, I think the Linux community was really the founding community for the Git community.

5:19And some of the harshness of that community took over to the Git side and the directness, where I think some of the Mercurial folks were a bit more welcoming and encouraging. I think those two things flew together. And I just liked the system a little bit more. And so that's how I started contributing to Mercurial. Rather than to Git, I had some patches in Git, but eventually I just ended up working for the most part on Mercurial. I didn't know that about Mercurial. So thanks for that piece of information about being built in Python mostly. I think it's true that contributing to the Linux project, the kernel, Git is rougher.

5:53It's got much better throughout the years, but it is true that, well, Junior Humano, the current maintainer of, or one of the maintainers of Git, has done an excellent job in that sense, sort of like keeping everything. But back in the day, I think it was rougher. It seems like your career was destined to end at what was previously known as Facebook, now Meta, because Meta is known for many things, for its products mostly, but from a developer perspective, from the software engineer perspective, it's because they maintain and use a quite peculiar stack. I would have never thought that a company that is listed in the public stock market that is so incredibly fast at developing and delivering software would rely on PHP, a specific flavor of php and mercurial among other things bark and etc so it feels that your career was designed had it all a yeah was designed with joining meta eventually but i'm sure that was not the case but yeah if you can talk about what drove you to meta eventually or facebook back in the day and if you can talk about the stack of meta because it's i find it quite funny to be honest to know about that that they keep their own flavor if you can explain that of php of mercurial etc Yeah, absolutely.

7:07Funny enough, I think nobody has ever looked at this as the whole thing, like, oh, you were destined to join Facebook. But I think it makes sense in retrospective quite a lot. And I certainly feel way more aligned with Facebook than, for example, Google, which has slightly different approaches to this. The interesting bit is like I was coming out of university by the end of like 2012 or something along the lines. And I was not considering joining a big American company because I was like living in Germany. And I just worked in these like little companies. And I would have probably not by myself went and go and apply to Facebook.

7:45But it happens that the Mercurial community itself like got together like once a year. And we were sitting in Stockholm and at the time for one of these events. And at the time, Facebook had quite an interest in McCurril because they were in the midst of choosing what's their version control system that they will have to work with for the next 10 plus years. As it turned out, eventually they will choose McCurril. And one of the people from Facebook was there and he was like, we were going to build a team around this. Why don't you come and join? And that's honestly how this happened. And, you know, I interviewed, I got the job, I relocated from Germany to first Vancouver and then later to the Bay Area because to just continue working on source control.

8:27And so I think that was really, really cool. And that goes like back into this unique stack that Facebook, similar to Google, are building or have been built, have built, is that at the time they had challenges as part of the scale that they had and particularly the growth that they had that just few people had. the world. And they were quite unique in a company in that regard, that they required a set of infrastructure and a set of decisions that they had to make that just nobody else was facing. And one of these decisions was, for example, do we want to have one big repository for everyone, or do we want to have a thousand repositories for each team separately?

9:08And they're very different trade-offs to be made, and there's a lot of in-depth of why you would choose one or the other. But Facebook eventually chose, similar to Google and probably very inspired by Google, a monorepository approach. And with that, you inherently know you will have scaling issues because you can draw these graphs of commit rates and sizes of things that you will require your own source control system. You will require your own build system and all the stack on top of that. And at the same time, back to the PHP part, at the same time, your code grows at such a rapid rate that changing the programming language after you have prototyped basically Facebook and PHP becomes impossible.

9:47So it becomes way more efficient for these companies to go and optimize by building a team. And so like you build a version control system, you tend people and you tend people optimize the hell out of PHP way cheaper than making a thousand people change version control system or change programming language. And so that's a lot of these, how these stacks came to be because there were issues that nobody else had before. Okay, so it seems that your first stay, your first stint, the first part of your tenure at Facebook, I'm going to keep calling it Facebook because technically it was at that time, was on build tools, on the performance, enabling software engineers there to contribute to the minor repo, etc.

10:30And mostly in source code management, as you just explained. But you then turned into what was, I can only presume, very, very novel virtual reality, augmented reality stack of Facebook. Is that correct? Mostly, again, from the development aspect of it, right? So when Oculus got acquired by Facebook in 2015, I was one of the first engineers who helped them incorporate, basically, Oculus into the Facebook development infrastructure. And with that, there's a lot of very different challenges because the Facebook stack was built for web development, for end-to-end, the way the assumptions made in the CI system, the assumptions made in the source control system.

11:07And a lot of them did not hold through when you suddenly add Windows to the mix. and you add large file systems. Exactly. Give us a sense of what you found in the Oculus stack. Yeah, the Oculus stack, right? It was like a very traditional gaming stack. You would have like a very centralized version control system, usually Perforce, that artists know how to deal with, that handles large files very well. You have CI systems that understand how to hold some form of state. So they built the game or the engine once, and then they keep the cache around for it. And all of these things do not happen in the web world where you deal with way smaller repositories, you deal with way smaller artifact sizes, and things are very ephemeral in the CI system.

11:50And so it was just like these massive different aspects. And then, of course, the really big one is Facebook was a Linux shop. Like the servers, this Linux, everything is a Unix-based thing. You develop on a Mac and you deploy in Linux. And suddenly you bring Windows into the mix. and everything falls apart because it's like nothing works anymore because you work against 15 years or 10 years of assumptions made around Linux, right? And so that was a big, big lift for us. Oh my God, that must have been a ton of work and fascinating. Quite fascinating, not necessarily fun at all times. Okay, noted.

12:24So let's dive into model context protocol, which you co-created. So give us a sense of how this came about, like the initial ideation, I guess, that get into the meat of it yet? With whom did you develop this? And yeah, what were the initial stages of this? What sparked it all? Yeah, I think that's a good question. So thank you. I joined Anthropic like April last year. And my original work was, again, on developer tooling. So my work was of like, how do you make people internally use the AI systems you're building more? And one of these first things you do is when you look at like, how you enable people to do this is like, what is there and like what is required still to do this.

13:06And one of the first insights we had at the time was like, I cannot build a specialized system for everyone at Anthropic. What I need to do instead, I just need to enable people to build for themselves, right? So that was one of these insights. The second insight is that we had with Cloud Desktop, really a cool desktop application that had beautiful abilities to draw artifacts. So you had like a very visual interaction, but at the same time it was lacking like file system access or access to you know external system in any kind of form or shape we also obviously worked with like editors you know i at the time was working at zed with a zed editor and so these editors and obviously had file system access but they lacked on the other hand side just like beautiful ability to like create diagrams and all these other things so you had these like different clients that were had strengths but none of them were quite extensible and none of them you know was hard to build for.

14:01And so that's where I was thinking about, like, how do you enable people to build and really enable the workflows you care about in these systems? And then, you know, I also worked on a similarly on something like, yeah, like an LSP related thing, which is the language server protocol. And if you look at the language protocol, server protocol, you very quickly see that MCP is very inspired by that. And so you put these two and two things together and you go like, I wish, and that was like my proposal, like I wish there was a way for us to just extend these clients by like creating little scripts, by creating little things to tell these things what I care about.

14:41And it should probably be like some form of protocol so I can use it both in an IDE and I should use it both in cloud desktop. And I proposed this to a local friend of mine called Justin Spar Summers who really took a liking to it and really confirmed the idea and was like, we should really go and build this. And then he did an amazing job building this into Cloud Desktop, where I was at the same time building it into Zed. And so we took it from there as a two-person project, honestly. That was very bottom-up. That's how MCP came to be, right? It was like the Eurotunnel connecting France and the UK, that each one was digging through from each end and then met at the middle, right?

15:21Yourself from Zed, and he was building it from Cloud Desktop. So how did you become acquainted with LSP? Was it from your day getting acquainted with the Oculus stack or the Microsoft stack? Well, actually, that's just from my work at Anthropic. I was actually working on an LSP-related experiment, trying to build an internal LSP for various reasons. And that project didn't go anywhere, but it exposed me to LSP in more depth, and I've built a little LSP. And of course, from there, I looked into the specification, and I understood how these things are going to work. And then at the same time, when you have decided that you need some form of protocol, you go and shop around and look at pattern match.

16:00Because what you don't want to do, you don't want to invent the wheel. You want to focus on the unique differences that you have because you're in an AI application. And you don't want to also reinvent everything else. And so you just try to pattern match. And I felt LSP was a very good pattern to match it. I was not aware of LSP. Where is it currently being used? I mean, you got wind of it because you were doing some research and so forth. but how is it used in production? In what projects? What is the main use case of LSP? Yeah, so LSP solves this classic end-to-end problem that IDEs have with language integrations.

16:35So before LSP was a thing, so before 2015, every IDE itself would have to implement how do they parse Python, how do they parse Java, and everyone had their different take on it and the different strengths and the different weaknesses. But what it meant is that every IDE company or every IDE builder had to have a little team that only cared about these language bits. And they could not care about how to build a great IDE experience. And so the LSP came around as a Microsoft-driven effort around 2015, 2016. They built a protocol to go and say, like, hey, why don't we just build one Python implementation and just have that implementation tell the IDE certain things so that the IDE can display type hints, that the IDE can do refactoring of the code base.

17:23That way, not everybody has to build a Python implementation, parse Python, and you all can go and focus on your IDE stuff and do a better job at that. And so you see it in all IDEs. It would be in a VS code. It would be in JetBrains. It would be in Zed. Everywhere, IDEs, it would be everywhere we use LSPs for interacting with language syntax, with refactoring, these type of things. And so it's basically always there. You just barely notice it anymore. So for our listeners, can you break down the core concept of MCP? What are the key actors here, the key elements? Model, it seems from the name, of course, that it's models, tools, and protocol itself.

18:02But yeah, how do these things interact? Could you define each one of them, et cetera? Yeah, absolutely. So MCP really is, it's first of all, an open protocol. And I think the protocol bit is that it solves this end-to-end problem of clients to context providers. It is a protocol between AI applications and context provider for these applications. And what this does and what the key actors are is the actor is the application, like, for example, Cloud Desktop or, for example, your IDE, and some form of context provider, which is usually a program that provides some context to that AI client. client.

18:43It could be in the form of tools and could be in the form of resources. And so some of these primitives that we then have inside the protocol are tools, which is obviously the most used one, the ones that everybody knows about. The most obvious thing is like you can provide a tool via the protocol to an application such as Cursor, and then Cursor can use this, but you have implemented in your little application this tool and it can use it and you have your custom logic around this. But the protocol has more than that. The protocol has additional primitives such as resources, which is more like files that look like files, act like files, that the application itself, the cursor could decide how to deal with it and how to use this to ask the model something.

19:25And then lastly, there's something called prompts, which is basically just prompt templates that allow a user to ask an MCP server, hey, give me a predefined prompt that I might want to use because it might contain information about the tools you want to use, or it might have additional information that it pulled from somewhere. And I can put this into my context deliberately. But all of these eventually end up that the application will take something from the server and put it into the context of a model and then ask the model something so that you have a rich interaction with an LLAM. That's really what it boils down to.

20:01Okay, we'll go back into the protocol bit that you described briefly at the beginning later. But going a bit deeper into how this works, it seems like the invoke, response, and error are the main commands. Is that true? Am I missing any other command that is at the core of it? And how do they interact and work? Invoke response and error in the sense that it's a protocol that uses inherently like an RPC mechanism. So like a remote procedure call mechanism. Under the hood, it is JSON RPC. And in that regard, yes, there's some form of invocation from the client to the server, some form of response from the server to the client, and then obviously errors.

20:43The actual primitives and the actual semantics of the protocol are then slightly different. Again, these boils down in these three different server primitives that we call, again, prompts, resources, and tools. These are the more high-level things. But of course, they're getting invoked in a way from the server, and there's a result to it. So those are really the key concepts, so to speak. Okay. So the compute is happening. If I'm using Cloud Desktop, the compute is happening in the cloud because the model is hosted there. The client is Cloud Desktop. I am invoking a resource or a tool that could be a set of PDFs or something more agentic, for example, something that is running in a server somewhere else.

21:28So it goes back to the cloud, right? So the core compute resides in three places, potentially. The cloud where the LLM model is, in this case, Claude, one of the models of Claude, I should be specific. Then locally at the level of the desktop application, cloud desktop, and then again in a server or even in a cloud or somewhere else where the tools are working, right? Is that a correct description of how the setup would look like? I think that it's one instance of a correct description. I think so the client, yes, the client deals with the model and that model can be cloud. It can be, of course, like an open AI model.

22:08It can be anything. So the protocol itself is model independent. The client application, so like in this case, Cloud Desktop, can either go back to the cloud, like to like a remote server, be it, you know, something hosted on Cloudflare or somewhere else. But also, the protocol also allows, and actually the vast majority of servers today are local servers. There are local applications that run on your laptop, on your computer, that then interact with the maybe with external services. But Cloud Desktop Client interacts actually with like a local program, which we call the MCP server. And it's slightly confusing because a lot of people have the assumption that a server is always remote on the Internet.

22:50But in this case, it leans into the English name of serving something. And it's serving can also happen locally, right? It's just a separation between concerns of a client and something that serves the context upwards. Is this setup able to manage a state? And if so, how does it do it? Yeah, it does. In the end of the day, the MCP server is a full application. It's a program, right? Not an application in the sense of a graphical user interface, but in terms of a running program. And so with that, the protocol has an initialization sequence. It tells the client, tells something about itself to the server.

23:32The server tells something about itself to the client. And then from there on, they have invocations and results. And throughout those, the application can very much hold state. And so it's very possible, for example, and very easily to imagine an MCP server that, for example, manages a basket. And then there's a tool that says add to the basket and a tool that says list of the basket. And the application is then responsible. well, this like MCP server application or program is responsible in the end of the day for how to manage that state. So they are inherently, they can be stateful. They don't have to be.

24:06That's really what it is. So you've mentioned the inspiration from LSP. I can think of many other protocols, HTTP, UDP, et cetera. Did you get inspiration from any others or was it mostly from LSP? Did you pick and choose? I think we always looked at different protocols and what are the best fits and like look at what makes the most sense. I think there's, of course, a lot of things in what we call the transportation layer. So this can be HTTP. There can be different ways. It can be WebSockets and other things. And so there's some inspiration there. I would say the vast majority of the inspiration came from the language server protocol.

24:42And it's very closely related. A lot of the mechanisms, how the protocol actually work, are very deeply grounded in how LSPs have done it. For example, the choice of JSON RPC is one that is very one-to-one translated from LSPs. The choice of an initialization sequence and some form of capability exchange is informed both by LSPs, but also by my work at McCurl, because actually McCurl push and pull also have an initialization sequence. So there's some basic things that a lot of protocols inherently have that, for example, HTTP to some degree also has, but HTTP does it in the same message by using headers.

25:25And so there's a bit of inspiration in all of them. Then, of course, now when we talk about authorization and other bits, a lot of it is very directly from the web and how the web works. Okay, so the MCP universe that you co-created has exploded, especially on the tool side. Like, it's ridiculous just how many things have been added to the ecosystem. I call it universe, ecosystem, whatever. So how does MCP have any inherent feature in order to help with tool discovery? Like, you've chosen your LLM of choice. You are going to use our cloud desktop. What about what the rest offers, what the world is offering up there?

26:06Does it help with that at all at this stage? At this stage, there's no automatic mechanism to explore what's out there. You would have to go search the web, download an MCP server and expose it that way. And then within that aspect, the client can dynamically list the tools and explore and discover the tools that the server provides. But finding the server that provides a tool that you care about, that's a very manual process for now. And I think that's something that we're looking into, like, how do we improve? Of course, there are other aspects of that. You don't want your cursor to randomly download tools from the internet and execute them because at the end of the day, there are code execution.