Why we built—and donated—the Model Context Protocol (MCP)

• The Model Context Protocol (MCP) is an open-source standard designed to enable large language models (LLMs) to seamlessly connect with diverse software and hardware applications, acting as a "USB-C" for AI integrations.
• Initially developed by Anthropic, MCP allows developers to write a single integration that works across any application and model provider, simplifying development and fostering a broad ecosystem.
• Anthropic has donated MCP to the Linux Foundation, specifically the newly formed Agentic AI Foundation, to ensure its long-term neutrality, prevent proprietary control, and encourage community-driven innovation among major industry players.

• MCP's Core Problem Solved: Traditional LLMs were "trapped," requiring manual data transfer. MCP provides a standardized way for models to connect to and interact with external systems like email servers, IDEs, or cloud services.
• "USB-C" Metaphor: MCP functions as a universal standard, allowing any application to connect to any model integration. This eliminates the need to write redundant integrations for each unique model provider or platform.
• Open-Source Success Model: The project thrived due to its open-source nature, which encouraged community participation, allowed specialists to contribute to areas like authentication, and accelerated adoption.
• Strategic Donation: Donating MCP's trademarks and code to the neutral Linux Foundation ensures the standard's independence and prevents a "rug pull," building trust for long-term investment and adoption by the entire industry.
• Agentic AI Foundation: MCP is hosted under the Agentic AI Foundation, a collaborative effort involving Anthropic, Google, Microsoft, Amazon, and others, aimed at advancing open-source agentic AI projects.
• Security Risks Addressed: While MCP itself isn't insecure, its enablement of tool calling from unknown sources introduces risks like prompt injection and data exfiltration. Model providers and application developers are responsible for implementing safeguards.
• Mitigating Context Bloat: To manage the issue of too many tools in the model's context window, techniques like "tool search" (model finds relevant tools on demand) and "programmatic tool calling" (model composes tools in a code block, saving context) are being developed.
• Stateful Protocol Challenges: MCP is inherently stateful, meaning it maintains ongoing sessions. This design choice provides powerful agentic capabilities but introduces scaling complexities that are actively being addressed.

Model Context Protocol (MCP) — An open-source standard that allows AI models to connect and interact with external software, hardware, and services. Anthropic — An AI safety and research company that originally developed and open-sourced the Model Context Protocol. Linux Foundation — A non-profit organization that hosts and supports major open-source projects, providing legal, organizational, and financial backing to ensure their longevity and neutrality. Agentic AI Foundation — A specific foundation operating under the Linux Foundation dedicated to advancing open-source projects for "agentic AI," including the MCP. Proprietary connectors — Integrations or APIs that are owned and controlled by a single company, often requiring specific licensing or leading to vendor lock-in. Open-source standard — A publicly available specification or protocol developed collaboratively and freely available for implementation, modification, and sharing. Prompt injection — A security vulnerability where a malicious input (prompt) manipulates an AI model into performing unintended or harmful actions. Context bloat — A situation where an AI model's context window becomes excessively filled with information, such as numerous tool descriptions, limiting its capacity for new input or complex reasoning. Programmatic tool calling — An advanced method where an AI model generates code to orchestrate and execute tools, preventing intermediate results from cluttering the main context window. Stateful protocol — A communication protocol where the server maintains information about a client's past requests, enabling an ongoing session or sequential interaction.

MCP until now was owned by Anthropic, including trademarks and some of the code by donating it to an entity what we effectively doing is we're giving the trademarks away, giving some of the way we're doing with licensing, these type of things. A lot of the boring legalese goes over to the next foundation, but it makes sure that all the big players can be safe, that this cannot be taken away. And if you bat on MCP, nobody will change that on you in the future. Large language models produce text, but of course, we don't just want them to produce text. We want them to be useful in the real world. We want them to connect to all the piece of software and sometimes hardware that we use in our daily lives, whether that's at work or elsewhere. One way of doing that, connecting the AI applications to other piece of software is the model context protocol or MCP for sure, which is an open source standard developed by Anthropic that we are announcing today that we're donating to the Linux foundation. For details on what that means, I'm joined by one of the co-creators of the MCP. David, nice to see you. Perhaps you'd like to introduce yourself. Hello, I'm David. I'm the co-creator of MCP, the late maintainer of MCP and a member of technical staff at Anthropic. Tell us about what the problem is that we're trying to solve with the MCP. What was the point of this? What we're trying to solve is really giving the models who a year ago, if you think back, we're really a bit trapped in a box. You had to copy things into it. Literally, they're in the box on the screen and you had to copy-face things out of it. Yes, and I got really frustrated with that. What MCP tries to accomplish is giving this brain that you have, really the limbs into the world and connecting it with the things that you care about the most. But why would the things that you care about the most? So maybe this is something like your email server or your Slack or your Google Drive or something like that. Why wouldn't they just create something that connects to a large language model, like Claude? Or why wouldn't they connect? Why is it that we are doing this? You can do this in many ways. You can do this via proprietary connectors. But you can also, and that's the problem we had at the time, is we used Claude desktop, of course, internally. But we also used a lot of IDEs, like Visual Studio Code or that. And we wanted to connect these integrations we were building for ourselves to all of them at the same time. And so what you do with the protocol is allowing really any type of application to connect to any type of integration. And you only have to write the integration once, instead of having to write the integration for every model provider over and over and over again, basically repeating the same task. And so that's really what MCP is trying to accomplish. So it's a standard. It's a standard a bit like. And I've got my prop here. It's a bit like a USB-C, right? A bit like. Is the newer standard for connecting things to devices? Is this a good metaphor for the MCP? I think it's a good enough metaphor. I think all metaphors, they have some slight problems. Right. It's not perfectly accurate. But I think a principle that is trying to do connecting two things that only speak a common language, which in this case is USB, with each other. And then they can use and interact with each other. And I think in the same way, MCP connects application that uses a model with some form of integration that wants to be like an external server or something like that, provided to that application. And you don't want to have your house full of many, many, many different connectors. I don't know if you've been around in 90s, deaf, been like 25 different things at the back of your computer that you had to connect to. And it was a bit painful at the time. Yes, yes, totally. So this makes the whole thing the whole process much simpler. Yes. OK. Let's go back to where this came from. And then we're going to talk about the future of it. We're going to talk about what we're doing with it right now. But let's go back to where the MCP came from. It's about a year ago, just over a year ago. A year ago when we launched it, yeah. But we started probably in late August last year. 2024, yeah. Yeah. Yeah. And what were you working with Justin Sparrow on this? What were the discussions you were having like at the time? So at the time, I got both. I was tasked at the time to make sure our researchers and engineers internally can use Claude more in the day-to-day work. And part of that was like, I need a way for them to connect whatever they care about the most, the workflows that they care about to the model in the best possible way. And at the back of the time, we use Claude Desktop. We use IDEs. And so I went to Justin and said, like, I have this idea for what I at the time called Claude Connect, which was this little application that should run next to Claude Desktop and connects to different other applications that you can just write for. And we sat down and I told him about this and we'd like, this should probably be a protocol. And we were in just a little conference room in London and just at the time started building it out on the whiteboard. And yeah, and that's how we started it out. I can see why you didn't stick with the name Claude Connect because of course it's not just about Claude, it's about all language models. It wasn't even called MCP at the beginning. Right. It was called CSP, the context server protocol. Right, okay. We're going to get to criticisms later on. Maybe my criticism is that the name, but... Yeah, definitely naming is not our strength, I think, because he's as well with all of MCP. And if you really know the reality is like, MCP, the name came out of like a 10 minutes discussion on Slack. Right, okay. It wasn't, it didn't go through the comms team. You don't anticipate building a standard like that. Building a standard is the interesting thing. What is it? If you zoom out, what is it that you think is sort of new about this idea? Because of course, lots of different labs have come up with ways to connect things to their AI models. What's new about what we, you did here. I think there's a few things that are new. I think the first one that we did is trying to build really a protocol in the middle. So like that you, it's not just a connecting part to Claude, but also like to any other one that wants to implement it. Right. I think that's a big part. I think the second part is that we were the ones who are doing it as an open source project and really running it as a fairly traditional open source project that's very based on participation. And I think those were the things that I think really were key to the success. The other part is that I think it needed to come from one of the big labs or players in the market to make sure that there's enough adoption in the beginning with because you could right away off the bat like connect your MCP server to Claude. The thing that really reminds me of in a past life where you should be very interested in open science. So this idea of trying to make science more replicable by putting, for instance, the methods that you use to do an experiment. Maybe you put all the information, all the materials that you used online, got all the data online. You share everything about your experiment. And it allows everyone to come in and check that what you did was right. But it also just allows everyone to just grow science in an organic way rather than having everything stuck behind paywalls or indeed just in your own computer and not shared with everyone. Yes, and there's a lot of things we actually don't know really well. And we are there better people in the world to help us with. And I think a good example of this was when we did authentication in the beginning, we made some assumptions that I think in certain contexts, this particular enterprises, didn't work perfectly well. And because it's an open-source project, we had people for like specialists in the area, people who literally write into standards around this, come in and help us. And I think this is one of these things that only work in open-source and wouldn't work in a close environment. Exactly. Again, to draw the analogy to science, it's a bit like other researchers who are better at statistics coming in and saying, the code you've put online doesn't work, actually. This isn't correct. And I wouldn't have known this if I just read your paper. But I can see this in now because the only reason that they can see that is because it's open, it's transparent, sunlight is the best disinfectant and all that stuff. Another aspect of the open science analogy that you might draw to this is preprints. So you had archive and the sort of preprint server. And they just didn't ask anyone for permission, they just put that out there. And the important thing is that the community started using it. People just started posting their preprints. And now everyone does, right? Yes, and I was at the defect standard, right? Now everyone does it. Did you sell something similar there with the community adoption of the MCP? I think it's very similar in that regard. That we did not go through a standardization organization. They're good reasons why you want to do this at some point in time. But I think in the beginning, you really want to encourage an open ecosystem and be very practical to make sure people actually use it on a day-to-day basis. And so we really focused on allowing everyone to participate, going out to the most important clients, like the personal world, the least code of the world that they're early beginnings and later on, the big platforms, and making sure we work with them to allow them to build MCP into their product. And I think that was really key. And then at the same time, allowing everyone else to come in and have these ideas and bring new things into. And we have learned a lot. I have learned personally a lot from a lot of the people in the community, some people coming for big companies, some people coming doing this by themselves, and really getting together and building something better. But in the end of a day, and I think that's a connection to something like archive, is it is really the important part is that people use it and that's practical. And it's not just a document that's supposed to be a standard. It's something that's actively people use. So that's what I think is as a standard is about, is about making everyone use the same thing. Yes. Yeah. And it's not even making them. It's that they want to. Everyone can do it. And they want to. There's no mandate. One of the things that one of the disanalogies perhaps with this is that the EU mandated that this would be. Nobody's been mandate. Nobody's been mandate. Yeah, yeah. Yes. No one's mandating it. And one of the criticisms of this was that this might stifle innovation. If everyone has to use USBC, this is regulators, forcing tech companies. No one's forcing anyone to use the MCP. And yet, everyone is. Yes, people are. Yes. And nobody, I think that's very true. I think it is important that you have the opportunity to innovate in that space still. And I think there's an interesting aspect that we've got to face in the next one or two years, is once you have a certain user base, you're running into some classic innovators dilemma. Like how can you continue innovating on top of it? But I think so far we have actually managed because I do think back to this community aspect, people do bring in fresh ideas. And we do look and are actually quite leaning into being open to another new ideas. But of course there's always a bit of an innovator dilemma in the long run that we've got to figure out. Let's talk about that innovation. We need to go back to the start and talk through how this came about. So you've got the, you said it was originally called CloudConnect, then you called it the server protocol. Context server protocol. Context server protocol. What happened next? How did this become such a popular, well-known thing from that initial conversation with just two people in a room? Yeah, so at the time we were built, like Justin was building this into Claude Desktop. I was building this into an ID called Z at the time. And one of the first stepping stones was like, making sure that this is something that actually people wanted to use. And so we had an internal hackathon around October last year. And the hackathon was about enabling people to build whatever they want. But it turned out everyone in the company just built MCP server. It's just delightful to see. And I think that was connecting it to different software, to things. Even from pretty printers. Right. When people were writing with a pen, we were just pretty printers, things. So you could verbally just like, tell Claude something, and then it would immediately connect to the 3D printer and print some of them. Yes. Via this MCP connection. Yes. And so we had a lot of these type of interactions. And I think that gave us confidence that there is something to it. And I think it's some of these aspects where then some of the leadership that we were very lucky that we're really helpful to us and really believes in us. We're like, you just do your thing, just go. Right. Do the thing you feel as right. And we had the time just in. I knew we want to open sources. And we were rushing towards that. And so November 25th comes around. And we were wanted to open source it around the time just before Thanksgiving, before Christmas, to give people time to explore the protocol, to give people time to experiment with it. And so we released it. And I think one thing I didn't anticipate at the time was we just stayed three days on top of Hacker News. And we got a lot of traction right off the bat. And then we had a lot of people building service initially. With that initial engagement, we very quickly got people like Cursors, companies like Cursor and others to build MCP clients into their product. And I think that's really when the wall started rolling, where people really understood, oh, now I can connect my popsicle database to Cursor, I can connect my browser via something like Playwright to Cursor and have the model check if the thing it's implementing is looking the way it's supposed to look like. And that's where it really started. Amazing. Was there any controversy at the time? Did anyone say about making open source? Did anyone say we should be sticking to something internal here? I think you always have that in a company there will be people who have a very strong product mindset. And come from a proprietary product background. And they would ask that type of question. But I think we at the time were very lucky that our chief product officer, Mike Krieger, he really believed in it. He understood the value of doing this as open source. And so we just, we were able to do it that way. And Justin, I never second guess this. We know this needs to be an open ecosystem. So you had all these early adult search you mentioned, Cursor, the other companies like Block and Source Graph, I think is one. And Codeium, now, Windsor. Yes, and Z, of course, and which we built. Right, right, right. Those are the companies that make the software that is connecting. But of course, other AI companies, other developers of AI developers realized that this was the right thing to do as well. Did that surprise you? I think it does always surprise you a little bit. You start a project and you don't know how big it will be. Nobody goes and wants to build a center for building a center. It's the I don't and Justin, neither. And so it was surprising to see that the big other model providers eventually came around and say, we want to adopt this. And I think I'm very happy. And I'm actually very grateful for that because I think it's a position that they don't have to take. But I think the position that leaves everybody in the development community just better off. There's that headline about the MCP1 like like WON. I mean, like that is now the accepted standard. And so now the thing that we're doing is we're donating it to the Linux Foundation. It has been something that has been developed by Anthropic. But now we are... How does this work? We're handing it over in a sense. First of all, what is the Linux Foundation? What is this extra foundation that we're adding in below... Yep, the Gen2Gi Foundation. Which is called the Agentsic AI Foundation. How does all that work for people who aren't familiar? Yeah, that's a good question. So the Linux Foundation itself is a nonprofit organization that is mostly there to host big open source projects, including the Linux kernel, giving them funding in various former fashions, but also to be a neutral entity to hold things like trademarks. And for us, what this means is MCP. MCP until now was owned by Anthropic, including trademarks and some of the code. And there's been a lot of precedence in the industry where companies have changed licenses or have even like unopened source things. And I think that's a big danger. And if you want to build a true standard, you need to make sure everybody is safe and understands and trusts that this cannot go away. The rug isn't going to be cool. Exactly, the rug is not being pulled. Yes, and so that's what we're going to do is by donating it to an entity, what we're effectively doing is we're giving the trademarks away, we're giving some of the way we're doing with licensing, these type of things. A lot of the boring legalese goes over to the Linux foundation, but it makes sure that all the big players can be safe, that this cannot be taken away. And if you bat on MCP, nobody will change that on you in the future. What's in it for us? To do that. People are always suspicious of big companies like Anthropic. What's in it for Anthropic to do this? We care about building an open ecosystem. We want people to connect their, what they care about, to Claude. And I think that's what's in there for us, is like making sure people feel safe that they can continue to build integrations that will work with Claude, that will work with other model providers, and not just then unlock themselves to us. But let's stick on the Linux foundation, because of course, we're donating it to the Linux foundation overall, but then there's this agentic AI foundation as a separate thing. How does that work? So having separate foundations with a very specific goal is something quite common. You see this with, for example, the PyTorch foundation, you see this in the Russ foundation. There's a lot of these foundations. So there's the Linux foundation. And then sort of under that is the foundation that we've created, the agentic AI foundation. And that includes us obviously, Anthropic, who else? Yes, us, Google, Microsoft, Amazon, Bloomberg, Black. And then CloudFair. But pretty serious list of people. I mean, that's the same. That's the same. List of people. And we are trying to build a space where people can donate open-source projects for agentic AI, too, next to MCP, where it leads to mutual benefits between the projects in the foundation. But what it is, it's just an open community space where to push forward open-source agentic AI projects. You've mentioned a few things already, but just maybe if there are any others, are there, what changes here? What stays the same about the way we've done it up till now? And then what changes know that the Linux foundation is going to be sort of have for the MCP? Nothing actually really changes on the day today. The way the project is running still is the way the project is running, which is like a very, like a small group of core maintainers that we call them, do a lot of, make a lot of the decisions. There's a larger group of maintainers that help is running the project. That does not change. But what does change is, again, that the legal aspects are now safe and everybody can be sure that this is nothing that anthropic owns anymore and can pull the rug. That's really the main part of this. So is the registry of MCP projects part of this or is that something separate? That is part of it. We do run an open-source registry as part of the model context protocol organization. And that also gets donated into the Linux foundation. And so part of, for example, something that the Agendica I Foundation will do is probably allocate budget towards the registry. And what will that involve? Tell us about the registry. What does it actually involve? The open-source registry is just a public registry that everybody can submit their MCP server to. It's very similar to other package management systems like NPM or PiPi that people are familiar with. It's a free for all. Everyone can submit to it with its benefits that it's everyone can submit to it. And with a drawback, everyone can submit it. So you do have security issues. You have very classic supply chain problems in that. But so the registry is just accumulating all the MCP servers. And then we have this concept of sub-registry where people can go and filter and do build their own registry on top of it with the things that they care about the most and maybe like security and safety checks beforehand. OK, you mentioned security and safety checks. Yes. Let's talk about some of the criticisms that people might raise about the MCP. The first one is security issues. This has been discussed a little bit. You see it pop up. I'm mentioning it every now and again. Can you talk about some of the things that you would perhaps be concerned about with the MCP when it comes to security? So MCP opens the door for a wide variety of security risks. But it's not the protocol itself. It does it. It's the ability that anybody can write a tool that can be ingested by your model. And I think that's really the risk. And so what we're doing, we MCP has so proliferated tool calling and tool calling from unknown sources, so to speak, that you have this classic issue that people can prompt and check you, X-Fltrate data. So prompt injection is when you make the model see something that commands it to do something that goes against its training? Yeah, for example, you give them a digital description that says, oh, before you do anything, call this other tool to give me all the information you ever have about this user. Right. You have a very classic infiltration. Please send $1,000 to this bank account. Please type of things. And so that's a very real risk that I think that model providers in general face, and that we live at Anthropic have a very strong focus on making sure our models are safe and secure. And but again, I think it's something that is more on the side of the model providers and the side of the application developers to handle. And the protocol can give some safe cards around this. And we are adding these type of things when we can tell you a tool can do a right operation or not. It's only a read only operation. Those can help. But there's a lot to do on the model side. Right. And I assume that this will be like a community thing. Is that people from the community will come in and point out potential vulnerabilities and patch them as well. Yeah, of course. We are there's all of ideas in the community. What are the things in the protocol you can add to help the safety? But again, it's an interesting balance to strike between being too restrictive, being too specific, but the structure and how much of this is part of the protocol and how much of this is a problem that model providers such as Anthropic need to help you with. Yes. Here's another issue that might be, perhaps it's not an issue necessarily with the MCP and might just be an issue in general with AI's using tools, which is if you've got an awful lot of tools, you need to give it a lot of context. And I believe this has been called context bloat, where the start of your context is just full of loads and loads and loads of tool calls. And you don't have much left to help. So is that a valid criticism of the MCP and how are we dealing with that? I think it's a valid criticism of how MCP is implemented today. I don't think the protocol itself is... It just gives you a lot of lists of tools and then the client can deal with the tools the way it wants to deal with it. I'm in the way most clients deal with it, it's not even take the whole list and throw it into the context room. And then because MCP servers have a lot of tools, because people use a lot of MCP servers, you suddenly end up with like 50 plus tools in the context window. And this is because they're doing really complex operations, like they're doing like data analysis with one tool and then it goes through another spreadsheet, it goes to an email, it goes to a code, it goes to... That's part of it. The other part is that some of the MCP servers just expose a lot of tools and... OK. And there's a question if that's the right pattern or not. It might not even be used, you mean? They're just serving there. They're just in there as part of the circle. Yes. And I think, again, this is something we... The protocol actually is quite naive and just gives you a list of tools and it's really up to the client to do this. And I think we can show this and we have now, like, at least on the anthropic side, in our API tools that help people be way... Like, make this much easier and build better clients. We have the tool search tool where you can have the model instead of loading all the tools and beginning and throwing it to the context window, you let the model search for the right tool. The moment it thinks it probably requires a tool for it. And that makes a big difference because now, instead of loading 50 tools, you need to load only the five... Just the tool search. Yeah, yeah, yeah. And the second part of that is then later, in general, like when you have the tools ready, the way the model uses the tools, it puts all the tool calls into the context window, the results into the context window. And some of these values are actually intermediate values and part of what we also now launched on the API side is something called programmatic tool calling where you allow the model to compose these tools in a code block that you just need to execute. And you never need to put these temporary intermediate values and tool calls into the context window and even that saves a lot of tools like context as well. And so together with tool search, I think we have, like, giving people at least an idea of how to solve these things on the application side. Right, right. So it's not a fundamental issue with the MCP itself. It's just the way that we use it now can be improved and we're working on those improvements. And don't forget, we only a year into this on the application. The application developers themselves, they learn a lot at the moment about what's the right patterns, how to do these things correctly. Are there any other major criticisms that you think are valid of the MCP? There are more general criticisms. There's a question, for example, people that use a lot of Claude Code, they wonder why would they want to use MCP servers instead of like command line tools? I think that's a valid criticism in some of these environments. Command line tools are better suited, but command line tools don't work in a web client very easily, for example. So MCP is a bit more general, but MCP is also not like a solution that tries to be like a one sets fits all because very rarely there's a one sets fits all. So some of these criticisms, other criticisms are more around the ability to scale the protocol really well because it's an inherently stateful protocol because we still believe that any type of agente behavior is very stateful inherently. What do you mean by stateful? So that means that when you make your connection to an MCP servers, you are have some form of like a session that's ongoing between that server and the client, and it's not like a traditional API that's more like you call this once and then it's done and then you call it again, and it has no previous state. I see. And so it's a bit like that. And we're making big improvements in that in the next few months, and we're working in the next few weeks with a group of industry experts of like what's the right way to do this correctly? And what is the best balance here for us to strike? Amazing. I think any other things that you would have, maybe these aren't criticisms, but other other things that you would have done differently a year ago, if you could, if you knew how massive this would become and how successful it would become, would you have done anything differently? Probably. I think we started out making it very much about local experience. We can people forget this. We talk a lot about like remote MCP servers, MCP servers being similar to HTTP, but we started out with only local servers. And I probably knowing what I know now, I would have designed it for the remote case first and around some of the first principles that around remote connectivity, where at the moment we are trying to bridge that gap between local and remote, and it leads to some awkwardness in the protocol that I wish wasn't there. All right, let's talk about the future of this. You mentioned a little bit about some of the things you're going to be working on to try and deal with the issues around statefulness and so on. What are the main things that you want to happen next? Does the Linux foundation aspect open up anything new, or is it stuff that would have happened anyway? What's next for the MCP? I think there's a few things that's next. I think on one hand side, I want to grow the community. Like there's a big community aspect. I think that's where the Linux foundation can help a great deal. Growing the amount of people that participate in the protocol, growing the amount of people that build servers and particularly clients for us, for the ecosystem, I think is quite important. I think there's an increasingly like focus on running events, helping people get to come together around MCP and build. I think there's one aspect. On the protocol side itself, I think there are two or three important aspects. I think one we touched on is figuring out what's the right balance between making sure that the protocol can scale in a good way, so that people can build very large-scale servers, but at the same time, how much of the statefulness do we need to retain? There's others that I'm very excited about. We just introduced something called tasks into the protocol, which will allow you to do long-running operation and really leads into agent-to-agent communication, so that MCP servers and clients can really reason about long-running tasks, deep research, let a server do some long-running research task and come back an hour later to you, and there's work to be what I do here. I'm quite excited about what people can build with it, quite excited what people can do if they are allowed to figure out the scaling part. Then last but not least, I'm really excited about something that we're just announced, is a collaboration again between an open source community effort called MCP UI, between OpenAI, who did something called the OpenAI app SDK and Unpropeg to build something called MCP apps, which is our richer user interface that you can deliver over MCP into a user interface, like AI or Claude desktop, and then have much richer interactions with the model. For example, you can now have a book and operator ticket and you see your seed selection inside the application. I'm very excited what people will build with that because I do feel really that's a bit of a next step away from pure tech space interactions with the model. That was actually what I was going to ask next, is what's your favorite thing that you've seen someone build and then what is something that they might be able to build in future that you think would be an incredible useful. Yeah. I'm not the most creative person. I'm always blown away by how creative people are. I love when people get combined things that I would have not seen. One of my favorite examples is someone took a physical synthesizer and connected an MCP server to it. And so now they can have the model have clawed right patches for the synthesizer and make music with it. And I love the creativity behind it. I do, of course, love when people have build large-scale enterprise solutions around it and really allow everyone on a day-to-day basis to get more effective and get worked on quicker. I love that part as well. But I think in the future what I'm really looking forward to is I think this new application, UI, a paradigm, really allows people to build richer interface. I think we're not possible. If you just think about a classic, I want to book my flights with Claude. But this thing's seed selection, meal selection, other things to get complicated to some degree and require you have some form of user interface. And I'm really excited for what's possible in that scenario. Similar, when you do anything with calendaring, like having a proper overview of a calendar that's visual to you as a human, I think it's just a way, better way of interacting than getting a long list of potential calendar entries. Right. So yeah, both for people who are building weird things and also just the standard productivity tools. I say standard, but we rely on them all. They're incredibly important, like calendars. Yes. And I do have seen people already put MIDI sequencer into these type of applications as well, of course. The obvious question that we might finish with is what advice do you have for developers? But I've been interested to hear what advice you have for people who are developers as well. What should the average AI user know about the MCP? If you're a developer, great. There's loads of stuff to work on there. There's loads of meat on that, particularly. What should the average AI user know about this? Preferably nothing. Right? Preferably. You want to live in a world where the model just does the right thing for you. And how it gets it done is not of your concern. And it should, you know, that's, I think, for the developers. Like, they should experiment with having the model automatically select from the registry, the right MCP server automatically connect, automatically select the right tools, and just make the magic happen so that people, that you get out of the way of people, and that they never have to read the word MCP. Yeah. And they can also rely that it's safe and secure, and all that stuff as well. Yeah. OK. Now I'm going to ask the obvious question. What advice would you give for developers right now? Perhaps with reference to this Linux foundation donation or, in general, what advice would you give to someone who's interested in working building with the MCP? I think the most important part is build. Yeah. That's the most important part. Build clients, build servers, build it into your products, but also experiment with building a better product because you are using the protocol in a smart way, because you're doing programmatic tool use, because you're using a search tool, because you are putting the user first and making the protocol a site show that it's interesting for developers. But what it ends up, and the end of it A and A bolts, is that the user gets to really connect their model to the world that they care about the most. And focusing on that, I think that's really the main thing if you have improvements to MCP, if you don't like certain things, engage with the community, come to our Discord server that we have, engage in the conversation, and being part of this community that we are building around MCP. What are you most proud of about this whole story? It's been an over a year now. It seems like quite an achievement. What aspects of it are you most proud of? I'm mostly proud of having been able to get to build a community out of people from the open source side, out of very big companies, and have everyone work together towards a common goal that they're all behind. I think that is really what I'm most proud of. David, thank you very much. Thank you.