MCP 201 | Code w/ Claude

Key Takeaways

[Music] [Applause] Well, hello. Uh, my name is David. I'm a member of technical staff at Anthropic and one of the co-creators of uh, MCP. And today I'm going to tell you a little bit more about the protocol and the things you can do um just to give you an understanding of um 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. um that goes beyond the tool call 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 like 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 um that servers can expose to MCP clients that very few people know. And those are called prompts. And what a 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 text, you know, like a prompt in a way um that allows um users to directly um add this to the context window and see how they would use for example the MCP uh server uh you're building. And there are really the two main use cases here is for you as an MCP server author to provide an example for um 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 uh 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 um put into the context window um the comments from my pull request that is that you know I've written so that I can go and interact with it and have then the model go and help me you know apply the changes that has 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 wants to put into the context window before it interacts with the yellow lamb. So it's different from that from tools where the model decides when to do it. This is what that the user decides um I want to add this um to the context window. And if you look carefully, there's one additional thing that very very few people know um that you can do and that is prompt completion. So if you have looked carefully, there was a way where it showcased quickly a popup of me selecting the poll requests that are available to myself. And that is a way that you can 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're in Typescript, building a prompt that provides users with um like such a template and have parameters for it and like autocomp completion is nothing more than a few lines of code that cloud code together with cloud 4 can most of the time write basically for you. And it's just that simple. It's a function for the completion. 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 than an MCP server can expose to an MCP client. And while prompts are really focused on text snippets that a user can add uh 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. So 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 context uh from prompts but it also allows application to do additional things to that raw data and that could be for example building embeddings around this data the server exposes and then do retrieval augmented uh generation um 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 uh how resources work. In this case, this is again uh one of these um uh ways where an MCP client exposes a resource um as a file like object. And in this scenario here, we are exposing the database schema for apostra database um as resources and then you can add them in cloud 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 going to see is Claude is going to go uh 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 unexport space still here. Again, if you go beyond just like adding it file 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 the user interacts with there's the second one is resources that the application interact with then of course there should be a third one that you all are very familiar with um 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 quing a database for you or whatever it might be. Um 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. And if you think carefully about these three primitives that I just showcased you to to you, there's a little bit of overlap about like how do you use like they could like when do you use what really and so there's something that very 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 userdriven 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 applicationdriven. The application that uses the LLM be it cloud desktop be it VS code something like that fully is decides what it wants to do with that. And then lastly tools are driven by the model. in between, you know, 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 um 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 a really an example I want to give you um 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 hand 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 clawed 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 like of of a model provider and be it the anthropic SDK you still need then like a API key that this user needs to provide and 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 in 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 um a second part which is that if you take multiple um 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 like system, there might be then your Asia 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 um that an MCP server wants to do with a model. And that allows for very powerful chaining and it allows for like more complex patterns that go already into like 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 projects uh products. We will bring um sampling somewhere this year. Um 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 um I've probably named terribly to be fair I'm not a very not 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 MCP deal like 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 MC sorry, 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 open, 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 open 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 These are, you know, 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 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 recent threads, users or whatever you want them to expose. You can have additional prompts like what's new, what happened since yesterday. And so that's one way the user can just kickstart right away into using the server you have 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 threats that happened in the in the you know chat application such that the MCP client can index it deal with it in ways um that it 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 a threads and we would use sampling to summarize a thread 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 exposes 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've learned and the feedback we honestly got from the community as well as like key partners. And we work closely for example with like people in the industry that worked on and other aspects to get this right. And so 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 OOTH as the authorization layer. And the MCP specification basically says you need to do O 2.1. And that's a bit daunting because very few people know what OOTH 2.1 is. But OA 2.1 is usually just O 2.0 with all the basic things you would do anyway. all these security considerations that people that have done a wall telling you anyway to do. So it's just OS 2.0 zero a little bit cleaned up and you're probably already doing it if you're doing a wall and if you do implement this wall 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 or flow. I log in as my account and I know this is payment.com. I know this is the 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 the their development side, they can just ex like ex like update this server as they want and they don't have to wait for me to download a new like docker image. And so this is 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 AAI integrations which we launched earlier um this month to connect to a remote server and use this oath 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 internet or whatever like they use and use an identity provider like Azure ID or Octar 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 um 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 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 you always would do and anytime they use an MCP server from them on on out, they will just be logged in and have access to the data that you know the 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 um part of the company to build a server um while the other part deals about the integrations really nicely separates uh 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 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 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, you return application JSON and off you go. End of the story. You close the connection and the next connection come in and uh you know get 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 like what's coming for MCP in the next few months of some of the the most important highlights. And the most important part is that um we are starting to think more and more about agents and there's a lot to do there. There are a synchronous task that you of course want to run things that are longer running that are not just like a minute long but maybe a few few like hours long task 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 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. um 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 e on the ecosystem part we going and having a more things to go that we're doing at the moment. We're adding a Ruby SDK that is uh donated by Shopify uh in the next few weeks and the Google uh 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 bit low on time, so I can't ask question. We can't ask questions. We can't do Q&A, but just grab me afterwards and I can happy to answer on the hallway any questions you might have. So, thank you so much. [Music]