← Software Engineering Daily
Software Engineering Daily
Anthropic and the Model Context Protocol with David Soria Parra
00:51:02
The Model Context Protocol, or MCP, is a new open standard that connects AI assistants to arbitrary data sources and tools, such as codebases, APIs, and content repositories. Instead of building bespoke integrations for each system,
Loading summary
Transcript67 lines
- [00:00]
Jordi Mon
The Model Context Protocol, or mcp, is a new open standard that connects AI assistants to arbitrary data sources and tools such as code bases, 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 Soriapara 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 jordymon Companies. Check the show notes for more information on Jordi's work and where to find him.
- [01:01]
Host
Foreign welcome to Software Engineering Daily hi.
- [01:08]
David Soriapara
Jordy, how you doing?
- [01:09]
Host
I'm doing well, so why don't you introduce yourself?
- [01:12]
David Soriapara
Yeah, 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 sting in a venture capital called Sutter Hill. And yeah, I've you know, since a year I'm at Anthropic as a software engineer.
- [01:29]
Host
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 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? Were your first steps in this world?
- [01:56]
David Soriapara
Yeah, well thank you. That I have been doing software engineering or like programming probably since I'm 14. It started very simple like of 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 and then how I started learning PHP at like the age of like 14, 15 and I've 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 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 it like eventually you ended up on like adding your first patches to the actual language. You know, instead of writing php, you're suddenly writing C. That quite early around like, you know, the early 2000s, I've started contributing to PHP itself and worked in that field. And I was just very lucky enough that I had a bunch of mentors along the, 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, dabbled a little bit into Git and other things. So that's a bit of like the early days for me.
- [03:26]
Host
Exactly. So PHP is programmed in C and so is Git. Right. I didn't know about Mercurial. So is it programming 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 they already seen that Git was inevitable. Or was it not? Was it Mercurial? That was the hype back in the day.
- [03:56]
David Soriapara
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. So 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 project 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 like these like 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 mccurl and then there was Git and it was a bit like, you know, the editor work from the early 90s between Vim and Emacs, there was a bit of like the decentralized version control system war. 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 McCurry 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. Then the second of all, I think the. The Linux community was really where 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. And so that's how I started contributing to mccurl rather than to Git. I had some patches in Git but eventually I just ended up working for the most part on Mercurial.
- [05:42]
Host
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, Junior Hamano, 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 is 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, bulk and etc. So it feels that your career is 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 could talk about the stack at 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, et cetera.
- [07:07]
David Soriapara
Yeah, absolutely. Funny enough, I think never. Nobody has ever looked at this as the whole thing like, oh, this was destined to. You were destined to join Facebook. But I think it makes sense in retrospective qu 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 by the end of 2012 or something along the lines and I was not considering joining a big American company because I was living in Germany and I just worked in these little companies and I would have probably not by myself went and go and apply to Facebook. But it happens that the McCurial community itself got together like once a year and we were sitting in Stockholm and at that time for one of these events and at the time Facebook had quite an interest in McCurl as like 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 Mercurial. 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. 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. And so and so I think that was really, really cool. And that goes like back into this unique stack that Facebook similar 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 that just few people had in 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 how do we want to have one big repository for everyone or do we want to have 1,000 repositories for each team separately? There are very different trade offs to be made and there's a lot of in depth like why you would choose one or the other. But Facebook eventually chose similar to Google and probably very inspired by Google a mono repository approach. And with that you like inherently know you will have scaling issues because you can draw these graphs of like commit rates and sizes of things that you like. 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. So it becomes way more efficient for these companies to go and optimize by building a team. And so you build a version control system, you 10 people, and you 10 people optimize the hell out of PHP. Way cheaper than making 1000 people change version control system or change programming language. And so that's a lot of how these techs came to be because they were issues that nobody else had before.
- [10:12]
Host
Okay, so it seems that, you know, first stay the first stint, the first part of your tenure at Facebook, I'm going to keep calling it Facebook because it technically was at that time was on build tools, on the performance and enabling software engineers there to contribute to the Monorepo, etc. 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?
- [10:42]
David Soriapara
Mostly, again from the development aspect of it. Right. Like, so when Oculus got acquired by Facebook 2015, I was one of the first engineers who helped them incorporate basically Oculus into the Facebook development infrastructure. And with that, you know, there's a lot of very different challenges because the Facebook stack was built for web development for like end to end. The way the assumptions made in the CI system, the assumptions made in the source control system, and a lot of them did not hold through. When you sudden add Windows to the mix and you add large file systems.
- [11:14]
Host
Exactly. Give us a sense of what you found in the Oculus stack.
- [11:17]
David Soriapara
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. And 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 server 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 just like nothing works anymore. Because you work against 15 years or 10 years of assumptions made around Linux. That was a big, big lift for us.
- [12:15]
Host
Oh my God, that must be, must have been a ton of work and fascinating.
- [12:19]
David Soriapara
Quite Fascinating, not necessarily fun at all times.
- [12:23]
Host
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, don't 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?
- [12:42]
David Soriapara
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. And 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 of shape. We also obviously worked with like editors. You know, I at the time was working at Z with a Z editor and so these editors obviously had file system access but they lacked on the other hand side, this beautiful ability to create diagrams and all these other things. So you had these different clients that had strengths but none of them were quite extensible and none of them was hard to build for. And so that's where I was thinking about how do you enable people to build and really enable the workflows you care about in these systems. And then I also worked on similarly on something like an LSP related thing which is the language server protocol. And if you look at the language 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. And 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 Sparr 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 Z. And so we like really took it from there as like a two person project. Honestly that was very bottom up. That's how MCP came to be. Right.
- [15:14]
Host
It was like the Eurotunnel connecting France and the uk that each one was digging through from each end and met at the middle, right? You from yourself, from Z and he was building it from Claude desktop. So were you familiar, how did you become acquainted with lsp? Was it from your day getting acquainted with the Oculus stack or the Microsoft stack?
- [15:33]
David Soriapara
Well actually that's just from my work at Anthropic. I was actually working on like an LSP related experiment trying to build like 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 like a little lsp. And of course from there I looked into the specifications and I understood how these things are going to work. And then at the same time, when you are have decided that you need some form of protocol, you go and shop around and look at a 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. And so you just try to pattern match. And I felt LSP was a very good pattern to match it.
- [16:16]
Host
I was not aware of lsp, where is it currently being used? Like, I mean, and you got wind of it because you were doing some research and so forth. But how is it used in production? In what projects? Like what is the main use case of lsp?
- [16:27]
David Soriapara
Yeah, so LSP is this classic end to end problem solves this classic end to end problem that IDEs have with language integrations. So before LSPS 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 and they could not care about how to build a great IDE experience. And so the LSP came around. It's 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 tell, have that information, tell the idea certain things so that the IDE can display type ins that the IDE can do refactoring of the code base. That 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 Z everywhere ides like it would be everywhere. We use lsps for interacting with language syntax, with refactoring, these type of things. And so it's basically all always there. You just barely notice it anymore.
- [17:53]
Jordi Mon
This episode of Software Engineering Daily is brought to you by Capital One. How does Capital One stack? It starts with applied research and leveraging data to build AI models. Their engineering teams use the power of the cloud and platform standardization and automation to embed AI solutions throughout the business. Real time data at scale enables these proprietary AI solutions to help Capital One improve the financial lives of its customers. That's technology at Capital One. Learn more about how Capital One's modern tech stack, data ecosystem and application of AI ML are central to the business by visiting capitalone.comtech.
- [18:34]
Host
So for our listeners, can you break down the core concept of ncp? 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 yeah, how do these things interact? Could you define each one of them, et cetera?
- [18:49]
David Soriapara
Yeah, absolutely. So MCP really is 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 like 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. It could be in form of tools and could be in 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 be, can 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. And 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 that you have a rich interaction with an LLM. That's really what it boils down.
- [20:44]
Host
Okay, 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. If it's 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?
- [21:04]
David Soriapara
Invoke a response and error in the sense that it's a protocol that uses inherently like an RPG 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. The 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 like again, prompts, resources and tools. These are the more high level things. But of course they're getting even invoked in a way from the server and there is a result to it. So those are really the key concepts, so to speak.
- [21:49]
Host
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 is that could be a set of PDFs or something more agentic, for example, something that is running in a server somewhere else. So it goes back to the cloud, right? So that 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?
- [22:39]
David Soriapara
I think that it's one of the correct. 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 OpenAI model. It 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. Servers, they 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, but 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.
- [23:49]
Host
Is this setup able to manage a state? And if so, how does it do it?
- [23:53]
David Soriapara
Yeah, it does. Like in the end of the day, the MCP server is a full application. It's like a little. 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 there is the protocol, you know, has an initialization sequence. It tells the client tells something about itself to the server, the server tells something about itself to the client, and then from there on they having 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. 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. That's really what it is.
- [24:50]
Host
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?
- [25:01]
David Soriapara
I think we always looked at different protocols and what are the best fits and like look at what, what makes the most sense. I think there's of course a lot of things in the, what we call the transportation layer. So like how like this can be HTTP, this can be. There can be different ways it can be, you know, 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 and it is very closely related. A lot of the, the mechanisms, how the protocol actually work are very deeply grounded in how LS LSPs have done it. You know, 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 mcurl because actually mercurl, 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 message by using headers. And so there's a bit of inspiration on all of them. Then of course now when we talk about authorization, other bits, a lot of it is very directly from the web and like how the web works.
- [26:19]
Host
Okay, so the MCP universe that you co created has exploded, especially on the tool site. 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 pool discovery like you do the you've chosen your LLM of choice, you are going to use Claude desktop. What about what the rest offers, what the world is offering out there? Does it help with that at all? At this stage?
- [26:51]
David Soriapara
At this stage there's. 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. And then within that aspect, you know, 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 are looking into, like how do we improve? Of course there are other aspects of that. You don't want your cursor. So randomly download tools from the Internet and execute them because in the end of the day their code execution. There are security aspects of that problem, but there are things like a centralized registry that where thinking about and working towards that will facilitate makes sense some of that discovery aspect to IT developers.
- [27:45]
Jordi Mon
We've all been there. It's 3am and your phone blares, jolting you awake. Another alert. You scramble to troubleshoot, but the complexity of your microservices environment makes it nearly impossible to pinpoint the problem quickly. That's why Chronosphere is on a mission to help you take back control with Differential Diagnosis, a new distributed tracing feature that takes the guesswork out of troubleshooting. With just one click, DDX automatically analyzes all spans and dimensions related to a service, pinpointing the most likely cause of the issue. Don't let troubleshooting drag you into the early hours of the morning, just DDX it and resolve issues faster. Cycronosphere was named a leader in the 2024 Gartner Magic Quadrant for Observability Platforms at Cross Chronosphere IO Sed.
- [28:34]
Host
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 you 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 a 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's that collaboration working? How did you take that?
- [29:18]
David Soriapara
Yeah, I think on a personal level, I think you can not really prepare mentally for such a success. At least I probably are 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 it's cool in a way. 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 and I at the moment just take it one day at a time and try my very, very best. And 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 governance, but there's for example, there's clearly a need for more formalized governance model. It's at the moment we're running this as a very old school open source project similar to the ones I've experienced, clearly like PHP and the Carril, which is basically like contribution based, like your merit based contribution. If you contribute you get to eventually have commit access. So for example, the Pydantic people, they're a set of really fantastic Python engineers, helped a great deal on the Python SDK and of course they have commit access to it now and so 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 different governance model, be it with official standardization organization, be it with something more nuanced like a Linux foundation or other aspects that we're talking to. And then of course we're having channels and engagements 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. And that's what we're striving to build.
- [31:21]
Host
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 in mcp. It's just a matter of time. So it's quite difficult to answer this question that I'm going to pose to you now. Just give me your, I guess your best answer. No, 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, 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? Like what do you think is the next contribution whenever this is already put in place?
- [32:13]
David Soriapara
Yeah, I think that, yeah, that's a good question. So I think, I think it is always difficult in all large projects to like, what's the right thing to focus on? And there's a combination of having trustworthy external people that have strong opinions and usually are right on these opinions that you trust, be it input from the Googles, from the open AIs in The world of where do they feel they should go. And consider this very carefully. There's obviously a good set of 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 is like there's a one big thing is like how do I effectively have these MCP servers super smoothly run in a cloud, like in a cloud environment and in cursor in cloud desktop? All I need is your URL and I suddenly can connect to my GitHub account via the LLM 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 around authorization that had 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 like figure out what's the right path forward. I'm exceptionally grateful that I have, you know, people from Microsoft, from aws, from Okta, a lot of the O 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. And so that's one of these big features people are asking. The second big feature is the ability to really scale these servers horizontally when they are in a web environment. And that requires a bit less statefulness than the protocol has at the moment. There's already like 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 those that that's a big feature. And then there are people, you know, want to have a bit more streamability of certain things. That is a big one. And so those are the three like, like more directly like next bits. And then there's of course there's an ongoing discussion which format shape do agents take. And then there's a lot of exploration. I don't know, 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. And so there's a lot of work on that that's like in the six months horizon.
- [34:46]
Host
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?
- [35:08]
David Soriapara
I can't really talk for the company here, but more for myself, I think the. 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 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 would be important implemented. For example, we have this cut resources so you can expose like these whole like file 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 Cloud Desktop to do rag like retrieval and index these kind of like resources first. And 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. This similarly you can. There's a feature called sampling which is horribly named like in MCP World naming was definitely not our strength. 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 it in cursor. And so sampling is a way 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 through, you can actually chain MCP servers and clients together and chain them indefinitely long and build these 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. And so there's a recursive pattern in 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.
- [37:27]
Host
I mean, again, I think that's a function of the fact that this just literally A exploded B, and the protocol is just very, very young. And 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 with all things that explode in the Internet and particularly in Twitter and Mastodon. 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. And I've seen Solomon Hikes, for example, the founder of Docker, having questions about standard. Well, actually considering it a standard. And I think it's a protocol that may aim to become a standard. Like you were 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 boundary between tools and agents? I know that agent is now a really loaded word, but yeah, is there a clear difference between those two?
- [38:31]
David Soriapara
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. Right. There could be a conversational aspect to agents. And the reality is, I think we have not experimented in enough with different forms of agents and how they can operate to really have a formed opinion of how this works. And I think they're 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. In some of the models, the actual research paper was four years old or three years old. So these things take a little bit to understand the actual general structure of how these things go. And, and I think tools will play a massive role in agents. And there's a lot of tool like things. They 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, yeah, I don't know. The answer is I don't know. Go, let's try it out. Right. That's like a very, like my very practical hat on. Just try and see what sticks. Right. MCP doesn't have to be the final answer to everything. It just can be. Also. So there could be additional things and additional protocols that are built on top of it or extensions tend to be even yesterday.
- [39:50]
Host
I'll ask you about it. I'll just mention it. Google released and 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 complimentary. I mean I have actually seen several tweets from rather than people. So look, this. This is the discovery of a new continent and it seems like you are charting it. And 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 a 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 with what would you see that evolve in. In what direction?
- [40:39]
David Soriapara
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 just additional complementary bits like an A2A on top of it. And I think that's the exploration phase that we're currently in where we're like, yeah, there will be more to this and say there are some foundational truth to certain things. Like you know, like for example, the Docker and the Kubernetes ecosystem eventually became clear that like O 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. And 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. And I think you see this in the web, if you really think about a lot of the additional pieces that go like additional semantics on top of HTTP and. And even additional entries that are complementary like websockets to some degree. They all can exist on the same thing. That does not take away the importance of HTTP. It just means that HTTP can't be everything at the same time. And so I think the same way for mcp.
- [41:49]
Host
So we're wrapping up here. I want to go back actually to the beginning. So 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 and the outcome of a good design, well built, solid developed 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? 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 novel ways at Anthropic?
- [42:44]
David Soriapara
I'm super excited about it. I think as one of the software engineers that were quite, I'm not sure, formative, but people I certainly feel inspired by. Carmack had a very great, like John Carmack had a great take on this of like these tools, similar to all these other things and abstractions we had over the, over the like 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. Like we don't write assembly anymore, right. And so we have great compilers and that's like one of these abstraction instances and I think this is just another one of these and I, 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 make it makes it more, more easier for people to express themselves. I'm quite, quite, quite interested to see where this goes. I'm very excited, but I don't know where it goes because I think the space is a lot in 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. And 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 have been always curious. So for me it's just a big, big playground 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.
- [44:21]
Host
For all the software engineers that are listening to us, that want to get Engaged to 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?
- [44:36]
David Soriapara
Yeah, 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 side play around and 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.
- [44:51]
Host
Of like how many SDKs are there already? You've mentioned the Python one at the beginning.
- [44:55]
David Soriapara
There's Python, there's Typescript, there's C Sharp, 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 SDKs already that are really great.
- [45:16]
Host
It's quite a no Cobol one, no.
- [45:18]
David Soriapara
Cobol one, no, 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.
- [45:27]
Host
Cool better than I would.
- [45:30]
David Soriapara
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. You know, the other day I was like, I have a lot of friends I play video games with and we never can figure out which games you should play. So I built an MCP server through all our Steam libraries into the cloud and had Claude tell me which games we 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 getting into your life and what you care about. And so this is the magic you want to feel. But then. And I think that's for everything. I've never stopped there. Try to understand it like go read the spec, read what's possible. Be creative and figure out what you could do do and dream about what you could do with things. And I think that's how you should treat things. Try them, but also deeply understand them. And to be fair, MCP is, if you really look at it, it's actually fairly simple. So there's not that much magic to it as everything. At the end of the day it's a bunch of it's code and so just go deep.
- [46:33]
Host
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, 9th April. It looks just great. So I hope that MCP server is pointing in the right direction.
- [47:04]
David Soriapara
Yeah, I'm definitely going to check this out because I'm always looking for some good evening fun.
- [47:08]
Host
Oh, Commanders is just great. But yeah, 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 is, 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?
- [47:46]
David Soriapara
I think there are many, many ways, right? There's on one hand side, there's the SDKs where you can actually actively contribute and we're always looking for contributors that do, you know, patches, bugs, fixes, even go through like read through the issues and try to reproduce them and help people, you know, with answers. I think there's, there's a big part there, you know, 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, you know, go pull request for the specification. But 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 you know, I'm even like not even able to keep track of, you know, be it on Twitter, be it on like 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, that are interested and Build something very, very cool. And, and yeah, I think that's just the way. Find the way that, that you enjoy the most. Be it 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, you know, the big tech hubs around mcp. Go to those if you, if you love the social aspect of it and, and go and have a chat about it. And I think that's just like find your, your own personal way. How you care.
- [49:01]
Host
Yeah. At this stage of the MCP maturity, the, 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 you, as I was saying before, this thing has exploded. So you clearly you guys have hit the nail in the head and you. I'm really happy for you that you, 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, you guys did it and you did it in such an open and flexible way, to be honest.
- [49:39]
David Soriapara
Yeah. Thank you. Yeah, 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. And so it's very obvious that that's what I had, the path I was want to take.
- [49:50]
Host
Did we miss anything that you wanted to touch upon about mcp or are you good with that?
- [49:55]
David Soriapara
No, just, just play around with it, like just do cool stuff. That's, I think that's the, the end of it. Be creative with it. I love, I love the MCP servers that like interact with Ableton, that interact with Blender, a lot of the MCP servers that, you know, that program your synthesizers and these type of things, just be very creative. That's for the most part it. And yeah. Thank you Jordy, so much for the conversation. We really appreciate it.
- [50:18]
Host
The pleasure has been mine. David, thank you so much. Or David, probably thank you so much for being with us. And again, yeah, I encourage everyone to try mcp, read the protocol. It's very straightforward. It's not that long and it will. 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 a 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.
- [50:48]
David Soriapara
Thank you.