Building with MCP and the Claude API

- Am I reading your status updates then in your Slack and those are all Claude-generated? - Yeah, I'm never actually writing anything anymore. It's just all Claude. - It was just you reading Claude the whole time. Okay, good to know. - Mark. - Hey, I'm Alex. I lead Claude Relations here at Anthropic. Today we're talking about MCP and the Claude API, and I'm joined by my colleagues. - Hey, I'm Michael. I'm an engineer on the API team here at Anthropic. - I'm John and I work on the Model Context Protocol team here at Anthropic.

- To kick us off here today, I really wanna give a high level overview of just what is MCP. - MCP is the Model Context Protocol, and it's a way of providing external context to models. And so if you have a chat bot and you're in a conversation, the history of your conversation is your context. And the model only has the ability to see everything that you've typed in, which is really useful for some kinds of tasks, like, help me solve this problem or write this thing. But sometimes Claude needs access to things outside of its box, like it needs to be able to talk to the internet, or reach out to a travel agency to book your flight. And so that's kind of where MCP comes in. It provides these external context to Claude, so that it can take actions for you on your behalf in the outer world. - Right, yeah, I've heard a good analogy in the past of MCP being like the universal connector between applications and the model. So a way for us to tie Claude into everything else that it might need access to all the other data sources, tools, everything.

- Yeah, definitely. - Out there on the internet, basically. Why did we build this? What was kind of the intention? I mean, it seems useful to have these connections, but why did we take that on specifically and why make it a universal standard protocol? - So I think as we were starting to get further and further along in tool use and as Claude's capability, we were starting to notice that we were re-implementing a lot of the same capabilities in various different contexts. So my assistant that I had in my coding editor had to get a web search tool associated with it, but so did claude. ai and so did all these other services where we want Claude to be able to interact with the outside world. And we figured it would be good to have a single unified protocol that we can implement a set of functionalities once and take that everywhere. So build it once and configure everywhere. So the same web search functionality that I might get on Claude Code will be the same web search functionality that I would get on Claude. ai. - Okay, that makes sense. Creating that universal compatibility basically when we have tons of applications that might need these same connections. Now, our approach to MCP specifically with open sourcing, it was pretty different, I think, than a lot of other integration paths

that other companies were going down at the time. Why did we think to open source it? What was kind of the driving factor behind that? - I think there's a lot of value in open standards to allow a wide network of engineers, companies, individuals to go and build an ecosystem around something. And we could have gone and built the Claude app connector that allows you to tie things into Claude, but then you end up with a really kind of bad user experience for if you're using multiple models. If I'm a company like Asana and I want to go connect, do I have to go implement my Claude connector and my open AI connector and my Grok connector and my Gemini connector, and that ends up being kind of a nightmare. And one of the things that we had noticed is that models having access to external context is kind of good for everyone. It's like a rising tide floats all boats type of situation. And we had this internal protocol that was really valuable for us standardizing our model interactions. And so we went and open sourced it as a way of being like, hey, we found this useful, maybe the world would find this useful also. And it got incredibly popular, incredibly fast, it turns out a lot of people had the same kind of need and jumped on it and started just hacking together. Even with the minimum support, people started hacking together really incredible dev environments. And it kind of like boosted. I think it was the fastest-growing open source protocol, in history. - Wow. - It's been truly kind of stratospheric growth in there and there's a massive need for it. Yeah, so we went and open sourced that, and since this has taken off, it's truly succeeded our wildest dreams when we're releasing this little specification. And so we've done a lot of work as this is starting to move between a neat way for Anthropic, a project for Anthropic to go and get context to its models into an industry-defining standard-like ecosystem. We've done a lot of work to go and move that into a proper open source foundation and work with all the other providers

and make MCP something that's durable and is here for the long-term. - What is the lay of the land actually on MCP right now, both in terms of the open source community, but also the technical spec itself? It's been I guess almost a year, a little under a year since we first announced it. And I feel like a lot of folks still have kind of intuitions that were based in how it was, you know, earlier this year and early 2025 or something around that. But the protocols moving so fast and things are changing. What's the current state in your guys' mind of MCP? - I feel like a big aha moment for me at least, was when we released remote MCP support. Some of the initial quirks of the protocol were that you had to run everything effectively by yourself, which prevented providers of MCP servers like Asana from being able to host their own servers that you could just access very, very quickly. And it made the setup process very, very yeah, clunky. And I think that, yeah, a very big step change in my opinion, was when we kind of provided first-class support for remote hosted MCP servers, that drastically reduced the set of process, so that end users can just get started fairly quickly. - And now we have a registry of these servers, so people can actually upload these to the registry

and then we authorize them or we approve them and- - Yeah, totally. So the open source project has a, we've just released a central registry of MCP servers. In kind of keeping with the open source ethos, we have both a registry that's hosted at the model contact protocol organization site, and also a standard that allows other organizations to extend the registry, pull that information in. And so we've seen massive growth of MCP, GitHub MCP, Asana MCP, a lot of companies are building and deploying these endpoints. And so it's becoming easier to pull this in from a, in the past you would have to go and if you wanted to interact with GitHub, you'd have to go find some random developer who would hack together a GitHub connector and then trust their Node. js install on your computer to go in. And now you can just go hit the official GitHub site, like I think it's mcp. github. com, you can put that into your Claude Code or Claude. ai and then extend Claude with the ability to interact with GitHub. So it's really maturing in a way that's really cool. - That's pretty cool. And I've been using the GitHub MCP for things in Claude Code as well, and it's nice to just have that one your all endpoint

that just plug in. Is there any kind of fun, unique MCPs right now in the registry or outside of the registry that you guys have seen? - I think one that I think has been really, really interesting to watch, it's called Context 7. So one of the biggest limitations of large language models is that they have a knowledge cutoff that's usually, you know, delayed by a couple of months, which means that working with the latest and greatest packages as a software developer, sometimes difficult with LLMs, because they will just give you outdated information. And what Context 7 does is it takes care of pulling documentation from these websites like Next. js's website or even our own API's website and keeping those up-to-date. And all you have to do is configure your MCP connection once, and Claude will have the access to the latest information out there on whatever it is that you're developing against. - Mm, okay. Yeah, I think I had heard of that. So we're basically pulling in the latest docs, everything, and I know right now we're also in the mid-transition of a lot of folks making their docs completely just raw text and accessible to LLMs. So I'm assuming that's pulling from that same sort of information. - Yeah, so this is like the llms. txt format, which I've seen a lot of adoption of throughout the entire tech industry, which has been very exciting to see. - That's cool. Any from you, John? - From my end, I found it useful, from my work as a software developer, I really like Playwright as an MCP server, which allows Claude to go and interact with browsers as though it was a user clicking around. So if you're working on a website, Claude can read all your CSS and read your HTML, but it can't actually look at your webpage. But if you go and install the Playwright MCP server, then you can have Claude go look at your webpage and give you advice on how to make it more beautiful or fix alignment issues. - So it's like actually screenshots. - Yeah, it's actually loading it up in a browser, browsing around using Playwright. It's a Microsoft project that allows remote browser driving. - What happens when you put that in a loop with something like Claude code? - Oh, you can just, you can get some self-improvement loops. If I tell Claude Code to go and fix an alignment problem in a header, it can go make some changes to my HTML, CSS, reload the page if necessary, then go look at it again and be like, oh, everything looks better, or that didn't fix it, and it has the context of seeing both its changes and then actually being able to take a screenshot of the website and say, oh, this set of CSS changes actually led to this effect that I didn't intend. Let me roll that back and try a different way. - Mm, it's a different type of alignment problem. - Yeah, the CSS alignment problem, maybe it even need even a harder problem. Switching gears a little bit, if I'm a developer and I wanna use the Claude API

how can I use MCPs with our API and with Claude models? - So that's excellent question. The canonical standard way of doing this is to install the MCP SDK, set up your own loop, like you mentioned with Claude Code and handle connecting to any MCP server that you need to get connected to. But it's essentially your responsibility as a software developer to put together all the glue work, which is great and it works. But what we recently released directly into the API as a native feature is the MCP connector feature, which allows you to just specify where your remote MCPs live, like mcp. github. com, and provide us with whatever authorization information and we can take care of that calling loop of executing the tools and getting the results fed back to the model for you. So all you really have to do is send a single API call that says like, give me my latest pull requests. and it will go ahead and take care of that for you. - That's awesome, yeah, I've been hearing from a lot of developers that they've just been able to delete tons of code, because they just have that so they don't have to handle all that back and forth themselves now, just like passing the URL and to the end point and then you're kind of good to go.

What are some other tips for developers using MCP? - I think that the main one that I try to give developers when I talk is that MCP servers and tools are really at its core prompts. And so we've kind of learned that if you're writing AI-powered applications, it's really important to be careful and precise about the language that you use when you're prompting the model. This extends to everything about defining your MCP server, like defining your tool names appropriately, giving them descriptions. Maybe your description has a few short examples in the description of how to use it, giving appropriate parameter names. This is all stuff that's gonna affect your model's behavior when it interacts with the MCP server. An example though that I had was I was making an image generation server and I had a tool called Generate Image, and then it had a field called Description, and that's it. And then, you tell Claude like, "Hey, generate me an image of a cute puppy," and it'll go along, call the tool, be like, "Description, cute puppy. " Great. If you go and change that, and you say like, "This tool calls the XXX diffusion model, version Y and should be prompted in this style for best results," use this kind of descriptive language, do all of this. Claude has information about how to interact with these systems and it just needs to be told, oh great, I know that I'm talking to a diffusion model now, I'm gonna change my language, what I'm gonna use in this prompt, and it's gonna go and instead of asking for a cute puppy, it's just gonna give you a much more detailed diffusion model prompt that'll give you much better results. You get much better results from your MCP server just by changing a few words in your description or your prompt name. Just the same as you get better results writing pull requests or doing any sort of knowledge work with Claude that you would by tweaking those. - I mean I myself forget this all the time, that when you're dealing with a tool or some sort of description in isolation as you're working on a new feature for some, you know, AI app, it all gets pulled back into the same prompt, right? And it's all just like one text string at the end of the day that's getting fed into the model in each request. And yeah, that's good advice that like, hey, that's part of the prompt too. The description that you're writing in some JSON somewhere in your code is still gonna be pulled into that same prompt that gets sent to Claude on the request.

Let's talk a little bit about context management as well and dealing with lots of tools and lots of results. I mean, this is a huge problem for LLMs right now in terms of polluting the context. Curious if you have any thoughts there on how developers should think about that with MCP? - Yeah, so I think a big anti-pattern that we've seen a lot of developers make is just stuffing their MCP servers or their API requests with MCP servers with just tons of tools or tons of MCP servers, which not only gets expensive, because you're just generating tokens for every single one that you're adding, but also has a tendency of confusing the model. An example is if you connect both your linear and your Asana task management MCP servers in the same request, both of those might have a get project status MCP tool and the model will not have an implicit information about which one of them to use in which context. But beyond that, you're just, yeah, you're essentially confusing the model by giving it potentially conflicting information. So just being very, very careful and deterministic about which tools you add, making sure that they ergonomics around them also makes sense and that using those tools feels natural to you if you are getting to use them yourself. But beyond that, making sure that you, yeah, just don't include any information that might not necessarily help with the current turn of user prompts. So sometimes older parts of the conversation that might involve very introductory information, like, you know, what's the weather today? Might not be as relevant much, much later on in the conversation when you are moving on to the latest news or some other information that you need from the model. - Hm, I often get asked, how many tools can pass into Claude? Or how many MCP servers can I hook up at one time? And it seems like it's not so much a number question, rather, it's like a, how distinct are the tools from each other and how well-defined and scoped out. Is that correct or is there also kind of like a absolute number of MCPs? - I think you also end up with an absolute number. If your context window is X tokens, each server is gonna pull in a number of function definitions. Each of those is gonna eat it up. So you're gonna just start. As you give LLMs more information, it makes it harder for them to make good decisions. And so even though it will probably work if you hook up to a bunch of servers, it'll probably work better if you can give Claude a subset that's relevant to the task that it's looking at. One other point coming out here from what Michael was saying is if you're designing an MCP server, generally if you can have one or two tools in your server versus having 15 or 20 tools, it'll help the model a lot. And so it's sometimes MCP interface development is a bit different than API development where we're feeding these into LLMs. And if you give a tool a description that maybe takes some natural language or has as part of filling out the parameters, the model's gonna make some decisions and generates some text, you can maybe get away with instead of an API where you'd be like, get projects, get posts, get users. You might just have a get info tool, because you're calling LLM will be able to look at your description and fill out whatever information it needs. And that way you can provide a much smaller set of tools, you will both play nicer with other MCP servers and you'll ensure that your server gets called more efficiently appropriately. - Right, so it's not always a one-to-one translation. There's different levels of abstraction that you can apply and perhaps the API spec is not the best-defined thing for the model to take in either, yeah. So you guys live and breathe MCP all day every day, basically. How are you guys using it, whether it's at work or whether it's at home or side project or anything else?

I know the example of Playwright, but is there other ways that you guys are experimenting with MCP on the side? - One of the biggest use cases that I've found personally is Anthropic is often an information highway. There's just so much information all over the place between our Slack and our docs and our code base and getting the latest status on how the project that I'm currently on is going is not often very, very easy to understand from just a single source. So what I've gotten in the habit of doing is I will either on Claude AR or on Claude code set up my MCP servers to connect to all these various locations and I'll just ask it, "Hey, here's a couple of examples of past project updates that I've written myself. Can you go find information from the last week and generate a status update using the same exact format? " And I would say that the success rate on that is much, much higher than I originally thought. - Am I reading your status updates then in your Slack and those are all Claude-generated? - Yeah, I'm never actually writing anything anymore. It's just all Claude. - It was just you reading Claude the whole time. Okay, good to know. How about you John? - I found a couple of angles from hacking around my home hardware. I have some MCP servers running on my home network that can control things around my house. And so I can go and in a conversation with Claude, be like, "Hey, did I leave my door unlocked this morning? " And Claude can say, "Yeah, your door is currently unlocked, would you like me to lock it for you? " And come back and be like, "Yeah, that'd be great. " That sort of thing's really useful, kind of fun to play with it. It kind of feels like a sneak peek into what the future world might look like.

There's kind of a magical feeling with MCP servers, because you get these sort of emergent properties from adding them that you might not expect. An example of this is when we were very first time we started playing with MCP servers, I built a knowledge graph server with some of my colleagues here at Anthropic. - A knowledge graph in this case is? - A knowledge graph, meaning we wanted to give Claude the ability to take memories and form connections between memories. And so it's an MCP server that had two tools. It's a create memory tool and a connect memory to other memory tool and the simplest possible interface. And we hooked this up to Claude, and suddenly you'd have conversations with Claude and it would enter investigative journalist mode where I'd say like, "I play piano. " And Claude would be like, "That's amazing, what do you like to play? " And it's, I'm like, "I like to play Rachmaninoff. " And it's like, "Is there anything that's your favorite there? " And I'd look at the knowledge graph and Claude is going and scribbling down and be like, "User has sophisticated classical music taste," and it's trying to find, it's skilled in instruments and that's just from such a small change that you provided. And one of the really cool things with having MCP as a protocol is if you hook in your Gmail server with your home automation server, then maybe you can go and Claude can figure out some way to solve a problem that you ask it, by connecting those two together you might never have thought of. - Right, yeah, there's kind of that fuzzy in between when these things all get hooked together where pair that with Claude's kinda general intelligence and interesting things can happen. - And it's like one of the core differences between MCP and traditional-structured APIs where because everything is so fuzzy and because the LLMs are smart enough to just kind of smush it together, you care a lot less about contracts. There's this interesting property where if I have an MCP server for interacting with Gmail and then I go and I do some evals and I find a better set of tools and descriptions to interact with Gmail and it changes it from 15 tools with a set of descriptions to two tools with the other one, I don't have to go and roll out a new version of my API for that. If you're changing your API in a massive way like that- - You have to deal with breaking changes. - Breaking changes, talking to users, doing all of that, MCP, I can just roll that out and because the intent of the MCP is to allow Claude to interact with Gmail, it's not like I'm gonna provide a read emails tool and a write email tool. So it's really cool. - Yeah, it's about more like the higher level intent

and actions than the specific technical detail of how we get there. - Yeah, yeah. - That's really cool. So where's this all headed? Where's MCP gonna be in, you know, 6 months, 12 months, a year-plus? - That's an interesting question, because I've always viewed, you know, like John said, MCP is a protocol, so it's very interesting to see popularity for a protocol considering that it, you know, if MCP is successful and us and everybody that integrates with it did their job right, we should never know that MCP is happening under the hood. It should just be you using whatever program or app that you're using and MCP is happening under the hood just making everything glued together and LLMs kind of configure everything, so you're just giving it the arms and the legs that it needs. But yeah, it's always been interesting to me to see the hype around MCP. - Right, do you think that's gonna continue? Is there like a plateau here or what does that actually look like in terms of protocol? Is there any sort of precedent we can look at to judge MCP against? - I think it's hard applying a precedent to anything in the world of AI that we're in, but I definitely see a lot of this stuff that John and his colleagues over on the MCP team have been doing, is very exciting. And it's very, it to me, it's been amazing seeing companies big and small come to the table and come talk about how we can proliferate it and make it a, this ubiquitous thing that is just everywhere the same way that, I don't know, our internet is. - One thing that's really exciting for me going forward. I think we're at a point now where a lot of people have realized the value of MCP and they've started writing these servers, but in terms of the MCP servers as prompts analogy, we're in very early days. And so I am really excited for people now that they've started building out these servers to start evaluating how they work and making them better. And I'm excited for it to start to become a metric by which you might evaluate a vendor for your work. If I'm paying someone to do log analytics, for example, it would be really cool, it's really valuable to me if I could just hook in your log analytics MCP server into my Claude and say, "Hey, my site is down, what's going on? " And if they've gone and designed and developed a really wonderful MCP server that gives Claude the tools it needs to interact with their services and find those answers, then that's a huge selling point for me as an engineer, 'cause then I can rely on this functionality. I don't have to build it. And I'm excited for this to start becoming more mature and have it be less of. It's exciting that we've shipped an MCP server and starting to see people compete on, "We have the best MCP server. This is gonna make your life so much easier, you should use us, because we interact with Claude in this way. " - Well, I'm excited for that future as well. Thank you guys for coming on. This has been great. - Thank you. - Thank you so much.