MCP Co-Creator on the Next Wave of LLM Innovation

**Yoko Li** (0:00)
I have to ask a question here. How do you define an agent?

**David Soria Parra** (0:04)
Oh, I'm not going to get into that. What do you think is an agent?

**Yoko Li** (0:09)
I think it's a multi-step. Oh, I'm reasoning Chang. It's very simple for me.

**David Soria Parra** (0:14)
Okay, I can't get behind that. For me, agents is potentially more like, in this word, like agencies, so something that does some form of autonomous orchestration or autonomous task solving. And that's usually anything that's a multi-step thing is for me already like an agent, right? At the moment, it does two steps and it reacts to the first step. It's basically an agent because it now has some agency over what it's doing.

**SPEAKER_3** (0:38)
Welcome back to the a16z AI podcast. It's been a while, but here we are again with another great discussion about the fast moving AI space. This time, it's MCP or Model Context Protocol, which has been a major topic of conversation this year as it means to open up new LLM use cases and energetic behaviors by connecting models to any number of new tools, datasets and external applications. Here to talk about it are a16z Infer partner Yoko Li and Anthropics David Soria Parra, who created MCP along with his colleague Justin Spahr-Summers. Among other topics, Yoko and David discuss the MCP origin story, early and popular use cases, important work still to be done, for example, around authentication, and what is the right level of abstraction for carrying out certain types of workflows. It's an insightful and timely conversation that you'll hear after these disclosures. As a reminder, please note that the content here is for informational purposes only, should not be taken as legal, business, tax or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any a16z fund. For more details, please see a16z.com/disclosures.

**David Soria Parra** (1:51)
So MCP is, first and foremost, it's an open protocol and does not say much yet, but what it really tries to do, it tries to enable building AI applications in such a way that they can be extended by everyone else that is not part of the original development team through these MCP servers and really bring the workflows you care about, the things you want to do to these AI applications. And for that, it's like a protocol that just defines whatever you are building as a developer for that integration piece and that AI applications, how they talk to each other. And that's really what it is. It's a very boring specification. But then what it enables is hopefully, at least in my best case scenario, it's something that looks like the current API ecosystem, but for LLM interactions with some form of context providers or agents in any form or shape.

**Yoko Li** (2:46)
Yeah, I really love the analogy with the API ecosystem, just because it gives people a mental model of how the ecosystem evolves. It feels like API when it first came out is an abstraction on top of a set of things you can do on a different set of servers and services. Before, you may need a different spec to query Salesforce versus query HubSpot. Now you can use a similarly defined API schema to do that.
Not exactly the same because everyone defines query parameters differently. And then when I saw MCP earlier in the year when I was building something with it, it's very interesting that it almost felt like a standard interface for the agent to interface with LLMs. It's like, what are the set of things that the agent wants to execute on that it has never seen before? What kind of context does it need to make these things happen? When I tried it out, it was just super powerful. And I no longer have to build one tool per client. I now can build just one MCP server, for example, for sending emails. And I use it for everything on Cursor, on Claude Desktop, on Goose. So curious about, I guess, what's the behind the scenes story? What inspired you when you first realized, oh, we need a protocol for this? And how did you create it?

**David Soria Parra** (4:04)
Yeah, thank you. I think that's an interesting question. And with all of these type of ideas, I think they never happen in a vacuum. So I joined Anthropic about a year ago, pretty much actually a year ago. And I was working mostly on how we can use Claude more internally to accelerate ourselves. And as part of that, one of these original ideas I was thinking through is, I cannot be the person who builds for everyone, their specific workflow, their specific things, but I need to enable them to build for themselves because they know best what they need and how their workflow and their like agentic bits that they want to build fit into, you know, their system on the ecosystem that they're working in. And so that was one aspect of that. The second aspect of that was that at the time I was using both Claude Desktop, which was amazing with its artifacts that really allow you to greatly visualize things, but it had this like limitation that basically you had to, there was no interaction with anything outside of the text box. You couldn't add, you know, Google files yet or anything like that. And at the same time, I was using a code editor, which was amazing because it had access to all my code and had access to all these cool things, but it couldn't visualize anything very nicely as Claude Desktop. And I was very frustrated by just copying things from Claude Desktop back into the editor and back and forth. So I'm like, there needs to be a better way across these two applications. And then if you take these two things together, I need some way of enabling people to build something, so some form of API. But at the same time, I also want to work this across multiple applications, like a code editor. For me, there was the Z code editor, which I really like, and Cloud Desktop, which is obviously my favorite desktop application. You look at, how do I solve classic M times N problem, of I have M clients and I need N providers, and the answer is a protocol for that. And there's always been protocols for these type of thing, and there are many patterns in the past that match that. And that's how I came to go, hey, I would really love to have some form of protocol that enables me to tell Claude Desktop, to tell Zet, to tell Cursor, the workflow I care about and the things that I miss from it, because I'm a developer and I want to build for this, and I know how to build for this, just let me do it. That was really the origin in that regard. And that was just the idea, and I took this idea to a person called Justin Spahr-Summers, who is the co-creator of MCP with me, and he took a real liking to that idea and thought it was a good idea, and was really one of the key people to prototype the initial version, really make it work within part of the product or the side of Anthropic, and played a really big role in making this a rather big thing in Anthropic initially. Yeah, and so we both basically co-created this together until we released it into the open in November 2024