EPISODE 1836

[INTRO]

[0:00:00] ANNOUNCER: The Model Context Protocol, or MCP, is a new open standard that connects AI assistance to arbitrary data sources and tools such as codebases, 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. He joins the podcast to talk about his career and the future of context-aware AI.

This episode of Software Engineering Daily is hosted by Jordi Mon Companys. Check the show notes for more information on Jordi's work and where to find him.

[EPISODE]

[0:01:05] JMC: David, welcome to Software Engineering Daily.

[0:01:07] DSP: Hi, Jordi. How are you doing?

[0:01:09] JMC: I'm doing well. So, why don't you introduce yourself?

[0:01:11] DSP: Yes, happy to. I'm David. I'm a member of Technical Staff at Anthropic. And before that, I've worked right roughly like 10 years at Facebook and had like a little stint in a venture capital called Sutter Hill. Yes, since a year, I'm at Anthropic as a software engineer.

[0:01:28] JMC: So, that is the meat of the conversation you 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. Because 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 are your first steps in this world?

[0:01:55] DSP: Yes, well, thank you. I have been doing software engineering or like programming probably since I'm 14. It started very simple, of like, I got access to the web and wanted to build my own little websites. At the time, 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. And then I started learning PHP at like the age of like 14, 15, and I've doing it since then.

Then over the years, I was very lucky enough that some people in the local PHP community took a liking to me and had me work for them. 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've started contributing to PHP itself and worked in that field. 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.

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 help move this thing a little bit forward. That's how I've approached a lot of the projects over the years, and that's how I got from PHP to Mercurial, dabbled a little bit into Git and other things. That's a bit of like the early, early days for me.

[0:03:26] JMC: Exactly. So, PHP is programmed in C. So as Git, right? I don't know about Mercurial. So, is it program 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" times in terms of the Internet at least. I was there, so I'm dating myself here too. I think we already seen that Git was inevitable, or was it not? Was it Mercurial that was the hype back in the day?

[0:03:56] DSP: Actually, Mercurial is written in Python. There are some key parts to that that are written in C, the most important parts require performance. All of this actually came out of the work on PHP. So, I was quite interested in search control systems in general, and I was looking into like, what's the next version control system for the PHP project itself? At the time, it was like CVS, it was just old-dated version control system that had a lot of issues. I was looking around and someone was pointing me towards these decentralized version control systems and they were pointing me towards Git.

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. There were plenty of those and there was Bazaar, there was Mercurial, and then there was Git. And it was a bit like the editor war from the early nineties between Vim and Emacs. There was a bit of like the decentralized version control system wars.

I love Mercurial for two reasons. I think it was much easier to reason and contribute to it because it was written in Python. 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 Mercurial, you could write an extension and contribute that. That was a way lower bar and way easier to do, and really took a liking to that. Then the second of all, I think the Linux community was really what the founding community for the Git community and 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. That's how I started contributing to Mercurial. I had some patches in Git, but eventually I just ended up working for the most part on Mercurial.

[0:05:41] JMC: 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. It's got much better throughout the years, but it is true that, well, Junio Hamano, the current maintainer of, or one of the containers of Git has done an excellent job in that sense 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, is 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, Buck, et cetera.

So, it feels that your career was designed, had it all, yes, was designed with joining Meta eventually, but I'm sure that was not the case. But yes, 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 at Meta, because 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, et cetera.

[0:07:06] DSP: Yes, absolutely. Funny 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 retrospect of 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, I was coming out of university at the end of 2012 for 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 applied to Facebook.

But it happens that on 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 Mercurial, 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 chose Mercurial. One of the people from Facebook was there and he was like, "We were going to build a team around this. Why did you come and join?" That's honestly how this happened. 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.

So, I think that was really, really cool. That goes back into this unique stack that Facebook, similar like 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 gross that they had, that just few people had in the world. 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. One of these decisions was, for example, how do we want to have one big repository for everyone, or do we want to have like a thousand repositories for each team separately? They're very different trade-offs to be made, and there's a lot of in-depth like why you would choose one of the other, but Facebook eventually chose similar to Google, and probably very inspired by Google, a monorepository approach.

With that, you inherently know you will have scaling issues, because you can draw these graphs of like commit rates and sizes of things that you will require your own search control system, you will require your own build system, and all the stack on top of that. 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. It becomes way more efficient for these companies to go and optimize by building a team. 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. That's a lot how these texts came to be because there were issues that nobody else had before.

[0:10:12] JMC: 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 it technically it was at that time, was on build tools on the performance, enabling software engineers there to contribute to the monorepo, et cetera, and 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? 

[0:10:42] DSP: Mostly again, from the development aspect of it, right? When Oculus got acquired by Facebook, 2015, I was one of the first engineers to help them incorporate basically Oculus into the Facebook development infrastructure. With that, there's a lot of very different challenges because the Facebook stack was built for web development, like end-to-end is the way the assumptions made in the CI system, the assumptions made in the source control system. A lot of them did not hold through when you suddenly add Windows to the mix and you add a large file system.

[0:11:14] JMC: Exactly. Give us a sense of what you found in the Oculus stack?

[0:11:17] DSP: Yes, in the Oculus stack. It was a very traditional gaming stack. You would have 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 cash around for it. 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. So, it was just these massive different aspects. Then, of course, the really big one is Facebook was a Linux shop, like the server is Linux. Everything is a unique space thing. You develop on a Mac and you deploy in Linux, and suddenly you bring Windows into the mix. 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? So, that was a big, big lift for us.

[0:12:14] JMC: Oh, my God, that must have been a ton of work and fascinating.

[0:12:19] DSP: Quite fascinating, not necessarily fun at all times.

[0:12:23] JMC: Okay, noted. So, 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 yes, what were the initial stages of this? What sparked it all?

[0:12:41] DSP: Yes, I think that's a good question. So, thank you. Well, I joined Anthropic like April last year, and one of 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? One of these first things you do is when you look at how you enable people to do this, is what is there, and what is required still to do this? 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. 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. You had like a very visual interaction, but at the same time it was lacking like file system access or access to external system in any kind of form or shape. We also obviously work with like editors. I at the time was working at Zed, with a Zed editor. So, these editors obviously had file system access, but they lacked, on the other hand side, this like beautiful ability to like create diagrams and all these other things.

So, you had these like different clients that had strengths, but none of them were quite extensible and none of them was hard to build for. 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? Then, I also worked on similarly, on something like, yes, like an LSP-related thing, which is the language server protocol. If you look at the language protocol, server protocol, you very quickly see that MCP is very inspired by that. 

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 creating little scripts, by creating little things to tell these things what I care about. It should probably be some form of protocol so I can use it both in an IDE and I should use it both in Cloud Desktop. I proposed this to a local friend of mine called Justin Spahr 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.

We took it from there as a two-person project, honestly. That was very bottom-up. That's how MCP came to be, right?

[0:15:13] JMC: It was like the Euro Tunnel connecting France and the UK that each one was digging through from each end and then met at the middle, right? You yourself from Zed, and he was building it from Cloud Desktop. So, how did you become acquainted with LSP? Was it from your days, getting acquainted with the Oculus stack, or the Microsoft stack?

[0:15:32] DSP: 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. 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. 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 because 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. You just try to pattern match and I felt LSP was a very good pattern to match it.

[0:16:15] JMC: 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?

[0:16:27] DSP: Yes, so LSP does this classic N2M problem, solves this classic N2M problem that IDEs have with language integrations. So, 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 like 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. They could not care about like how to build a great IDE experience.

So, the LSP came around as a Microsoft an 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 information tell the IDE certain things so that the IDE can display, type in, so that the IDE can do refactoring of the code base." That way, not everybody has to build a Python implementation, part Python. And you all can go and focus on new IDE stuff and do a better job at that. You'll see it in all IDEs. It would be in a VS Code, it would be in JetBrains, it would be in Zed. It would be everywhere we use LSPs for interacting with language syntax, with refactoring these types of things. So, it's basically always there, you just barely notice it anymore.

[0:17:52] JMC: 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. But yes, how do these things interact? Could you define each one of them, et cetera?

[0:18:06] DSP: Yes, absolutely. So, MCP really is, it's first of all an open protocol, and I think the protocol bit is that it solves this like N2M problem of clients to context providers, it is a protocol between AI applications and context provider for these applications. What this does and what the key actors are, is like, there's the actor is the application, like for example, Cloud Desktop or for example, IDE, and some form of context provider, which is usually a program that provides some context to that AI client. It could be in form of tools and can be in form of resources. 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 you 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, so Cursor could decide how to deal with it and how to use this to ask the model something. 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 like 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 do you have a rich interaction with an LLM? That's really what it boils down to.

[0:20:01] JMC: Okay, we'll go back into the protocol bit that you described briefly in 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 anyone that is at any other command that is at the core of it? And how do they interact and work?

[0:20:21] DSP: Invoke, response, and error in the sense that it's a protocol that uses inherently like an RPC mechanism. So, like a remote procedure called 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. The actual primitives or the actual semantics of the protocol are then slightly different. Again, these boils down, 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 is a result to it. So, those are really the key concepts, so to speak.

[0:21:07] JMC: Okay, so the compute is happening, if I'm using Claude Desktop, the compute is happening in the cloud, because the model is hosted there. The client is Claude 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. It goes back to the Cloud. 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, Claude 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?

[0:21:57] DSP: I think that's one instance of a correct description. I think so the client, yes, the client deals with the and that model can be Claude. It can be, of course, like an OpenAI model. It can be anything. So, the protocol itself is model-independent. The client applications, so like in this case, Claude Desktop, can either go back to the cloud to remote a server, be it something hosted on Cloudflare or somewhere else. But also, the protocol also allows an 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 Claude Desktop client interacts actually with like a local program, which we call the MCP server.

It's slightly confusing because a lot of people have the assumption that a server is always remote on the Internet. But in this case, it leans into the English name of serving something, and its serving can also happen locally, right? It's just a separation between concerns of a client and something that serves the context upwards.

[0:23:06] JMC: Is this setup able to manage a state? I mean, so how does it do it?

[0:23:10] DSP: Yes, 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 like a running program. So, with that, the protocol has an initialization sequence. The client tells something about itself to the server. The server tells something about itself to the client. Then from there on, they having invocations and results. Throughout those, the application can very much hold state. 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, this like MCP server application or program is responsible, in the end of a day, for how to manage that state.

So, they are inherently, they can be stateful, they don't have to be. That's really what it is.

[0:24:07] JMC: So, you've mentioned the inspiration from LSP. I can think of many other protocols, HTTP, UDP, et cetera. Did you get inspiration from many others or was it mostly from LSP? Did you pick and choose?

[0:24:19] DSP: I think we always looked at different protocols and what are the best fits and look at what makes the most sense. I think there's of course a lot of things in what we call the transportation layer. This can be HTTP. There can be different ways. There can be WebSockets and other things. So, there's some inspiration there. I would say the vast majority of the inspiration came from the language server protocol. It is 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 Mercurial, because actually Mercurial 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. So, there's a bit of inspiration on 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.

[0:25:36] JMC: Okay. So, the MCP universe that you co-created has exploded, especially on the tool side. 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? You've chosen your LLM of choice. You are going to use our Claude Desktop. What about what the rest offers? What the world is offering up there? Does it help with that at all at this stage?

[0:26:08] DSP: At this stage, there's no automatic mechanism to like explore what's out there. You would have to go search the web, download like an MCP server and expose it that way. 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. How do we improve? Of course, there are other aspects of that. They'll want your Cursor, so randomly download tools from the Internet and execute them because at the end of the day, they're code execution. They're security aspects of that problem. But there are things like a centralized registry that we're thinking about and working towards that will facilitate.

[0:26:57] JMC: Makes sense.

[0:26:59] DSP: Some of that discovery aspect to it.

[0:27:01] JMC: So, as I say, the community has exploded. There's contributions of all kinds of servers, of all kinds of tools out there, but also at the enterprise level, at the company level. I assume we can only be surprised because who creates something months ago and knows about the CEO of Microsoft, the CEO of Google, literally tweeting about the CEO of OpenAI. So, I guess my question is twofold, like, how did you take that at the personal level, that those such important people were tweeting about it? But most importantly my question is about collaboration, like OpenAI adopted MCP, Google the same. So, how has that collaboration working? How did you take that?

[0:27:45] DSP: Yes, I think on a personal level, I think you cannot really prepare mentally for such a such a success, at least. I probably, is not the kind of person who would believe that this is where it would have ended. I would have been way more critical and probably more conservative in my estimations here. So, this, it's cool in a way. I'm also, somewhat stressful because now there's a lot of eyes on the things and you need to move quite quickly and get things right. But that's how it is. I, at the moment, just take it one day at a time and try my very, very best. I also have been around long enough that I know how the Internet works and eventually getting high up there and there might be a fall after, you never know. I sure hope it doesn't.

But in the collaboration bit, we are very early in our thinking around like governance. But, for example, there's clearly like a need for more formalized governance models. At the moment, we're running, this is a very old-school open source project, similar to the ones I've experienced clearly like PHP and Mercurial, which is basically like contribution-based. You are a merit-based contribution. If you contribute, you get to eventually have commit access. For example, the Pydantic people, they're a set of really fantastic Python engineers, helped a great deal on the Python SDK. Of course, they have commit access to it now.

There's a lot of that, but I think it needs a more formal process as we're having larger companies There's various interests in it in the whole mix and so we're working through ideas around like different governance model, be it with this official standardization organization, be it with something more nuanced like a Linux foundation or other aspects that we're talking to. Then, of course, we're having channels and an engagement with them and trying to figure this out together, because again, MCP only works if it's an open ecosystem and if it's an open protocol that everyone feels safe to use, even competitors with each other feel safe to use. That's what we're striving to build.

[0:29:48] JMC: Obviously, as you just mentioned, the project has literally exploded. So, the governance, the project management tools that the more mature projects have in place, because they've had enough time to develop, enough time to invest in that, does not exist at the minute and MCP is just a matter of time. So, it's quite difficult to answer this question that I'm going to pose you to you now, just give me your, I guess, your best answer. Because if you don't have that in place, you probably don't know, with a high degree of accuracy, what the community is requesting, right? Because with a proper instance of GitHub, you would be able to see how many issues there are about this and that. If they're repetitive or it's about the same thing and stuff like that.

But my question is, what is in your opinion, what the community is right now requesting the most? What do you think is the next contribution whenever this is already put in place?

[0:30:40] DSP: Yes, that's a good question. So, I think it is always difficult in all large projects to like, what's the right thing to focus on? There's a of having trust where the external people that have strong opinions and usually are right on these opinions that you trust, be it input from the Google from the OpenAIs in the world of like where do they feel they should go and like consider this very carefully. There's obviously a good set of like your own opinions and your own convictions that you need to have and just like every other good open source project, you might sometimes disagree and you just move forward.

But I think from the things that are very obvious that people at the moment ask for, it's like there's a one big thing is like, how do I effectively have these MCP servers super smoothly running a cloud, like in a cloud environment, and in Cursor, and Claude Desktop, all I need is your URL, and I suddenly can connect to my GitHub account via the yellow LAM, or I can connect to my PayPal account or what it might be. In there, there's two big parts. One is authorization. We have an early specification on authorization that I think was mostly right, but had some problems around particularly enterprises. I'm working very closely with some of the big enterprise identity providers to figure out what's the right path forward. I'm exceptionally grateful that I have people from Microsoft, from AWS, from Okta, a lot of the laws specification authors that are really experts and have done this for 20 years to help me figure out what's the right approach and what's the right way to do this. So, that's one of these big features people asking.

The second big feature is the ability to really scale these servers horizontally when they are in a web environment, and that's required a bit less statefulness than the protocol has at the moment. There's already what is actually, I think, the right approach in the specification, but there's not that many implementations in the SDK. So, we need to work towards that. It's a big feature. Then, there are people who want to have a bit more streamability of certain things. That is a big one. So, those are the three more directly like next bits. Then there's, of course, an ongoing discussion which form and shape do agents take? Then there's a lot of exploration. I don't know. I don't have an answer. I don't even have a really formed opinion just yet. I think MCP fits into the ecosystem very well and it solves some of the problems. But it's unclear if it solves all of these problems. So, there's a lot of work in that. It's like in the six months horizon.

[0:33:13] JMC: What about yourself, like selfishly, or your co-creator or even Anthropic? What would you like as a company yourselves to see in the next few iterations of the protocol? Are you bullish about some features? I mean, that you can give away. Obviously, you don't talk about anything that is not revealed yet. Where would you like it to go apart from the directions that you already pointed out?

[0:33:34] DSP: I can't really talk for the company here, but more for myself. I think for me, at the moment, it's less about what the specification needs to do. I think the specification is actually quite good and very opinionated and not too broad. What is more of the case is what I want to see is more support on clients for the full set of what the protocol can offer. There's a lot of really interesting bits and interesting patterns people can develop if all of these things will be implemented. For example, we have scattered resources. So, you can expose these whole fine-like objects from MCP servers to a client. And one of the ideas was like, this can be a way for something like Cursor or something like Claude Desktop to do RAG, like retrieval and index these kinds of resources first. Nobody really is doing this yet.

But I think it's a very interesting way to go like, "Hey, I can build retrieval on top of this." Similarly, you can, there's a feature called sampling, which is horribly name. In MCP world, naming was definitely not our strengths. But what sampling does it is a way for a server, so for one of these applications that provide context to model, like in order to be independent from the model, it can't have its own Anthropic SDK with itself. It needs to know what is the client using? Which model do you currently have selected in Cursor? So, sampling is away from the from the server side to go back to the client and ask it, give me a completion from a model. But the interesting nature of this is if you, and it's hard to do it without visualization, if you really think to through, you can actually chain MCP servers and clients together and chain them indefinitely long and build like graphs of fairly complex agents, and they all, all of the inference, all of the bits, all of the final say in how this whole thing runs is still by the client.

So, there's a recursive pattern this whole thing that people are yet to explore. And there's some things like MCP agent that try to do this and they're great, but I think people can do more exploration in that regard. So, there's a lot of these features that are a bit more hidden and very not much supported because the vast majority of clients currently only do tools and tools is 10% of the spec.

[0:35:54] JMC: I mean, again, I think that's a function of the fact that this just literally A, exploded, B, end protocol is just very, very young. Honestly, I see this, what you're pointing out is very normal, under usage of a protocol that is not vast, but it's flexible enough. It's got hidden features as we see, probably you didn't even mention all, but also there's a bit of confusion like with all things that explode in the Internet and particularly in Twitter and Mastodon, and all these, you get just little bits and bytes of information that if you don't go to the actual protocol and read it, which I'm sure that 80% of the people have not done, you get confused.

I've seen Solomon Hykes, for example, the founder of Docker, having questions about standard, well, actually considering a standard, and I think it's a protocol that may aim to become a standard, like he was pointing out before, correct me if I'm wrong. But also, he said, and this might actually be true, and this is a question I'll pose to you in turn. Is there a clear boundary between tools and agents? I know that agent is now a really loaded word, but yes, is there a clear difference between those two?

[0:36:58] DSP: This is one of these things, I think, that requires exploration, which I don't have a good answer. It does feel to me tools fit into this, they might be good enough, they might not be good enough. There could be a conversational aspect to agents, and the reality is, I think, we have not experimented enough with different forms of agents and how they can operate to really have a formed opinion of how this works.

I think the similar to tool use, for example, is a good example. By the time it landed in MCP, it was a thing for a year already and like some of the models, the actual research paper was like four years old or three years old, right? So, these things take a little bit to understand the actual like general structure of how these things go. I think tools will play a massive role in agents and there's a lot of tool-like things. There will be necessary in the mathematical sense of like they're necessary, but I'm not sure if they're sufficient, if that makes sense.

So yes, I don't know. The answer is, I don't know, go, let's try it out, right? That's like a very practical hat, and just try and see what sticks, right? MCP doesn't have to be the final answer to everything. It just can be also, there could be additional things, and additional protocols are built on top of it or extensions to MCP.

[0:38:16] JMC: Even yesterday, I'll ask you about it. I'll just mention it. Google released Google Next, which is being taken place this week. I believe it's A2A. I can't remember what it stands for. It's application to application, maybe. Another protocol. And the diagrams and why I read from it seems to be complementary. I mean, I've actually seen several tweets from relevant people. So, look, this is the discovery of a new continent and it seems like you are charting it. I see this, to be honest, and this is my actual comment. A bit like the Kubernetes moment in which the CNCF was created or even before that, but the whole ecosystem was created that Kubernetes enabled, right? So, it does feel like MCP could become the underlying technology protocol in this case of something much bigger. Would you agree? What would you see that evolve in? In what direction?

[0:39:07] DSP: I certainly think that MCP is the right abstraction for a subset of the promise people will have. I think it is foundational in that regard. I'm just not sure if, does it need to be the only one or is there additional complementary bits like an A2A on top of it? I think that's the exploration phase that we're currently in, where we're like, "Yes, there will be more to this." Say, there are some foundational truths to certain things, like for example, the Docker and the Kubernetes ecosystem eventually became that like OCI containers are like some of these foundational things, right? But they're not the only thing that is required in this ecosystem, they're just a very important part to the ecosystem like OCI containers, right?

So, I think it's similar to this type of thing is that this is potentially very foundational and very useful for a lot of people, but it's probably not the only entry. I think you see this in the web, if you really think about a lot of the additional pieces that did go a bit like additional semantics on top of HTTP and even additional entries that are complementary, like WebSockets to some degree. They all can exist at the same thing, but it does not take away the importance of HTTP. It just means that HTTP can't be everything at the same time. So, I think the same way for MCP.

[0:40:17] JMC: So, we're wrapping up here. I want to go back to actually to the beginning. Yourself as a software engineer that is actually, that has software engineers as the clients, the users of your work, right? Throughout your career, you've worked 90% on developer tools and the outcome of a good design, well-built, solid developer tool is that a good developer experience to keep it quite abstract, right? Enabling developers to become faster, to feel comfortable, to have a lot of affordances and learn faster tool, commands and all that stuff.

You, as a software engineer that has a ton of experience building that infrastructure that enables other software engineers, how do you see the future with AI? The intersection between software engineering and particularly the building blocks of it, the build mechanisms with AI. Are you quite excited? Are you using it in other ways at Anthropic?

[0:41:11] DSP: I'm super excited about it. I think, as one of the software engineers the software engineers had worked quite, I'm not so formative, but people I certainly feel inspired by, like Carmack, had a very great - like John Carmack, had a great take on this, of these tools, similar to all these other things and abstractions we had over the decades, are great enablers to be more productive for the people who understand how to use them and who understand the underlying systems, but don't have to do the boilerplate things anymore. They don't have to do some of the grunt work that has been taken away. We don't write assembly anymore.

So, we have great compilers, and that's one of these abstraction instances, and I think this is just another one of these, and I'm exceptionally excited for how these things go because I don't think it takes away from the human creativity, I think, but it makes it more easier for people to express themselves. So, I'm quite interested and see where this goes. I'm very excited, but I don't know where it goes, because I think the space is a lot of flux, and I think if you had made predictions a year ago, you'd probably like to have, if you're lucky, a 50/50 chance to be right of how things are today. So, it's so exceptionally hard to understand where it goes.

I'm just excited and being someone who just loves technology and I've always loved technology and I've been always curious. So, for me, it's just a big, big playground to play with and I'm very, very happy that the playground has to offer, new amazing toys that seem to be way more fun than the old things that we have played with.

[0:42:49] JMC: For all the software engineers that are listening to us that want to get engaged, start the first steps with MCP, how would you suggest them an opinionated 101 that you would provide them about how to get their hands dirty for the first time?

[0:43:03] DSP: Yes, I think that's a good question. For me, the things that have always been important, there's two things to that. On one hand, play around. If you're a very practical person like me, use the SDK, play something, feel that magic that I feel a lot of people see and what I think makes a lot of the virality of like -

[0:43:19] JMC: How many SDKs are there already? You've mentioned the Python one in the beginning.

[0:43:23] DSP: There's Python, there's TypeScript, there's C#, that's actually provided by Microsoft. Very thankful for them to that. There's Java, which is provided by the Spring people, which I'm very thankful for. There's Kotlin, which is provided by the JetBrains people, which I'm very thankful for. There's a very likelihood that Google is going to work towards a Go SDK. There's a lot of other open source, Go SDK is already there, really great.

[0:43:43] JMC: There's no Cobalt one? No Cobalt?

[0:43:48] DSP: We might not need that. You can go. Maybe Claude can write that. You never know. I have a good feeling that Claude might be able to write you a Cobalt.

[0:43:55] JMC: That's better than I would, think, sure.

[0:43:57] DSP: I think you should just go and try this thing and play around with it and feel a little bit of that magic of like making the LLM do something that you care about. The other day, I was like, I have a lot of friends to play video games with and we never and figure out which games you should play. So, I built an MCP server through all our Steam libraries into Claude and had Claude tell me which games you should play next, which actually was a very good fit. So, this is a little bit of magic of things you can make an LLM do and have a little bit of like getting into your life and what you care about. So, this is the magic you want to feel.

But then, and I think that's for everything, I've never stopped there and try to understand it. Go read the spec, read what's possible, be creative, and figure out what you could do and dream about what you could do with it. I think that's how you should treat things, try them, but also deeply understand them. To be fair, MCP, if you really look at it, it's actually fairly simple, so there's not that much magic to it. As everything, in the end of the day, it's a bunch of code, so just go deep.

[0:45:00] JMC: By the way, I hope that MCP server that suggests new games, suggests Commandos Origins, which literally came out in Steam yesterday, and it was developed by a Spanish company back in the day, the first three versions, but this new one, which looks fantastic, has been developed by a German company, which I didn't know about, a German video game studio. So, check it out, it looks grandiose, and the first reviews literally came out yesterday, the 9th of April. It looks just great. So, I hope that MCP servers pointing the right direction.

[0:45:31] DSP: Yes, I'm definitely going to check this out because I'm always looking for some good evening fun.

[0:45:36] JMC: Oh, Commandos, is just great. But yes, my next question you already answered partially, that was a good incentive to start getting their hands dirty with MCP, to download the SDK, to fiddle around, to build something, break it again and do it again and so forth. The maturity of the project from a governance perspective, you probably don't want to encourage wave of contributions because it will only add to your stress and you've got a young kid and stuff like that and personal life to devote to. But if anyone has already read the protocol, is already sort of familiar and wants to contribute, how would you advise to get at least engaged with the community? Would you have any directions, any pointers?

[0:46:13] DSP: I think there are many, many ways. this. On one side, there's the SDKs where you can actually actively contribute and we're always looking for contributors that do patches, bug fixes, even go through read through the issues, and try to reproduce them and help people with answers. I think there's a big part there, add to the documentation where it's missing because the documentation can - I've never seen a project that doesn't need more or better documentation. That's always true for every project. And then, of course, if you really want to and you feel you have a very good contribution, go pull requests for the specification. But then the bar there is, of course, very high, as you can imagine. And then, of course, like, there's lots of communities that have popped up that I'm not even able to
keep track of, be it on Twitter, be it on, there's a Discord, there's a bunch of Discord servers, there's some Reddit communities, just engage with them and find people that are interested and build something very, very cool.

Yes, I think that's just a way, find the way that you enjoy the most, speed for some people, documentation writing, for some people writing code, for some people like chatting and exchanging ideas with other people. There's tons of meetups in the big tech hubs around MCP. Go to those if you love the social aspect of it and go and have a chat about it. I think that's just like find your own personal way, how you care.

[0:47:28] JMC: Yes, at this stage of the MCP maturity, the maturity of the ecosystem, it seems like that you're completely able to do your own thing, even regardless of the sort of like the official project, because as I was saying before, this thing has exploded. So, clearly you guys have hit the nail in the head. I'm really happy for you that you've - I mean, you already had a really successful career, but it seems like this is a major discovery, a major piece of technology that you've contributed to the world very kindly, so I'm really, really, really happy that you guys did it and you did it in such an open and flexible way, to be honest.

[0:48:06] DSP: Yes. Thank you. The openness is like that's so important to me, but like if you look at the history, like I've always loved open source. I truly believe in it. So, it's very obvious that that's what I had the path I would want to take.

[0:48:17] JMC: Did we miss anything that you wanted to touch upon about MCP or are you good with that?

[0:48:24] DSP: No, just play around with it. Just do cool stuff. I think, that's the end of it. Be creative with it. I love the MCP servers, that interact with Ableton, that interact with Blender, love the MCP servers that program your synthesizers and these types of things. Just be very creative. That's for the most part it. Thank you, Jordi, so much for the conversation. We really appreciate it.

[0:48:45] JMC: The pleasure has been mine, David. Thank you so much, or David probably. Thank you so much for being with us and again, yes, I encourage everyone to try MCP, read the protocol, it's very straightforward, it's not that long, and the tools are there. So, you just need to start fiddling with an SDK, launch your server in a container locally. Docker has done splendid things in that sense. The OCR community I'm sure will eventually contribute something if it's not yet there already. Thank you so much David. Take care.

[0:49:15] DSP: Thank you. 

[END]