MCP is so back! (feat. David Soria Parra)

Key Takeaways

Hi everyone and welcome To the show. Today we have a very special guest with us. We have none other than David. David is the co-creator of MCP and maybe I'll just give you some time to introduce yourself. David, please tell us a little bit more about you. Welcome to the show. Hey, thank you for having me. Yeah, I'm I'm David. I'm a member of technical staff at Anthropic. Usually a software engineer there basically. And yeah, I've I've created MCP together with Justin as far as I remember. And yeah, that's what I do since since a year and a half and at the moment I'm mostly busy with leading leading the community. Amazing. I also wanted to ask you about so MCP, I want to say like a year ago. I remember I met you like at a random Pydantic event you were speaking about it and I think at that point MCP was just blowing up and it was like >> Yeah. I remember the event. Yeah, it was just like very tiny little event. Yes. Exactly. And it was so amazing to see like how much adoption people had since that time and how much MCP has grown since that time. I'm interested in knowing what is the story behind you creating MCP? Like how did you actually come up with that idea? Yeah, it's I think it's a um It's a good question but in the end of the day like I was I joined Anthropic in April uh 2024 and one of the things I was asked originally to do is um looking into ways for how developers at Anthropic can use Claude more in their day-to-day work so that we accelerate ourselves. And um my background is always been developer tooling. I've worked on um I'm sorry for this Marlene. I worked on PHP originally although now I'm I'm definitely a Python convert. I I I worked on PHP originally later worked on a version control system called Mercurial. I joined Facebook. Worked on developer tooling all the time. So I've been only in developer tooling. And so it's quite natural for me to take on this kind of work. And at the time and I think it's very easy to forget this like 1 and 1/2 years ago when I basically started MCP you have like Claude AI or like ChatGPT as like very simple web interfaces that couldn't do anything basically except for answering some some some questions and you had um Claude desktop but when you wanted to really go and ask questions for example about code you would have to go copy the code out of your editor Yeah. >> into Claude AI get an answer copy it back compile copy out the the like the the the problems the error messages and put it back in. And I'm inherently a very lazy person and I was like I don't think I'm very paid for um Yes, as all good developers should be. >> Yes, for for copy pasting in and out of things every day. And so that was one of the frustrations and the original idea was like going to Justin like why can I just not connect VS Code to um to the to to Claude desktop directly? And out of this came an idea that I at the time called Claude Connect which was just like hey, why don't we have like a little application from Claude desktop that starts that can that you can connect local things to because I know best what I want to connect to the model. I'm a native developer. I can do things. Um and we and out of that then I I talked to Justin about it. He's like hey, I think that sounds like a protocol. And so we then went and ahead and were like started developing this protocol with the original intent to have something within Anthropic for people to build for Claude AI for Claude desktop to accelerate the workload. And then at the time I was mostly focused on development tooling. Justin was focused on experimenting with the next thing of what you could do in in a team that we called at the time labs. And he built it into Claude desktop and I at the same time built it into an editor which is not VS Code. Um uh so I built it at the time into the Zed editor which I which I really like um and also it's open source so um >> [laughter] >> so if you go back to like September last year you will actually see already very early commits for coming in working with the Zed people to build MCP into Zed. So that was really the origin story of of what we wanted to try to do. Just basically like build that connective layer as the models getting better as tool calling really started to take off and really showed that these models can do so much you needed this way of like reaching out into the real world and so that's where the idea originally came from. That's amazing. It's I feel like so much has happened with MCP and it's only been a little over a year and so much and I'm sure you so much feedback has you know gone your way. You see what people say online. You know and now we have like MCP apps, MCP UI. There's so much going on. So I'm curious what was your biggest takeaway from this entire time of all things MCP? >> [sighs] >> I think there are multiple things. I think there there's realistically a I think there there's a takeaway of what happens when you are in a well-known company and find something that is product market fit and I think there's something to it that is quite interesting in terms of like helping people and building something for people that they really wanted this in the moment. There's there's something to be learned there. I think the the more interesting part there is from my perspective is seeing being in the middle of a growth pattern that is partially fueled by hype and partially fueled by product market fit and so this and figuring out how you deal with this because I think I think looking back we can we can definitely all agree that the the AI field particularly on Twitter and other communities is very hype based. >> Yeah. You see [laughter] this with you see this with MCP. You saw this with you see this now with Claude bot and these type of things. Um and so people do this natural thing that I I think it's very clear that they they take an idea that they have not really researched and then they go and think all their problems will be magically solved by it and then just get disappointed when 3 months later they find out it's not all magic and so I think there's something to be learned there. So I think on on on one end side um as a company we learned leaning into centralization and openness and open source and I think MCP is by far the the the biggest open source project Anthropic has done and there's a lot we've learned and I think a lot that we're feeling good about having contributed to the ecosystem. I think personally I've learned a lot about not getting a lot of the criticism to myself and trying to stay positive and yet nice and um and and I mentioned this to Marlene like trying to very hard work on learning despite the criticism despite Yeah. the attention you get both um attention that you that you maybe deserve and attention that you don't deserve um and in that realm stay more like a Guido van Rossum and less like other personalities in the ecosystem [laughter] that are a bit more a bit more toxic. Shout out Guido. We're big Guido He's just so nice. He's just like incredibly nice. Yeah, all the attention he got over the years. Yeah, an awesome awesome leader. And so what are you most most excited about? MCP MCP wise or anything I guess. Um what what gets I think I'm I'm what I'm really excited about is and and this is so abstract and philosophical but I'm actually excited that there's a standard and I don't I don't I I'm a super happy that I've I've been the one helping building it. But I'm super I'm super excited that there's a standard that everybody agrees on. I can build something once and I can connect it to everything. I think that gives me is is super I'm super happy about that because I it allows me to solve problems. I want to build you know a bot that like I want to build you know an MCP server that solves a problem for me. I can do this today and I can hook it into Claude AI and I'm happy right? And so I'm really excited about that part. I'm super excited about like where this all can lead like I'm of course like I find it very fun to look at like the developments like we've done with apps like the things that are possible there where you can just like display spreadsheets only in in Claude AI or you can display some you know comp like complicated workflow or some fun stuff. You can display I don't know a MIDI sequencer for synthesizers right? So there's a lot of things you can do. I'm I'm really and and what I love about this part is like once you build these type of things, then people that are way more creative than I am come out of the woodwork and do things you didn't know that were possible. So, when we built MCP for example, like of course very early people were like, oh, I can just connect the 3D printer to this um and let the model do things. But then like seeing people doing the blender MCP or like um like uh like some of the like music MCP servers or one that like connected to a synthesizer. I think that's so much fun to see and I'm just so curious to see what they do uh that kind of community does with apps like now as well. Um I'm super happy about this and I'm yeah, I think that's what I'm really excited about. I'm just excited when you like get like tens or hundreds of people like excited about stuff. I love it. Do you want to give us just a quick description of what MCP apps are? Yeah, so MCP apps is um the idea of um the normal text-based interfaces that um LLM applications so far mostly have um and particularly the way that MCP servers work is limited enough and you actually in some cases want to display rich interfaces. If I want to build an MCP server that that can book a opera ticket or a cinema ticket, I probably want to showcase like a seat selection. Um and seat selection is something I do not want to do in text because where like row five seat 27 is is very unclear to me. Um and so uh what this allows is basically you just like send like somewhat limited applications to Claude I and it or like any interface that implements it and have them displayed and now you have a rich interface you can interact with. And so like a literally mini web application, but the best part about it is not just you as a user can interact with it, the model can interact with it as well. You display a map for example, the model can go, you know, let me show you I don't know, where is the where is the next um Python event or whatever and just goes and and moves the map to that. And that's I think is the kind of magic where you together interact with with with an interactive interface. It's amazing. Marlene, I know you wanted to and I really want to hear about this, too. Skills skills versus MCP. >> this is >> [clears throat] >> diving directly into the hard things. Yeah, I mean it's a you talked about I'm super excited about apps and I feel like the thing is you talked about this just now, David, in terms of like the hype cycles on Twitter and and places like that. And I feel like right now there's like all this hype about skills and I've seen so many people on Twitter being like, don't use MCP, use skills. Is your MCP is over. Use skill, you know, and it's like what are your thoughts about skills? Is MCP over because of skills? Yeah, where where are we at with that? >> Yeah, yeah, I I it's done. I just shut it all down tomorrow. Um no, the um so so I think this is part of the hype cycle. I think that this I think one of the things and um that I think we have lost um in the community in the development community, but I think in to be fair and in society at large is um a more nuanced discussion um over the last uh that that is happening. And I think in skills is one of these instances where skills is really good. We it's it's an amazing thing, right? What it does is you provide these markdown files, you can even provide little programs with it and then um the model will progressively discover this. It um learn more about it when it feels it needs to use that specific skill and then go ahead and um and you maybe use a program to do something. Like for example, a skill to um format uh you know, translate an HTML page into like a PDF or vice versa or something like that. And it can it knows it reads what it how to do it and so on and does progressively do this. Now, this is great and very viable useful particularly for developers who are used to running programs locally, who are familiar with development environments. Um and so for that, skills is really really good. Now, the one thing skills basically do in the end of the day is they give a specific domain knowledge to the model. But what they don't do is they don't really provide external connectivity. And of course you can do this. You can add a Python script that has external connectivity, but if you do this, you suddenly require an API key, uh you require um you know, you know, uh uh some form of script that you know, pulls in a Google API whatever. Um and now you you need to know as a developer a little bit more and even as a user you would have to provide API keys. And so that's I think where things like MCP come in where MCP is really this like standardized way for external connectivity. It doesn't try to provide uh the knowledge of a specific domain like I don't know, like um data analyst, but it tries to provide in return like the connectivity required to go to an external service for it. Um and I think that's where they're actually very complimentary. Um the thing that I think people love about skills that it was originally built with this like progressive um progressive discovery mechanism built in. So where the model can have 100 skills and it will not know the full skill, so you don't waste the tokens for all the skills. It will only know the quintessential I'm a data analyst, I'm I don't know, I'm a code reviewer and will only read the tokens for the full skill when it requires it once it wants to use it. And people conflate that that's actually completely possible with MCP as well, just people don't do it. And so that's where I think a bunch of the tension comes from, but they're actually super complimentary in many many ways, I think. Yeah, I'd agree with that. I have been using skills that also use MCP servers in the skill itself and that's worked really well for me and I think one of the things is that programming in general is changing so much and so I think this is why we have these huge waves of hype where people discover something new. Of course. And uh but I totally agree with you that often times I think people don't really give something a full try and know what's going on. And and part of that I would say like probably comes from the vibe coding culture where we're just not even looking at the code, we're just getting our, you know, whatever it is code code or VS code to code something for us. What are your thoughts on vibe coding? And MCP is kind of used quite a lot in this process. [clears throat] Do you like vibe coding? Are you vibe coding? Do you encourage people >> [laughter] >> Um Well, well, it's it's a complicated discussion, right? It is again says nuance, right? Like um do I do if I build C++ code for a for a fighter jet or a nuclear power plant, you vibe coding might not be the tool of choice. Um so just to put one extreme out there, right? But on the other hand side, if I have a prototype, like I'm I'm at the moment I love Claude bot. I don't trust it as far as I can throw it, right? It's a it's a massive like massive amount of code. It's I have no clue what's going on in there. Um everything is vibe coded, just accept it. I wouldn't trust it at all. So I'm building my own version of it and that's like pure prototyping. And for that, vibe coding is great and and 90% of the code or like actually 100% of the code Claude just writes, I'm reviewing it, maybe part of it. I've seen probably 20% of the code, but not 100% of the code and it just runs, right? And that's great. That's that's what you want this for. And even when it comes to like standard like CRUD software like create, update, delete software. You can just have the model do this, right? Like I rebuilt I rebuilt my I was tired of having a standard um block um theme recently and I just like, Claude, just make a better theme for me and this is what I want. 10 minutes later I had a theme. I have no clue how that theme works. It just works, right? Vibe coding at extreme and but it's great, right? And but this is this is the the the the problem that people that you that you look at is like how close is the the problem space that I'm trying to solve in the rough distribution of the model. And if I look at a front end application, it'll be very much in distribution. As long as I write React or Svelte or something like that. As long as I like write TypeScript. As long as I write Python with machine learning stuff, all in distribution. If I try on the other hand side to use it for game development, well, suddenly it becomes less in distribution because it turns out there's way less game code out there in the world that is visible. There's a lot there, but everything is proprietary. Everything is behind closed doors, right? So you're way out of distribution. It's way harder for the model to be right. And then the second part to that is like understanding your blast radius. Um of like, okay, what happens if my personal blog goes wrong? Nobody cares, right? But that's different if I build again a critical service, then you have a very different bar. Would you vibe code a government website? Probably not. Would you vibe code your personal um assistance bot? Probably yes. And so I'm actually super in favor of it. Um and it's very clear that something happened around Opus 4.5 where I think there's a massive step function that that changed the industry and makes it makes this thing that we're talking about way more visible that we're just going to code not at all or way less than we used to do before. So, big vibe coding fan unless you unless you write fighter software nuclear nuclear power plant software. Yeah, it depends. Makes sense. So, I I'm curious about your So, you So, let's take for example of MCP apps now, right? Something new. And with this entire space being so opinionated like you mentioned online and that's why I wanted to ask the skills thing cuz it's I feel like it's you see it every day. MCP versus skills. Like there's so much big discussion around that. So, I'm curious how much of making new things with your team is based off like we think this is genuinely useful and very cool and we want to do this. And okay, this is what people want. This is what the feedback What's How do you balance that? That is so that's such a good question because I think that's one of the hardest things at the moment to do, right? If you just follow if you just follow what people want you have you you end up actually with a lot of stuff that's first of all not needed in 6 months from now. Um and second of all might just not actually compose very nicely together. So, you do need to be opinionated and it is very very hard and I think the if you get it right or not is nothing that will someone tell you in a year from now. It's something that will history will judge you over 10 years, right? I um If If you I think for example, Python is a good example of this. Like the the decisions in the Python language are decisions made over 30 years. The language has surprisingly be well kept together for for the amount of changes it has seen over 30 years. And that's just like in average Guido made more good decisions than he made bad decisions, right? Um and that I do not know if that is true. And so, um that is very very hard. Um A good chunk of it is trying and just um and just believing in certain things of where the puck is like where things are going. Like apps, I don't know if apps will work. Nobody knows if apps will work. Um but when we saw it and to be I just want to be honest, this is not invention by us. It is a very much the MCP UI people who built this originally. OpenAI took the idea rebuilt it in I think in a better version and a production ready version into what ChatGPT apps are. And then we thought this is a great idea, but we should really have a more common standard everybody agrees upon. Um And so, it's it's actually the third iteration, right? Of the same thing within 6 months. But it's clear that there was something to it because um I think we saw some I saw how cool it can be within ChatGPT. We saw the potential of how many people were interested with MCP UI. Um and then we wanted to bring it and see the use cases that we see. Now, we have one of the biggest benefits you have if is that within Anthropic or living inside um a frontier lab you're get to have a more forward-looking culture that is just inherently looking where things go in 2 years from now in a year from now, right? Um And you have more extreme looks that I think help you um perspective that will help you to not just try to look at value now, but look at what will be valuable in 2 years from now. Um And so, I think yes, in the end of the day it comes down to good judgment and good taste. And you just better hope you have it and if not, you know well We'll see. We'll see We'll see in 6 in 6 years so like like they will say who was this idiot who did the MCP? Yeah. And then that's it. With the with the vibe coding question that Marlene asked, I'm curious do you do you feel like your uh your your standard or your quality for code has changed just cuz you're talking about kind of having this like you know, a strong opinion and on your stuff. Do you feel like anything like that has changed? Um I I think it has changed, but I think it's actually interesting because I think people have I have the I'm a very practical-minded person. I think people have over-indexed originally on the idea of lean code or pretty code that were mostly designed for humans, right? Like humans try to build abstractions for the sake for the sake of the beauty of the abstraction so that they can then write three lines that do a lot of things, right? Like the model writes 100 lines and it's perfect. >> [laughter] >> Very practical. Um and yet at the same time um models got really really good and the code quality coming out of it is actually very very good. Like if I look at um uh the the the Rust bot that I wrote um this like my my personal Claude uh Claude bot um it's it's very good code quality and it could have been written by a by a human, right? I would have not written better code. So, I think there's also an aspect of these things getting better. Um So, I'm actually very little concerned about code quality in general. I also think that code quality is massively yeah, massively overrated in certain domains. Um And I I say this as someone who has worked at Facebook and has seen uh $2 trillion company being built on very crappy code. Oh. In the most places, not in the right places. In the most critical places most places. it's very very very very good, right? You look look at the cache layer, look at the database layer. Very solid. Very careful engineer. The front-end code whole different story. A little bit tricky. >> Because you're optimizing for iteration speed and I think that's fine. Yeah. I mean, that's that's great. That makes sense. I think I mean, I like I think in Python land we love an elegant piece of code. You know, that's the I think that's one of the things about Python that like people are always like, you know, the code is usually really nice-looking. Um and yeah, I struggled sometimes with vibe coding because I just don't like how the code looks. And it's a lot of stuff going on, you know? The worst part about vibe coding is that it just amplifies the dominance of JavaScript. That's the biggest problem. >> exactly. >> [laughter] >> Um I'm not the biggest fan. >> a good This is a good This is a good question to ask you is what team are you on? You are on you know, we are we're I I mean, it's a safe space. But what language do you prefer, David? Do you prefer Python? Do you prefer TypeScript? Let the people know what what language do you Um So, let's start let's start with the non-controversial takes. I hate JavaScript and I hate C++. It's the one The two languages I will make my way around and I will try to not write. Um Yeah. I um And I think I have reason for that. I think I'm I'm a I'm a team Python person. I've always written Python. >> Yeah. Um I my career is written Python. I love Python. It's the go-to language. Actually, my go-to language nowadays is Rust. I'm also on team Rust. Oh, wow. I love Rust. I think uh it's it's an exceptionally well-designed language. I love strong type systems. Um it is super super powerful. Rust and Python are really the go-tos. I think TypeScript is TypeScript is a very good type system. Um and actually way better than the the Python type system. So, Yeah. it's an interesting one. But TypeScript is a as a as a type as a type system is really really awesome. Yeah. Um but it is it is still under the hood JavaScript and that's its problem. But that's not the problem that the TypeScript people have. That's the The TypeScript people took something very horribly and made it actually surprisingly usable. Um but they started really off at probably like one of the worst languages in existence. That But yeah. My real heart wants the world to be Haskell. Like that's that's what I really really want. >> Oh, my god. >> But I think we are very far from that. No. Uh yeah, that's probably not going to happen. And love to the JavaScript people, we still like you. But it's I mean, we also love Python. But again, it's practical, right? Like I I I think PHP you know, was exceptionally successful and definitely not a well-designed language. And I think that's the same as JavaScript. But I think TypeScript is super super fun and super good, super useful. Um Python is just as much so. I love it. >> Yeah, exactly. Um I I another question I have for you, David, is what is your stack? Like you're doing a bunch of agentic coding right now. Um you've been developing developer tools for a while. What are you using to to code these days? So, this [clears throat] is the fun part about it. Like people think like, you know, someone at like Anthropic must have this elaborated thing that just goes has this like super crazy setup. I use Claude code in the terminal and that's it. And that's that's far as I get. I'm a I'm a very baseline boring person. I have five tabs open in Ghostery. Uh and I code away in Claude code and have that open um to review the changes um or make some minor things. And that's it. That's that's to the extent I use these things. Um I use maybe one or two plugins um for code reviewing um and and that's basically under the hood skills. Um I use maybe one or two MCP servers for integration with sentry and other things and that's it. That's that's Wow. the extent of it, right? Um Yeah, very very I'm a basic man. I >> You're very minimal. Very minimal, very simple. >> Minimal. Yeah. >> Very minimal, very simple. We appreciate that. I love it. Are you Can you talk a little bit more about like your workflow? Are you reviewing every change [clears throat] or what what What is What does that look like? Um So the my my current work is most of my actual day-to-day work is community work with the MCP community reviewing specification enhancement proposals. That's just a lot of reading. And then on next like what I usually do is I go and download a PR. I open it in Zed. I start grading through it. Um have GitHub open and then at the same time have Opus review it as well for me and make changes and look it for for consistency and other things to it. Um the the one benefit I do have um a we have we have access to um to a version of Opus that that basically gives me one GPU for myself so I can just it's just faster, way faster. It's just the same model. Nothing is better or just I don't have secret models or something, but I have faster models, which is good. Um and um And so I I I I I'll have I have run that. Um And then when I write code um for example, when I I write a lot of infrastructure code at the moment for for MCP, that I have let it write. I take a brief look at it. I mostly just test the implementations. Um but I actually don't look at all the code anymore. I wouldn't know. Um I just have like two or three Opuses running at it at the same time. After Usually after a while, I start One thing I do all the time is like after two or three iterations of code writing code. So the few things is like I stop. Um I do one task at like a bunch of to-do's first. So what I really do is like I go in when I want to write code, I go into plan mode. I let it plan. And then that's the task it will do. Um if you don't know how to get into plan mode, it's a really good thing. It's like shift tab tab. You go into plan mode. It creates a really good plan first. I let it run at the plan. Um and then I stop the session. I will restart the session because I want to clear the context window. I don't want to compact too much. Um and restart it. Um and then I go to the next thing and the next thing and the next thing. And then after two or three of these, I start a new thing and go like start three or four sub agent. One is a security review. One is a principal architect. One is a principal co- like a principal software engineer that is like um super picky about code review and just go about it and then implement the fixes for it. And that's how I usually run. Yeah. I I And then I review it eventually. I also have the luxury that I have other people who will review stuff for me. Um Very nice. Yes. Which is Which is Which is to say that >> [laughter] >> I make my problem someone else's problem sometimes. Yeah. Yeah, I I'm curious I remember Marlene we asked Armon this and he said that he believes that the current ideal UX for a genetic programming doesn't exist. So you know, we have either IDEs or we have CLIs, but neither of them are ideal. What are your thoughts on that? What do you think? Oh, I have 100% agree. It's so funny by the way like Armon and I think agree on a lot of topics. Although he doesn't agree with MCP. Um the the No, I I do believe that. I think the There's an interesting tension where um editors feel very dated nowadays because I think editors are like single uh they are they're built for a use case where there's a single human in front of it and it's the workspace for a single human. And for that I think that will always be required, but it's not to the extent that they're very like where you live in an editor. Um and so I think they're quite dated in an old paradigm nowadays. Um At the same time the I show you a diff in unified diff format with green and red on a terminal is also not a great uh user interface either. Um and but at the same time building you GUIs is very hard and a very difficult job. Um If you look at like what it takes to build an editor from scratch, be it VS Code, be it Zed, it's a lot a lot of work. It's very very hard. Years and years of engineering. Um and so it's very hard to build the next iteration of all this. Um but the paradigm is just not this These are not the ideal UI and the problem is by the time you have built an editor for the current um capabilities, the next capabilities have come around, right? Um it's clear that the models have basically steadily improved and I don't think there's any reason to believe they wouldn't improve another year or two or three or more, right? And so what does that What does it look like then? I do not know. Mhm. I'm excited to to find out eventually when someone tries something new. Yeah. >> sure it'll be something soon. Yeah, you'll see it on social media like this is the way you have to code now. [laughter] People will always tell us. Oh. >> Yeah. This I bet it's by the way I think that's why the two e stuff works so well. That's why these command line utilities work so well because they're fairly fast to iterate on. They're minimal enough that they're composable enough. You can just open five terminals and have five claws running and just that's it, right? Um and all they do, they talk over the file system with each other and so that they are you don't need complex architecture to do this and they're good enough, right? And they're familiar enough for software engineers, but they're not the best. They're not the final interface. They're just the the local the local optima at the moment. Interesting. Yeah, I mean I love that answer and I I think that the future is going to look really interesting, very different probably than where we are now. Though we're seeing kind of glimpses of that. And I know we're coming to time now and I wanted to know from you David, what do you think is the future of of MCP? I know recent like a couple months ago you donated or Anthropic donated MCP to the Linux Foundation. Huge deal. Um why did you make that decision? Where is that going? What does that mean for the future of MCP? Yeah, so this is an interesting one because I think it's it's um people don't know a lot of these about these inner workings and it's a bit hard to understand why you would do this and what it exactly means. So let me let me unpack this a little bit. We have been thinking about donating MCP to a neutral foundation since basically March, April last year. And the reason is pretty straightforward is um MCP is for the most part from a copyright perspective owned by Anthropic at the time. There There we made some very interesting choices that people have not noticed. So for example, we did not enforce a CLA. And the reason we did not enforce a CLA because project that enforces a CLA, you know, we're getting very legally, um are able to change the license on a whim. And what you have seen in the open source past is things like Redis, things like Terraform. Out of nowhere the business, particularly when it's company backed, suddenly changes the license. So we early on made a few decisions. The first decision was we don't enforce a CLI, which means the CLI, which basically means um contributors retain the copyright and it's basically impossible for us to change the license um to a commercial license unless everybody would agree, which of course one of the some of them would not, right? So it's already like a defense against that. The second part of that is finding a neutral space where this gets donated to because there's a second third problem that the average developer doesn't care about, but big companies very much care about is the the trademark MCP is still was still very much owned by Anthropic. So um if Microsoft goes and runs around and says, "Here's an MCP client." then they are basically at the goodwill or at legal deals with Anthropic directly to be able to use the name. Right. And you serve you solve all these issue by donating this to a neutral entity because you now it will stay always open. It will um the trademark is now owned by a neutral part and it basically tells everybody in the industry, "This actually just stays neutral. This will not go away. You can use it. Nobody will ever going to sue you over it. That's it." Um and so that's was one of the big parts because enterprises rightfully were careful about it because there has been history of bad things happening. Um and you might trust Anthropic, but you know, again, people have trusted Redis and others in the past and then things can still happen, right? And so that was the big deal here for us. And then of course, we do want to um get a like a governing board when and more projects are adjacent to it close together and work together and there's a lot of community benefits. But what it actually is not, it does not change anything about how MCP is actually handled or any of the commitment from Anthropic to MCP. So, we still have the same developers working on it. Nobody of like everybody from us works at Anthropic. Um we're still like for the most part like I'm still the BDFL of the project and so I'm in that in the end of the day nothing has really really changed here either, right? So, it's it's mostly actually legal thing but it's also like a big signal that we really want to build a community around it. Um and so we're and so I'm very very happy that like everyone came together and like we built such a actually really really cool foundation which I think can be the ground for bringing in a lot of the like Agentech open source projects together and like actually have like great synergies between each other. Yeah, I love that. So, it's not because Anthropic gave up on MCP. Oh, it's very much not. It's like Yeah, like this like it's like saying like Google gave up on Kubernetes and then that's why they like they very much didn't, right? Like it's like part like if they like why is Kubernetes in the in the built the cloud cloud native foundation? It's just like to find a new place because would you trust would you trust Google at the time like 10 years ago um that they will never like make Kubernetes close source or something like that? No, that's why you have a have it in a foundation, right? Yeah, absolutely. >> No, we definitely did not give up on it quite the opposite, right? We we're doubling down and we're uh we're we're still investing into it which you know MCP apps is I think it's a great example of this. I love that. Uh yeah, well I think this is amazing. I have said before that I just see so many parallels um from like the Python world in MCP and like the way it's being run very similar open values as well which I love. So, I think that's all the time we have for today. Thank you so much, David. >> Thank you. Really appreciate it. We are very excited about MCP and Thank you for having me. Next time with a demo. >> [laughter] >> Next time with a demo. In a few months we'll have you back for sure. Perfect. Awesome. All right. Thank you. Bye, everyone. Bye. >> [music]