MCP 201 | Code w/ Claude

Well, hello. My name is David. I'm a member of technical staff at Anthropic and one of the co-creators of MCP. And today I'm going to tell you a little bit more about the protocol and the things you can do just to give you an understanding of what there's more to the protocol than what most people use it for at the moment, which would be tools. So really the goal today is to showcase you what the protocol is capable of and how you can use it in ways to build richer interactions with MCP clients that goes beyond the tool calling that most people are used to. And I will first go through all the different, like what we call primitives, like ways for the servers to expose information to a client before we go into some of the bit more lesser known aspects of the protocol. And then I want to talk a little bit about how to build a really rich interaction before we take a little stab of what's coming next for MCP and how we bring MCP to the web. But to just get you started, I want to talk about one of the MCP primitives that servers can expose to MCP clients that very few people know. And those are called prompts. And what prompts are really are predefined templates. for AI interactions, and that's to say it's a way for an MCP server to expose a set of texts, you know, like a prompt in a way that allows users to directly add this to the context window and see how they would use, for example, the MCP server you're building. And they're really the two main use cases here is for you as an MCP server author to provide an example that you can showcase to the user so that they know how to use the MCP server in the best way. Because realistically, you are the one who has built it, you are the one who knows how to use it in the best possible way, and probably at the time you would release it, are the one who has used it the most time. But since MCP... uh prompts are also dynamic in a way they're just code under the hood that are executed in mcp server they allow you to do even richer things than that what you can do and i want to showcase this in this scenario is an mcp prompt that a user invokes um in this z editor here that will fetch directly github comments that um into my context window. And so what you see me here doing is just basically put into the context window the comments from my pull request that I've written so that I can go and interact with it and have then the model go and help me apply the changes that's been requested to me or whatever I want to do. And so this is really a way for exposing things that the user should directly interact and the user should directly want to put into the context window before it interacts with the yellow lamp. So it's different from that, from tools where the model decides when to do it. This is what the user decides. I want to add this to the context window. And if you look carefully, there's one additional thing that very, very few people know that you can do, and that is prompt completion. So if you have looked carefully, there was a way where it showcased quickly a pop-up of me selecting the pull requests that are available to myself. And that is a thing that you can provide as an MCP server author to build richer parameterized templates, for example. And this is exceptionally easy to do in the code. Like if you were in TypeScript, building a prompt that provides users with like such a template and have parameters for it and like autocompletion is nothing more than a few lines of code that cloud code together with Cloud4, can most of the time write basically for you. And it's just that simple. It's a function for the completion, and it's a function for generating the prompt. And so this is already like one of these primitives you can use to build an interaction for users with an MCP server, but it's just a little bit more richer than a tool call. And a second one of these is something that we call resources. It's another primitive that an MCP server can expose to an MCP client. And while prompts are really focused on text snippets that a user can add into the context window, resources are about exposing raw data or content from a server. And why would you want to do this? There are two ways why you want to do this. One thing is most of the clients today would allow you to add this raw content directly to the context window. So in that way, they're not that different from prompts. It also allows application to do additional things to that raw data. And that could be, for example, building embeddings around this data that server exposes and then do retrieval augmented generation by adding to the context window the most appropriate things. And so this is an area that at the moment I feel is a bit underexplored. And I just want to quickly showcase you how resources work. In this case, this is again one of these ways where an MCP client exposes a resource as a file-like object. And in this scenario here, we are exposing the database schema for a Postgres database as resources and then you can add them in Claude Desktop just like files and that way you can tell Claude this is the tables I care about and now please go ahead and visualize them and so in this scenario what you're gonna see is Claude is gonna go and write a beautiful diagram that visualizes the database schema for me and I've exposed the schema via resources There's a lot of unexplored space still here again if you go beyond just like adding a file again and think about like retrieval augmentation or any other thing the application might want to do. And so those are two primitives. One is prompts again, the things that a user interacts with. The second one is resources that the application interacts with. Then of course there should be a third one that you all are very familiar with. that I don't want to get into too much depth because if you have built an MCP server, you probably have built it for exposing a tool. And so tools are really these actions, of course, that can be invoked. That's like one of the, I think, most... magical moment I feel when you build an MCP server is when the model for the first time invokes something that you care about, that you have built for, and has this little impact on, you know, it might be like carrying a database for you or whatever it might be. But this is, again, the thing that the model decides when to call to an action. And so these are three very basic primitives that the protocol exposes. if you think carefully about these three primitives that I just showcased to you, there's a little bit of overlap about like how do you use, like when do you use what really. And so there's something that we don't talk enough about and it's somewhere buried in the specification language of the model context protocol, is what I call the interaction model. And I think showcasing it hopefully makes clear when you use what. Because the interaction model is built in such a way that you can expose the same data in three different ways, depending on when you want to have it show up. And prompts, again, are these user-driven things. It's the thing the user invokes, adds to the context window. And the most common scenario where how you see these pop up is a slash command, an add command, something like that. Resources, on the other hand, are all application-driven. The application that uses the LLM, be it cloud desktop, be it VS Code, something like that, fully decides what it wants to do with that. And then lastly, tools are driven by the model. And between an AI application using a model and a user, we have all three parts that we eventually cover using these three basic primitives. And that allows you already to go to a little bit of a richer application and experience than what most people can currently do with tools. Because you just have a way to interact with the user a bit more nuanced than if you just wait for this model to call the tool. But we can even go beyond that. Because while these basic primitives get us a little bit further than what we see most MCP servers do at the moment, there are even richer interactions that we want to enable. And to make this a bit more understandable, here's really an example I want to give you that showcases this problem. So how can you build an MCP server, for example, that summarizes a discussion from an issue tracker? So on one side, I can build an MCP server that exposes this kind of data, very simple, and that's quite clear. But how do I do the summarization step? because for the summarization step I obviously need a model and so there in one way to go and build this is you can build an MCP server that is this issue tracker server and you have a choice here you can bring your own SDK and call the model have the model summarizes but then there's a little problem to that and the problem is that the client has a model selected be it like Claude or whatever else but the server The MCP server that you've built doesn't know what model the client has configured. And so you bring your own SDK of a model provider, and be it the anthropic SDK, you still need then an API key that this user needs to provide. And it gets very quickly very awkward. And so MCP has a little hidden feature, or a little primitive, called sampling that allows a server to request a completion from the client. What does this mean? It means that the server can use a model independently from like don't having to provide an SDK itself, but asks the client which model you have configured and the client is the one providing the completion to the server. And what does this do? It does two things. First of all, it allows the client to get full control over the security, privacy, and the cost. So instead of having to provide an additional API key, you might tap into the subscription that your client might already have. But it allows also a second part, which is that if you chain MCP servers in an interesting way, It makes this whole pattern very recursive. And what do I mean by that? It's a bit abstract. You can take an MCP server that exposes a tool, but during the tool execution, you might want to use more MCP servers downstream. And somewhere downstream in this system, there might be then your Azure Tracker server that wants to go and have a completion. But using sampling, you can bubble up the requests such that the client always stays in full control over the cost of the subscription, whatever you want to use. It stays in full control of the privacy over the cost of this interaction and basically manages every interaction that an MCP server wants to do with a model. And that allows for very powerful chaining and it allows for more complex patterns. that go already into ways of how you can build little MCP agents. But that's sampling. Sampling at the moment is sadly, I think, one of the more exciting features, but also one of the features that's the least supported in clients. For our first party products, we will bring sampling somewhere this year. And so then you can hopefully start building more exciting MCP servers. And then there's the last primitive that I want to touch on that's also a bit more interesting. And it's one of these things that, in retrospective, as one of the person who has built the protocol, I probably named terribly, to be fair. I'm not very good at naming, and you will see this throughout the talk probably. But there's a thing called roots. And roots is also an interesting aspect. Because let's imagine I want to build today an MCP server that deals with my Git commands. I don't want to deal with Git. I don't want to do source control commands. I don't remember any of that. I want to have an MCP server deal with this. So now I'm going to hook up an MCP server into my favorite IDE. But how does the IDE know, how does the MCP server know what are the open projects in the IDE? Because obviously I want to run the Git commands in the workspaces I have opened, right? And so roots is a way for the server to inquire from the client, such as VS Code, for example, what are the projects you have opened so that I can operate within only those directories that the server has opened. And I know where I want to execute my Git commands. And this again is a feature that's not that widely used, but for example, VS Code currently does support this. And so these are just all the big primitives. that MCP offers. So we have five primitives, three on the server side, two on the client side. But how do you put it all together to actually build a rich interaction? Because that's what we want. We want to build something for users that's a bit richer than just tool calling. And so let's take a look at how you will build a hypothetical MCP server that interacts with your favorite chat application, be that Discord, be it Slack. You could use prompts. to give examples to users such as like summarize this discussion and you can use completions with the recent threats users or whatever you want them to expose you can have additional problems like what's new what happened since yesterday and so that's one way the user can just kick start right away into using the server you've provided and get the ideas um that you how you intended it to be used and then you can use resources to directly list the channels, to expose recent threads that happen in the chat application such that the MCP client can index it, deal with it in ways that it wants. And then of course, last but not least, we still have our tools. We have search, we have read channels, we have reading of threads, and we will use sampling to summarize. a threat for example and really expose this and that's a way to really build a much much much richer experience with mcp to use the full power that the protocol has to offer but this is just the the beginning because most of these experiences if we build mcp servers so far have been experiences that stayed local out of the 10 000 mcp servers the community has built over the last six to seven months the vast majority are local experiences But I think we can take the next step, and I think this is MCP's really big next thing, is bringing MCP servers away from the local experience to the web. And so what does this mean? It means that instead of having an MCP server that is, you know, a Docker container or some form of local executable, it is nothing else but a website that your client can connect to and expose this MCP and you talk to. But for that... we need two critical components. We need authorization and we need scaling. And in the most recent specification of MCP, we made a ton of changes towards this from the lessons we have learned and the feedback we honestly got from the community as well as key partners. And we worked closely, for example, with people in the industry that worked on OAuth and other aspects to get this right. with authorization in mcp what you can do is you can basically provide the private context of a user that might be behind an online account or something directly to the llm application and it really enables mcp authors to bind the capability of the mcp servers to a user an online account something like that and in order to do that The way this currently has to work in MCP is that you do this by providing OAuth as the authorization layer. And the MCP specification basically says you need to do OAuth 2.1. And that's a bit daunting because very few people know what OAuth 2.1 is. But OAuth 2.1 is usually just OAuth 2.0 with all the basic things you would do anyway, all these security considerations that people that have done OAuth telling you anyway to do. So it's just OAuth 2.0, a little bit cleaned up, and you're probably already doing it if you're doing OAuth. And if you do implement this OAuth flow, you get two interesting patterns out of that. And the first one is the scenario of an MCP server in the web. And a good example of this is if you, for example, a payment provider, and you have, you know, website payment.com, and I, as a user, have an online account there. Now I, as the payment provider, can expose mcp.payment.com that the user can put into an MCP client. And the MCP client will do the OAuth flow. I log in as my account and I know this is payment.com. I know this is the person that is my online account with the provider that I trust. I don't trust some random Docker container running locally built by a third party developer anymore. I trust the person I already trust with the data anyway and their developers. And on their development side, they can just like update this server as they want, and they don't have to wait for me to download a new Docker image. And so this, I think, will be a really, really big step for enabling MCP servers to be exposed on the web and MCP clients to interact basically with all the online interactions that you already have. And here's just a small little example of this. In this scenario, we use Cloud AI integrations, which we launched earlier, um this month to connect to a remote server and use this OAuth flow to log in our user to then have tools available that are aware of my data that I care about it are for it is for me but it enables another aspect it enables enterprises to smoothly integrate MCP into their ecosystem how they usually build applications And what does this mean? It means that internally they can deploy an MCP server to their intranet or whatever they use and use an identity provider like Azure ID or Okta or whatever that central identity provider that you usually use for single sign-on. And you can have that still exist and it will be the one that... gives you the tokens that you require to interact with the MCP server. And that has a lot to say that what it ends up with is a very smooth integration. You're, as a development team internally, you're going to build an MCP server that you control, that you could control the deployment, and the user just logs in in the morning with their normal SSO like they always would do, and any time they use an MCP server from them on out, they will just be logged in and have access to the data that, you know, that is their data that the company has for them. And so this, I think, enables a new way that I've already seen some of the big enterprises do to build really vast systems of MCP servers that allow part of the company to build a server while the other part deals about the integrations, really nicely separates integration builder and platform builders. And then the second part that we require is scaling. And we just added a new thing called streamable HTTP, which is just to say it's a lot of words to say basically we want MCP servers to scale similar to normal APIs. And it's as simple as that. You have as a server author, you can choose to either return results directly. as you would be in a REST API, except that it's not quite just REST, or if you need to, you can open a stream and get richer interactions. So in the most simple way, you just want to provide a tool call result, you get a request, return application JSON, and off you go, end of the story, you close the connection, and the next connection come in and gets served by yet another Lambda function. But if you need richer interactions, such as notification or features we talked about, like sampling, a request comes in, you start a stream, the client accepts the stream, and now you're being able to send additional things to the client before you're returning finally the result. And those authorization and scaling together is really the foundation to make MCP go from this local experience now to be truly a standard for how LLM applications will interact with the web. And just to finish it all up, I just want to show you quickly about what's coming for MCP in the next few months of some of the most important highlights. And the most important part is that we are starting to think more and more about agents. And there's a lot to do there. There are asynchronous tasks that your cores want to run, things that are longer running, that are not just like a minute long, but maybe a few hours long. Tasks that an agent takes and that eventually I want to have a result for. So we think a lot about that, and we're going to work to build primitives for that into MCP in the near future. The second part of that is elicitation, so really MCP server authors being able to ask for input from the user. And that is something that's going to land just about today or on Monday in the protocol. And then we're doing two additional things. We first and foremost going to build an official registry to make sure there's a central place where you can find and publish to MCP servers so that we can really have one common place where we're going to look for these servers, but also allow agents to dynamically download servers and install them and use them. And then, of course, We're thinking more about multimodality. And that can be, for example, streaming of results. But that can have other aspects that I just don't want to go into details yet. And that's just the specification part. On the ecosystem part, we're going and having a lot of more things to go that we're doing at the moment. We're adding a Ruby SDK that is donated by Shopify in the next few weeks. And the Google folks, the Google Go team, is currently building an official Go SDK for MCP. And so I just hope that I was able to give you a bit of a more in-depth view of what you could do with MCP if you use the full power of the protocol. And with that, I think I'm a bit low on time, so I can't ask questions. We can't ask questions. We can't do Q&A. But just grab me afterwards, and I'm happy to answer on the hallway any questions you might have. So thank you so much.

Presented at Code w/ Claude by @anthropic-ai on May 22, 2025 in San Francisco, CA, USA.

Speakers:
David Soria Parra, Member of Technical Staff at @anthropic-ai