Hello, everyone. Who's excited to chat about MCP today? Okay, we can work on that. We can get it a little bit better by the end of this talk. But I'm Theo. I am a product manager at Anthropic, work on MCP. Prior to this, was also a startup founder, working in the AI space.

Couple fun facts about me, because everyone says make yourself a little bit more personable, is I like playing poker, mostly losing money at poker, not making money at poker, and I also really like coffee. If you're a huge coffee fan and want to talk about the best coffee in San Francisco, hit me up after the talk.

But you didn't come here to talk about me. You came here to learn about MCP. So let's talk about MCP. I was told not to say MCP is the best thing since sliced bread, which I won't say, but mostly because I don't actually think it's the best thing since sliced bread.

My goal here today is to really walk you through the origin story of MCP, why we launched it, give you a better sense of where it can actually help you in your workflow, And then ultimately give you a sense of the types of questions that I'm frequently hearing, where I think there's a lot of value to build in the ecosystem.

And let you decide for yourself whether or not it is actually the best thing since sliced bread. So scrolling all the way back to mid last year, the co-creators of MCP, David and Justin, had this idea. They were seeing that, you know, classic two engineers in a garage style.

They were seeing that they were constantly copying and pasting context from outside of the context window into the context window. So you're doing your workflow and suddenly you're remembering that there was a Slack message that was really important that had a lot of context that you could just copy in.

So you're constantly kind of copying things back and forth from Slack. Maybe you're copying things in from Sentry, your error logs. But they were kind of realizing, hey, it would be so great if Claude or any LLM could just kind of climb out of its box, reach out into the real world, and bring that context and those actions to the model.

And so the genesis of MCP was really around this big question of not just context but model agency. How do you actually give the model the ability to interact with the outside world? And so as they started thinking about this, they came to the conclusion that it had to be an open source standardized protocol in order for this to make sense at scale.

And the reason is, of course, as you all know, if you want to build an integration and the actor or the client in this case that has to leverage that integration is using a closed source ecosystem, then you need maybe a BD or partnerships angle with that client to actually get access to the team, to integrate with them.

You then have to align on the right interface, and then you get to actually build the thing itself. And so the idea here was that model agency was the biggest thing that was stopping LLMs from actually reaching the next stage of usefulness and intelligence, as we saw that reasoning models were becoming more and more the future, that tool calling was getting better.

We really wanted to make sure that we were making it possible for everyone to get involved in that ecosystem and actually allow the models to, again, have agency. So they form a small tiger team internally, work on this protocol, and launch it at our company Hack Week in November of last year.

And this was really the first turning point of MCP. It went viral, as you can imagine. Engineers from various teams were working on building MCPs to automate their own workflows. They were working on MCPs to automate other teams' workflows. This was really kind of a cool moment to see how it went from, again, like two engineers in a garage, all the way to this is a major moment and turning point where we think we actually unlocked some true value for other people.

And so we ultimately ended up open sourcing MCP in November of last year, and that's when we introduced it to the rest of the world. But as most builders know, when you build something zero to one, you think the launch moment is going to be really impactful. But it actually usually is not.

At launch, most people were saying things like, what's MCP? Or even worse, or maybe, you know, rightfully so, what's MPC? And more often than not, we got this question of, I don't really understand why you need a new protocol. I don't really understand why it has to be open source.

Can't models call tools already? This was the slew of questions that kind of came again and again for probably from the era of November, all the way even to early this year. And it really took making it possible for builders to kind of get their hands dirty with building MCPs to automate their own workflow for this to take off.

And so the next turning point, as Henry alluded to, was when Cursor kind of adopted MCP. And after that, a lot of other coding tools also adopted MCP. VS Code, Source Graph, et cetera. We had a lot of coding IDEs start adopting MCP. And that's really where that next stage of momentum came in where agency was given to builders to actually build MCPs for themselves.

And more recently, we've seen kind of another turning point where Google, Microsoft, OpenAI, and many others have also adopted MCP. So we're really excited to see this kind of become more and more the standard. But ultimately, standards become standards because they are actually useful to builders. And so I kind of want to ask all of you to keep us honest.

Contribute when you see issues with the way that the protocol is built today. Or if you even want to take that one step further and submit a PR directly to the GitHub repo and fix the issue, that would be even better. But our goal here is really to make it maximally useful for you all and for model providers.

So thank you for your help in even getting us to the point where I can be speaking on stage about this less than one year later. So just to get a little bit deeper into what we were solving for at the start of building MCP is, again, this kind of idea of model agency.

And part of that means agents is kind of the direction that we think is going to be the future. That's no surprise to anyone in this room. You are probably going to hear the word agents said in every talk, if not almost every talk. But the way that we think about agents is that you are giving the model, or you're rather depending on the model's intelligence to choose actions and decide what to do.

In the same way that, you know, maybe when you talk to a human and you ask them for a response, you don't know exactly what the response is, but based on your understanding of maybe the task that you've given them, your hope is that they are going to give you the right response.

And we want to kind of enable that world where you're depending on the model's intelligence scaling over time. So that leads to principles in how we actually build the protocol itself. Recently, we launched the support for Streamable HTTP, which changes the transport from SSE. And as you all might know, Streamable HTTP enables more bidirectionality.

And so that was a very controversial decision, actually. But if you're keeping agents in mind as the future, it makes a lot of sense because you want to make sure that agents can kind of communicate with each other. The other thing that we believe is that there will be a lot more servers than there are clients.

We could be totally wrong on this. I would love to see where the future plays out. But because we think that there will be a lot more servers than there are clients, we optimized for server simplicity and for the server builders to have better tooling. And that does mean when we have to make a trade-off between client complexity or server complexity, we tend to optimize for pushing the complexity down to the client.

So I apologize in advance to client builders, but it was an intentional decision. Again, I would be curious to see if this plays out the way that we thought it would. So I'm going to speed run through some project updates, mostly because other talks are going to go much more in detail here.

But last six months, we launched ability for folks to build remote MCPs. We fixed auth, which we got wrong initially. Thank you. So I know that was a huge, huge thing that we got wrong initially, but it is now fixed in the draft spec. And so we'd love folks to continue helping to push on these things that they see don't match their mental model.

This was actually fixed via a series of people from the community jumping in to work on saying, hey, this is how auth works with identity providers, and here's how we can update the protocol. So very much a community effort. Again, launched renewable HTTP as the primary transport. And lastly, made a couple of updates to the developer experience by updating our SDKs and also making updates to inspector, which if you aren't familiar with, is a really good debugging tool for your server.

I think it is probably our most underutilized tool. Looking forward, we're going to be focusing a lot more on that agent experience. So we just added elicitation to the draft spec. This allows servers to ask for more information from end users. So you can imagine you're building a-- maybe you're building a flight booking tool, and the end user says, hey, book me the best flight to Atlanta.

And so as the server, you have a question, which is what does best mean to you? Is it cheapest or is it fastest? So you ask the end user, and now you can pass through that elicitation. The end user can respond and have that response ultimately sent back to the server.

We are also making progress on the registry API, which would make it a lot easier for models to actually find MCPs that weren't already given to them upfront. So this is, again, kind of on that theme of model agency. We're really betting on the intelligence of models going up over time.

Again, working on developer experience, we've heard often from you all that there are-- that, you know, you'd love to understand what kind of the best patterns are in the ecosystem or what the standards are. And so we want to make sure that there are open source examples that both we've contributed to and also the community can contribute to to kind of help build those standards and patterns together.

And lastly, we're making sure that MCP stays open forever, and we are investing heavily in thinking about the next phase of governance. So there will be more updates on that soon. And just to do a quick call-out to the graphic in the bottom, so a lot of people have asked us what it looks like to actually build an agent with MCP.

So our take is that an agent really is just a server acting as a client and vice versa, where you can then kind of chat back and forth with other agents, other servers, other clients. So I won't go into too much detail there. I know a lot of other people are going to be talking about agents in more detail, but I just wanted to make sure that I call that out here.

So the thing that everyone has probably been waiting for and that I've been told over and over again when I talk to founders, what they're asking me about is what should I build in this space? If MCP becomes a standard, where are the interesting opportunities? So before jumping into this, the first thing I'll say is that we are really early right now.

And that means that even if the standard exists, we still need the ecosystem to be filled out. And I would urge you to build more and more and more servers. If I had to put a weighting on these three bullet points, I would put 80% on the first one, 10% on the second one, and 10% on the third one.

So we have a lot of opportunity to build a lot more servers that are higher quality and for different verticals. And just to touch quickly on what I mean by higher quality, a lot of people, you know, maybe hot take, but I think a lot of people are wrapping their API endpoints one-to-one and just exposing that as tools.

So I don't think that's the right way to build an MCP server. That in and of itself could probably be a 20-minute talk. But what you really have to remember when you're building a server is that you have three users. You have the end user, the client developer, and the model.

So a lot of people forget that the model is a user here as well. You want to, just as you would for API design, you want to think about what are the use cases that your end users are going to have? What are the prompts that they might actually be putting into the model?

And ultimately, what are the tools that you then need to expose to the model to enable the model to respond correctly to those prompts? So higher quality servers and also servers for different verticals. A lot of the servers today have been for DevTools. We would love to see this expand to be useful beyond engineers into verticals like sales, finance, legal, education, pick your poison, whatever you know best.

We would just love to see more servers. The next piece is on simplifying server building. So again, as I mentioned, we believe strongly that servers are going to be the vast majority of the ecosystem. There will, of course, be a lot of clients as well, but we think the order of magnitude of servers is going to outweigh the order of magnitude of clients.

And so we would love to see a lot more tooling to actually make it easier and easier to build servers, both for enterprises that are deploying MCPs internally as interfaces between teams and for indie hackers and everything in between that are building MCPs for external users. So anything from hosting tooling, testing tooling, evals, deployment, et cetera.

And then I snuck a bullet in here that's maybe a little bit more of a moonshot and a bet on the future, but there's a bullet for automated MCP server generation. And again, if you kind of think back to our bet on model intelligence and model agency for the future, at some point models will be so good writing code and interacting with the external world that they will actually be able to write their own MCPs on the fly in real time.

And so this might be a little early for where we are today, but I do think that there will be an opportunity for automated MCP generation as models get smarter and smarter. And last but not least, I wanted to do a quick call out for any tooling around AI security, observability, auditing, et cetera.

I don't think this is actually specific to MCP. This is true for any AI application, but I think the more that you enable those applications to have access to the outside world, to start playing with real data, of course, the security and privacy, et cetera, implications also go up.

And so I think if you're going to build a startup in that space, now is the time. So with that, happy MCP-ing. Thank you. Thank you.