- The Model Context Protocol (MCP) serves as a universal connector, enabling large language models (LLMs) to access external data sources and tools beyond their initial training data.
- Open-sourcing MCP fostered a widespread ecosystem, simplifying integrations for developers and companies by offering a single standard for connecting LLMs to various applications.
- Recent advancements like remote MCP support and a central registry have drastically reduced setup complexity, making it easier for users to leverage powerful, pre-built connections with their LLMs.
Building with MCP and the Claude API
- MCP provides external context to LLMs, allowing them to take actions on your behalf in the "outer world" by interacting with internet services, applications, and tools.
- Anthropic open-sourced MCP to establish a universal standard, preventing re-implementation of common capabilities (like web search) across different LLM applications and fostering broader industry adoption.
- The introduction of remote MCP support and a central registry of MCP servers significantly streamlines the setup process, enabling users to connect to official services (e.g., GitHub MCP) with a single URL endpoint.
- Developers can now use the Claude API's native
MCP connectorfeature to specify remote MCPs and authorization, offloading the looping and execution of tool calls to the API. - Treat MCP server definitions—including tool names, descriptions, and parameter names—as core prompts; precise and detailed language here can drastically improve how the LLM interacts with and utilizes the tools.
- When designing MCP servers or API requests, avoid adding excessive tools or servers; too many can confuse the model, increase token costs, and dilute the effectiveness of distinct functionalities.
- Design MCP servers with fewer, broader tools (e.g., a
get infotool instead of separateget projects,get posts,get userstools), allowing the LLM's natural language understanding to fill out parameters more flexibly than rigid API specifications. - Leverage specialized MCP servers like "Context 7" for up-to-date documentation access or "Playwright" to enable LLMs to interact with web browsers, offering capabilities beyond an LLM's static knowledge.
MCP (Model Context Protocol) — A protocol that provides external context and tools to large language models, allowing them to interact with outside applications and data.
LLM (Large Language Model) — An artificial intelligence model trained on vast amounts of text data, capable of understanding, generating, and processing human language.
Context window — The maximum amount of text (tokens) an LLM can process or "see" at any given time within a conversation or request.
Knowledge cut-off — The specific date beyond which an LLM's training data does not contain information, meaning it is unaware of more recent events or developments.
Remote MCP server — An MCP server hosted by a third-party provider, allowing users to connect to its capabilities remotely via a URL rather than running it locally.
Prompt engineering — The practice of carefully crafting inputs (prompts) and tool descriptions for LLMs to guide their behavior and elicit desired responses when interacting with MCPs or other systems.
Function definitions — The structured descriptions of tools or functions (including name, description, and parameters) that an LLM can call, provided as part of its context to enable tool use.
Open standard — A specification or protocol that is publicly available and free for anyone to use, implement, and extend, fostering widespread adoption and interoperability.
Playwright — A browser automation library (used here as an MCP server) that allows an LLM to programmatically control and interact with web browsers, enabling tasks like browsing and screenshotting.
Context management — The strategic selection and filtering of information and tools provided to an LLM, aiming to keep the input relevant, prevent confusion, and optimize token usage within its limited context window.
Am I reading your status updates then and you're sliding those are all Claude generated? I, yeah, I'm never actually writing anything for a short-term reading. Clouds all the time. Okay, good to know. 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 Mavic context political team here at Anthropic. To kick us off here today, I really want to give a high level of review 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 chatbot and you're in a conversation, the history of your conversations 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. I can be able to talk to the internet or needs to be able to 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 like 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 and to use and as clouds capability, we were starting to notice that we were re-implementing a lot of the same capabilities in various different contexts. So my assistants that I had in my coding editor had to get a web search tool associated with it. But so to Claude that AI and so did all these other surfaces 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 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 that 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 then a lot of other integration paths that other companies were going down at the time. Why did we think to open sourcing like what was kind of like 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 your 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 like do I have to go implement my Claude connector and my open app connector and my GROC 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 is kind of good for everyone. It's like a rising tide for its 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 a like we found this useful maybe the world would find this useful also and it got incredibly popular and incredibly fast. Like it turns out a lot of people had the same kind of need and jumped on it and started just hacking together even with like the minimum support people started hacking together. Really incredible Dev and Ryman saying it kind of like boosted. I think it was the fastest growing open source like protocol like in history. Wow it's been a truly kind of stratosphere growth and there's like a massive need for it. Yeah so we went in open source 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 a neat way for anthropic 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 like work with all the other providers and make MCP something that's durable and here for the long term. What is the lay of the land action on MCP right now both in terms of like the open source community but also the technical spec itself. It's been like yes 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 in early 2025 or something around that but protocols moving so fast and things are changing what's like the current state in your eyes 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 where 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 setup process so that end users can just get started fairly quickly. And now we have a registry of these servers so people can actually like upload these to the registry then we like authorize them or we improve them and yeah totally so the the open source that 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 like GitHub MCP like Asana MCP like a lot of companies are are building and deploying these endpoints and so it's becoming easier to pull this in from a in 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 right 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 URL endpoint like this plugin. 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 cut off that's usually you know delayed by a couple of months which means that working with like the latest and greatest packages as a software developer sometimes difficult with LLM's because they will just give you updated information and what context 7 does is it takes care of pulling documentation from these websites like nextjs as 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. 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 accessible to LLM's so I'm assuming that's like pulling from that same sort of information. Yeah so this is like the LLM's.Tex format yeah which I've seen a lot of like adoption of yeah like throughout the entire tech industry which has been very exciting to see. That's cool. I need from you John. From from my end there's um I found it useful I guess from from my my work as a as a software developer I really like playwright as an MCP server which allows a Claude to go and interact with browsers as though it was a user clicking around so if you're like working on a website Claude can read all your CSS and read your HTML but it can't actually look at your web page but if you go and install the playwright MCP server then you can have Claude go look at your web page and give you advice on how to make it more beautiful or like fix alignment issues. So it's like actually screenshots. Yeah it's actually loading it up in a browser browsing around using playwrighted so 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 uh you can get some self-improvement loops like if I tell Claude Code to go and fix an alignment problem in a header. It can go make some changes to my HTML make some changes to my 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 like take a screenshot of the website and and say oh the set of CSS changes actually led to this effect that I didn't intend let me roll that back and try a different way. It's a different type of alignment problem. Yeah. Yeah. The CSS alignment problem maybe is even harder problem. Switching gears a little bit. How if I'm a developer and I want to use the 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 MCPs decay, 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.getHub.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 lettuce pull requests yeah and it will it will go ahead and take care of that for you. That's awesome. 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 pass in the URL and to the endpoint and then 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 a score 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 shot examples in the description of how to use it giving like appropriate parameter names. This is all stuff that's going to affect your models behavior when it interacts with the MCP server. An example 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 go along call the tool be like description a cute puppy. If you go and change that and you say like this tool calls the XXX diffusion model version why and should be prompted in the style for best results like use this kind of scripted language to do all of this. Claude has information about like 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 going to change my language what I'm going to use in this prompt and it's going to go and instead of asking for cute puppy I just going to give you a much more detailed diffusion model prompt that will 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 and doing any sort of knowledge work with Claude that you you would by 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 and isolation as you're like 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 and each request and yeah that's a good advice that like hey that's part of the prompt too like the description that you're writing in some JSON somewhere in your code is still going to be pulled into that same prompt that gets sent to Claude on its own the request. Let's talk a little bit about context management as well and like dealing with lots of tools and lots of results. I mean this is a huge problem for elements right now in terms of polluting the context. Curious if you've 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 request 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 like which tools you add making sure that they are going to omics around them also makes sense and that using those tools feels natural to you if you were getting to use them yourself but beyond that making sure that you yeah just don't 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. I often get asked how many tools can pass in 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? You also end up with an absolute number like each if your context window is X tokens each server is going to pull in a number of function definitions each of those is going to eat it up so you're going to just just start as you give elements more information it makes it hard for them to make good decisions and so even though it will probably work if you hook up a bunch of 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 like 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 national language or has like as part of like filling out the parameters the model is going to make some decisions and 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 like get info tool where where the because you're calling LLM will be able to like look at your description and fill out whatever information it needs and that way you can provide like a much smaller set of tools you both play nice 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 like there's different levels of abstraction and apply and perhaps the API spec is not the best defined thing for the model to take in either yeah so you guys live in breed MCP all day every day basically how are you guys using it whether it's at work or whether it's a home or side project or anything else I know the example playwright is there other ways that you guys are experiment to MCP on the side one of the biggest use cases that I found personally is andthropic 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 gone in the habit of doing is I will either on claude.ai 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 like the success rate on that is much much higher than I originally thought. Am I reading your status of dates and and your slag in those are all Claude generated? I've never actually read anything. I've been just reading clouds all the time okay good to know how are you John? I've found a couple of angles from hacking around my home 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 a conversation in Claude be like hey like 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 would be great. That sort of things really useful kind of fun to play with it it's kind of feels like a sneak peek into what the future world might look like the it's 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 like the an example of of this is when we were very first time we started playing with MCP servers I built a knowledge gap graph server with some of my colleagues here at Anthropic and knowledge graph in this case is a knowledge graph meaning we wanted to give Claude the ability to take memories and form like connections between memories so it's an MCP server that had two tools it said 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 Claude suddenly you'd have conversations with Claude and it would enter your 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 unlike I like to play rock on and off and it's like that's is there any anything that's your favorite there and 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 like trying to find like like it's it's skilled in instruments and and that's just from like and from such a small change that you provide it 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 yeah pair that with clouds kind of general intelligence and yeah interesting things can happen and it's like one of the core differences between MCP and like traditional structured APIs where because everything is so fuzzy and because the LMS are smart enough to just kind of smoosh it together like you care a lot less about contracts like 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 like a better set of tools and descriptions to interact with Gmail and it changes it from 15 tools with the set of descriptions until like two tools with the other one I don't have to go and roll out a new version of my API for that like if you're changing your API in a massive way like that yeah it's a 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 it to interact with Gmail it's not like I'm going to provide a read emails tool and a write email tool so it's yeah it's about more like the higher level intent and like actions yeah like the specific technical detail of how we get there yeah that's really cool so where's this all headed where's MCP going to be in you know six months 12 months year plus that's an interesting question because I've always viewed you know like John said at MCP is a protocol so it's very interesting to see popularity for a protocol considering that 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 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 glue together and LLM's 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 going to continue is there like a plateau here or what does that actually look like in terms of protocols there any sort of precedent we can look at to like John Gemsy P against I think it's hard to 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 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 one thing that's 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 like very early days and so I'm really excited for people now that they've started building out these servers to start like evaluating how they how they work and making them better and I'm excited for it to start to become a metric by which you might evaluate like a vendor for your work like if I'm if I'm hiring a log 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 like a huge selling point for me as an engineer because then I can I can rely on this function now 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 this is going to make your life so much easier like 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 been great thank you so much
TL;DR
- The Model Context Protocol (MCP) serves as a universal connector, enabling large language models (LLMs) to access external data sources and tools beyond their initial training data.
- Open-sourcing MCP fostered a widespread ecosystem, simplifying integrations for developers and companies by offering a single standard for connecting LLMs to various applications.
- Recent advancements like remote MCP support and a central registry have drastically reduced setup complexity, making it easier for users to leverage powerful, pre-built connections with their LLMs.
Takeaways
- MCP provides external context to LLMs, allowing them to take actions on your behalf in the "outer world" by interacting with internet services, applications, and tools.
- Anthropic open-sourced MCP to establish a universal standard, preventing re-implementation of common capabilities (like web search) across different LLM applications and fostering broader industry adoption.
- The introduction of remote MCP support and a central registry of MCP servers significantly streamlines the setup process, enabling users to connect to official services (e.g., GitHub MCP) with a single URL endpoint.
- Developers can now use the Claude API's native
MCP connectorfeature to specify remote MCPs and authorization, offloading the looping and execution of tool calls to the API. - Treat MCP server definitions—including tool names, descriptions, and parameter names—as core prompts; precise and detailed language here can drastically improve how the LLM interacts with and utilizes the tools.
- When designing MCP servers or API requests, avoid adding excessive tools or servers; too many can confuse the model, increase token costs, and dilute the effectiveness of distinct functionalities.
- Design MCP servers with fewer, broader tools (e.g., a
get infotool instead of separateget projects,get posts,get userstools), allowing the LLM's natural language understanding to fill out parameters more flexibly than rigid API specifications. - Leverage specialized MCP servers like "Context 7" for up-to-date documentation access or "Playwright" to enable LLMs to interact with web browsers, offering capabilities beyond an LLM's static knowledge.
Vocabulary
MCP (Model Context Protocol) — A protocol that provides external context and tools to large language models, allowing them to interact with outside applications and data.
LLM (Large Language Model) — An artificial intelligence model trained on vast amounts of text data, capable of understanding, generating, and processing human language.
Context window — The maximum amount of text (tokens) an LLM can process or "see" at any given time within a conversation or request.
Knowledge cut-off — The specific date beyond which an LLM's training data does not contain information, meaning it is unaware of more recent events or developments.
Remote MCP server — An MCP server hosted by a third-party provider, allowing users to connect to its capabilities remotely via a URL rather than running it locally.
Prompt engineering — The practice of carefully crafting inputs (prompts) and tool descriptions for LLMs to guide their behavior and elicit desired responses when interacting with MCPs or other systems.
Function definitions — The structured descriptions of tools or functions (including name, description, and parameters) that an LLM can call, provided as part of its context to enable tool use.
Open standard — A specification or protocol that is publicly available and free for anyone to use, implement, and extend, fostering widespread adoption and interoperability.
Playwright — A browser automation library (used here as an MCP server) that allows an LLM to programmatically control and interact with web browsers, enabling tasks like browsing and screenshotting.
Context management — The strategic selection and filtering of information and tools provided to an LLM, aiming to keep the input relevant, prevent confusion, and optimize token usage within its limited context window.
Transcript
Am I reading your status updates then and you're sliding those are all Claude generated? I, yeah, I'm never actually writing anything for a short-term reading. Clouds all the time. Okay, good to know. 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 Mavic context political team here at Anthropic. To kick us off here today, I really want to give a high level of review 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 chatbot and you're in a conversation, the history of your conversations 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. I can be able to talk to the internet or needs to be able to 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 like 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 and to use and as clouds capability, we were starting to notice that we were re-implementing a lot of the same capabilities in various different contexts. So my assistants that I had in my coding editor had to get a web search tool associated with it. But so to Claude that AI and so did all these other surfaces 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 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 that 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 then a lot of other integration paths that other companies were going down at the time. Why did we think to open sourcing like what was kind of like 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 your 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 like do I have to go implement my Claude connector and my open app connector and my GROC 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 is kind of good for everyone. It's like a rising tide for its 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 a like we found this useful maybe the world would find this useful also and it got incredibly popular and incredibly fast. Like it turns out a lot of people had the same kind of need and jumped on it and started just hacking together even with like the minimum support people started hacking together. Really incredible Dev and Ryman saying it kind of like boosted. I think it was the fastest growing open source like protocol like in history. Wow it's been a truly kind of stratosphere growth and there's like a massive need for it. Yeah so we went in open source 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 a neat way for anthropic 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 like work with all the other providers and make MCP something that's durable and here for the long term. What is the lay of the land action on MCP right now both in terms of like the open source community but also the technical spec itself. It's been like yes 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 in early 2025 or something around that but protocols moving so fast and things are changing what's like the current state in your eyes 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 where 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 setup process so that end users can just get started fairly quickly. And now we have a registry of these servers so people can actually like upload these to the registry then we like authorize them or we improve them and yeah totally so the the open source that 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 like GitHub MCP like Asana MCP like a lot of companies are are building and deploying these endpoints and so it's becoming easier to pull this in from a in 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 right 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 URL endpoint like this plugin. 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 cut off that's usually you know delayed by a couple of months which means that working with like the latest and greatest packages as a software developer sometimes difficult with LLM's because they will just give you updated information and what context 7 does is it takes care of pulling documentation from these websites like nextjs as 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. 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 accessible to LLM's so I'm assuming that's like pulling from that same sort of information. Yeah so this is like the LLM's.Tex format yeah which I've seen a lot of like adoption of yeah like throughout the entire tech industry which has been very exciting to see. That's cool. I need from you John. From from my end there's um I found it useful I guess from from my my work as a as a software developer I really like playwright as an MCP server which allows a Claude to go and interact with browsers as though it was a user clicking around so if you're like working on a website Claude can read all your CSS and read your HTML but it can't actually look at your web page but if you go and install the playwright MCP server then you can have Claude go look at your web page and give you advice on how to make it more beautiful or like fix alignment issues. So it's like actually screenshots. Yeah it's actually loading it up in a browser browsing around using playwrighted so 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 uh you can get some self-improvement loops like if I tell Claude Code to go and fix an alignment problem in a header. It can go make some changes to my HTML make some changes to my 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 like take a screenshot of the website and and say oh the set of CSS changes actually led to this effect that I didn't intend let me roll that back and try a different way. It's a different type of alignment problem. Yeah. Yeah. The CSS alignment problem maybe is even harder problem. Switching gears a little bit. How if I'm a developer and I want to use the 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 MCPs decay, 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.getHub.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 lettuce pull requests yeah and it will it will go ahead and take care of that for you. That's awesome. 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 pass in the URL and to the endpoint and then 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 a score 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 shot examples in the description of how to use it giving like appropriate parameter names. This is all stuff that's going to affect your models behavior when it interacts with the MCP server. An example 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 go along call the tool be like description a cute puppy. If you go and change that and you say like this tool calls the XXX diffusion model version why and should be prompted in the style for best results like use this kind of scripted language to do all of this. Claude has information about like 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 going to change my language what I'm going to use in this prompt and it's going to go and instead of asking for cute puppy I just going to give you a much more detailed diffusion model prompt that will 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 and doing any sort of knowledge work with Claude that you you would by 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 and isolation as you're like 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 and each request and yeah that's a good advice that like hey that's part of the prompt too like the description that you're writing in some JSON somewhere in your code is still going to be pulled into that same prompt that gets sent to Claude on its own the request. Let's talk a little bit about context management as well and like dealing with lots of tools and lots of results. I mean this is a huge problem for elements right now in terms of polluting the context. Curious if you've 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 request 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 like which tools you add making sure that they are going to omics around them also makes sense and that using those tools feels natural to you if you were getting to use them yourself but beyond that making sure that you yeah just don't 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. I often get asked how many tools can pass in 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? You also end up with an absolute number like each if your context window is X tokens each server is going to pull in a number of function definitions each of those is going to eat it up so you're going to just just start as you give elements more information it makes it hard for them to make good decisions and so even though it will probably work if you hook up a bunch of 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 like 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 national language or has like as part of like filling out the parameters the model is going to make some decisions and 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 like get info tool where where the because you're calling LLM will be able to like look at your description and fill out whatever information it needs and that way you can provide like a much smaller set of tools you both play nice 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 like there's different levels of abstraction and apply and perhaps the API spec is not the best defined thing for the model to take in either yeah so you guys live in breed MCP all day every day basically how are you guys using it whether it's at work or whether it's a home or side project or anything else I know the example playwright is there other ways that you guys are experiment to MCP on the side one of the biggest use cases that I found personally is andthropic 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 gone in the habit of doing is I will either on claude.ai 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 like the success rate on that is much much higher than I originally thought. Am I reading your status of dates and and your slag in those are all Claude generated? I've never actually read anything. I've been just reading clouds all the time okay good to know how are you John? I've found a couple of angles from hacking around my home 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 a conversation in Claude be like hey like 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 would be great. That sort of things really useful kind of fun to play with it it's kind of feels like a sneak peek into what the future world might look like the it's 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 like the an example of of this is when we were very first time we started playing with MCP servers I built a knowledge gap graph server with some of my colleagues here at Anthropic and knowledge graph in this case is a knowledge graph meaning we wanted to give Claude the ability to take memories and form like connections between memories so it's an MCP server that had two tools it said 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 Claude suddenly you'd have conversations with Claude and it would enter your 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 unlike I like to play rock on and off and it's like that's is there any anything that's your favorite there and 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 like trying to find like like it's it's skilled in instruments and and that's just from like and from such a small change that you provide it 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 yeah pair that with clouds kind of general intelligence and yeah interesting things can happen and it's like one of the core differences between MCP and like traditional structured APIs where because everything is so fuzzy and because the LMS are smart enough to just kind of smoosh it together like you care a lot less about contracts like 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 like a better set of tools and descriptions to interact with Gmail and it changes it from 15 tools with the set of descriptions until like two tools with the other one I don't have to go and roll out a new version of my API for that like if you're changing your API in a massive way like that yeah it's a 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 it to interact with Gmail it's not like I'm going to provide a read emails tool and a write email tool so it's yeah it's about more like the higher level intent and like actions yeah like the specific technical detail of how we get there yeah that's really cool so where's this all headed where's MCP going to be in you know six months 12 months year plus that's an interesting question because I've always viewed you know like John said at MCP is a protocol so it's very interesting to see popularity for a protocol considering that 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 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 glue together and LLM's 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 going to continue is there like a plateau here or what does that actually look like in terms of protocols there any sort of precedent we can look at to like John Gemsy P against I think it's hard to 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 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 one thing that's 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 like very early days and so I'm really excited for people now that they've started building out these servers to start like evaluating how they how they work and making them better and I'm excited for it to start to become a metric by which you might evaluate like a vendor for your work like if I'm if I'm hiring a log 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 like a huge selling point for me as an engineer because then I can I can rely on this function now 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 this is going to make your life so much easier like 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 been great thank you so much