Building with MCP and the Claude API

Alex Albert 0:00 Am I reading your status updates then in your Slack, and those are all Claude-generated? [laughs]

Michael Cohen 0:04 I, yeah, I'm never, I'm never actually writing anything anymore. It's just all Claude.

Alex Albert 0:07 I'm just reading Claude the whole time. [laughs]

Michael Cohen 0:09 [laughs]

Alex Albert 0:09 Okay, good to know. [upbeat music] 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.

Michael Cohen 0:23 Hey, I'm Michael. I'm an engineer on the API team here at Anthropic.

John Welsh 0:27 I'm John, and I work on the Model Context Protocol team here at Anthropic.

Alex Albert 0:30 To kick us off here today, uh, I really wanna give a high-level overview of just what is MCP.

John Welsh 0:36 MCP is, uh, the Model Context Protocol, and, uh, 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 conversation is your context, and the model only has the ability to see everything that you've typed in, um, 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, um, things outside of its box, like it needs to be able to talk to the internet, or it needs to be able to reach out to a travel agency to book your flight.

Alex Albert 1:08 Mm-hmm.

John Welsh 1:08 And so that's kind of where MCP comes in. Like, it provides these external context to Claude so that it can take actions for you on your behalf in the outer world.

Alex Albert 1:16 Right. Yeah, I've heard, I've heard a good analogy in the past of MCP being like the universal connector-

John Welsh 1:22 Yeah

Alex Albert 1:22 ... between applications and the model.

John Welsh 1:23 Yeah.

Michael Cohen 1:24 Mm-hmm.

Alex Albert 1:24 So a way for us to tie Claude into everything else that it might need access to, all the other data sources, tools,

Alex Albert 1:30 everything-

John Welsh 1:31 Yeah, definitely

Alex Albert 1:32 ... out there on the internet, basically. Why did we build this? What, what was kinda 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?

Michael Cohen 1:44 So I think as we were, um, starting to get further and further along in tool use and, uh, as Claude's capability, we were starting to notice that we were re-implementing a lot of the same capabilities in var-various different contexts. So my assistant that I had in my coding editor, um, had to get a web search tool associated with it-

Alex Albert 2:04 Mm-hmm

Michael Cohen 2:04 ... um, but so did claude.ai, and so did all these other surfaces where we want Claude to be able to interact with the outside world. And, uh, we figured it would be good to have a single unified protocol that, um, we can implement a set of functionalities once-

Alex Albert 2:19 Mm-hmm

Michael Cohen 2:20 ... and, um, take that everywhere. So build it once and configure everywhere. So the same web search functionality that I might get on Claude Code, uh, will be the same web search functionality that I would get on claude.ai.

Alex Albert 2:32 Okay, that makes sense, uh, creating that universal compatibility, basically, when we have tons of applications that might need these same connections. Um, now, our approach to MCP spec-specifically with open sourcing it was pretty different, I think, than a lot of other integration

Alex Albert 2:50 paths that other companies were going down at the time. Why did we think to open source it? Like, what was kinda like the driving factor behind that?

John Welsh 2:57 I think there's a lot of value in open standards to allow, uh, a wide network of, of engineers, companies, um, individuals to go and, um, build an ecosystem around something. And, uh, we could have gone and built the, uh, the Claude app connector that allows you to tie your things into Claude, but then, like, you end up with a really kind of bad, uh, user experience for if you're, if you're using multiple models. If, 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 OpenAI connector and my Groq connector and my Gemini connector? And that, 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 floats all boats type of situation.

Alex Albert 3:48 Mm-hmm.

John Welsh 3:48 And, uh, we had this internal protocol that was really valuable, um, for us standardizing our model interactions. And so we went and open sourced it as a, as a way of being like, "Hey, like, we found this useful. Maybe the world would find this useful also." And it got incredibly popular incredibly fast.

Alex Albert 4:07 Yeah.

John Welsh 4:07 Like, it turns out a lot of people had 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 environments, and it kind of, like, boosted. I think it was the fastest-growing open source, like, protocol, like-

Alex Albert 4:25 Mm-hmm

John Welsh 4:25 ... in history.

Alex Albert 4:26 Wow.

John Welsh 4:26 It's been, uh, truly kinda s-stratospheric growth in there, and there was, like, a m-massive need for it. Yeah, so we went and open sourced that, and since this has taken off, uh, it's truly succeeded our wildest dreams when we were releasing this, like, little specification. And so we've done a lot of work, um, as this is starting to move between a, a neat way for Anthropic, a project for Anthropic to go and get context to its models into an industry-defining standard, uh, like ecosystem. We've done a lot of work to go and move that into a proper open source-

Alex Albert 4:58 Mm-hmm

John Welsh 4:59 ... foundation-

Alex Albert 4:59 Mm-hmm

John Welsh 4:59 ... and,

John Welsh 5:00 like, work with all the other providers and make MCP something that's durable and is here for the long term.

Alex Albert 5:06 What is the lay of the land actually on MCP right now, both in terms of, like, the open source community, but also the technical spec itself? It's been, like, 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, in early 2025 or something around that, but the protocol's moving so fast, and things are changing. What's, like, the current state in your guys' mind of MCP?

Michael Cohen 5:33 I feel like a big aha moment, for me at least, was, uh, when we released remote MCP support.

Alex Albert 5:39 Mm.

Michael Cohen 5:39 Some of the initial quirks of the protocol were that you had to run everything effectively by yourself, um, which, um, prevented providers of MCP servers like Asana from, uh, being able to host their own servers that you could just access very, very quickly. Um, and it made the setup process very, very, yeah, clunky.

Alex Albert 5:57 Mm-hmm.

Michael Cohen 5:58 And, um, I think the, yeah, a very big step ch-change, in my opinion, was when we kind of provided first-class support for, um, remote-hosted MCP servers-

Alex Albert 6:06 Mm-hmm

Michael Cohen 6:06 ... that drastically reduced the setup process-

Alex Albert 6:09 Mm-hmm

Michael Cohen 6:09 ... um, so that end users can just get started fairly quickly.

Alex Albert 6:12 And now we have a registry of these servers, so people

Alex Albert 6:15 can actually, like, upload these to the registry, and then we, like, authorize them or-

John Welsh 6:19 Yeah

Alex Albert 6:19 ... we approve them, and-

John Welsh 6:21 Yeah, totally. So the, the, the open source, uh, the, the open source project, um, uh, has a... We've just released a, a central registry of MCP servers. Um, 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. Um, and so we've seen massive growth of, like, MCP- GitHub MCP, like Asana MCP. Like, a, a lot of companies are, are, are building and deploying these endpoints, and so it's becoming easier to pull this in. Uh, 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 had hacked 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.

Alex Albert 7:32 Right.

John Welsh 7:33 Um, so it's really maturing in a way that's really cool.

Alex Albert 7:35 That's pretty cool, and I've been using the GitHub MCP for things in Claude Code as well, and it's nice

Alex Albert 7:40 to just have that one URL endpoint-

John Welsh 7:42 Yeah

Alex Albert 7:42 ... that can just plug in. Is there any kind of fun and unique MCPs right now in the registry or outside of the registry that you guys have seen?

Michael Cohen 7:50 I think one that, um, I think has been really, really interesting to watch, uh, it's called Context7.

Alex Albert 7:56 Mm.

Michael Cohen 7:56 Um, so one of the biggest limitations of large language models is that they have a knowledge cutoff, um, that's usually, you know, delayed by a couple of months, um, which means that working with, like, the latest and greatest packages as a software developer, um, is sometimes difficult with LLMs-

Alex Albert 8:10 Right

Michael Cohen 8:10 ... because they will just give you outdated information. Um, and what Context7 does is, um, it takes care of pulling, um, documentation from these websites, um, 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, um, MCP connection once, and Claude will have the access to the latest information out there on whatever it is that you're soft- uh, developing against.

Alex Albert 8:33 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-

Michael Cohen 8:45 Mm-hmm

Alex Albert 8:45 ... accessible to LLMs. So I'm assuming that's, like, pulling from that same sort of information, right?

Michael Cohen 8:50 Yeah. So this is, like, the llms.text-

Alex Albert 8:52 Yeah

Michael Cohen 8:53 ... um, format.

Alex Albert 8:53 Yeah.

Michael Cohen 8:54 Which I've seen a lot of, like, adoption of-

Alex Albert 8:56 Yeah

Michael Cohen 8:56 ... um, like, throughout the entire tech industry, which has been very exciting to see.

Alex Albert 8:59 That's cool.

John Welsh 9:00 Yeah.

Alex Albert 9:00 Any from you, John?

John Welsh 9:01 From, from, from my end, there's, um... I, I found it useful, I, I s- From, from my m- my work as a, as a software developer, I really like, um, Playwright as an MCP server, uh, which allows, uh, Claude to go and interact with browsers as though it was a user clicking around.

Alex Albert 9:19 Mm.

John Welsh 9:19 So if you're, like, working on a website, uh, 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, how to make it more beautiful or, like, fix alignment issues.

Alex Albert 9:38 So it's, like, actually screenshots.

John Welsh 9:40 Yeah. It's actually-

Alex Albert 9:40 Ah, okay

John Welsh 9:40 ... loading it up in a browser, browsing around using, um, Playwright. It's a Microsoft, uh, uh, project that allows, uh, remote br- browser driving.

Alex Albert 9:50 What happens when you put that in a loop with something like Claude Code?

John Welsh 9:53 Oh, you can just, uh, y- you can get some self-improvement loops. Like, if I tell Claude Code to go and fix an alignment problem in a header, um, it can go make some changes to my HTML, make some changes to my CSS, reload the page if necessary-

Alex Albert 10:07 Mm

John Welsh 10:07 ... then go look at it again and be like, "Oh, everything looks better"-

Alex Albert 10:10 Mm

John Welsh 10:11 ... 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, this set of CSS changes actually led to this effect that I didn't intend."

Alex Albert 10:23 Mm.

John Welsh 10:23 "Let me roll that back and try a different way."

Alex Albert 10:25 Mm.

Michael Cohen 10:25 It's a different type of alignment problem-

Alex Albert 10:27 Yeah. [laughs]

Michael Cohen 10:29 ... from what we normally work on.

Alex Albert 10:29 The CSS alignment problem maybe is-

Michael Cohen 10:30 Yes

Alex Albert 10:31 ... even a harder problem in some ways.

Michael Cohen 10:32 [laughs]

Alex Albert 10:34 Um, switching gears a little bit, uh, how... If I'm a developer and I wanna use the, the Claude

Alex Albert 10:40 API, how can I use MCPs with our API and with Claude models?

Michael Cohen 10:44 So that's excellent question. The canonical standard way of doing this is to install the MCP SDK, um, set up your own loop, like you mentioned with Claude Code, um, and handle connecting to any MCP server that you need to get connected to. Um, but it's essentially your responsibility as a software developer to put together all the glue work.

Alex Albert 11:03 Mm-hmm.

Michael Cohen 11:04 Um, which is great, and it works. Um, but what we recently released, um, directly into the API as a native feature is the MCP connector feature-

Alex Albert 11:12 Mm

Michael Cohen 11:12 ... which allows you to just specify where your remote MCPs live, like mcp.github.com, and, um, provide us with whatever authorization information, and we can take care of that, um, calling loop, um, 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"-

Alex Albert 11:33 Yeah

Michael Cohen 11:33 ... and it will, it will go ahead and take care of that for you.

Alex Albert 11:36 That's awesome. Yeah, I've been hearing from a lot of developers that they've just been able to delete tons of code-

Michael Cohen 11:40 Mm-hmm

Alex Albert 11:40 ... because they just have that, so they don't have to handle all that back and forth themselves now.

Michael Cohen 11:45 Mm.

Alex Albert 11:45 Just, like, pass in the URL and to the endpoint and then you're kind of good to go.

Michael Cohen 11:49 Mm-hmm.

Alex Albert 11:50 Um, what are some other tips for developers using MCP?

John Welsh 11:54 I think that, um, the main one that I try to give developers when I talk is that MCP servers and tools are really, at its core, prompts.

Alex Albert 12:05 Mm.

John Welsh 12:05 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, uh, appropriately, giving them descriptions. Maybe your description has a few short examples in the description of how to use it, giving, like, appropriate parameter names. Um, this is all stuff that's gonna affect your m-model's 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, a field called Description, and that's it. And then, like, 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." Great.

Alex Albert 12:55 Mm.

John Welsh 12:55 Um, if you go and change that and you say, like, uh, "This tool calls the XXX diffusion model version Y and is... should be prompted in this style, uh, for best results, like, use this kind of descriptive language," do, do all of this, Claude has information about, like, how to interact with these systems, and it just needs to be told, uh, "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 s- asking for a cute puppy, it's gonna give you a much more detailed, uh, 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, uh, writing pull requests or doing any sort of knowledge work with Claude that you, you would by, uh, by tweaking those.

Alex Albert 13:47 I mean, I f- myself forget this all the time, that when you're dealing with a tool or some sort of description in 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 in each request. And yeah, that's 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 gonna be pulled into that same prompt that gets sent to Claude on its own, quote, request.

Alex Albert 14:20 Let's talk a little bit about context management as well and, like, dealing with lots of tools and lots of results.

John Welsh 14:25 Mm.

Alex Albert 14:25 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.

Michael Cohen 14:35 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-

Alex Albert 14:47 Mm

Michael Cohen 14:47 ... which not only gets expensive because you're just generating tokens for every single one that you're adding, but, um, also has a tendency of confusing the model. An example is, um, if you connect both your Linear and your Asana task management MCP servers-

Alex Albert 15:02 Mm

Michael Cohen 15:02 ... um, in the same request, both of those might have a, uh, Get Project Status, uh, MCP tool, um, 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, um, yeah, you're, you're essentially confusing the model by giving it potentially conflicting information. So just, um, being very, very careful and deterministic about, like, which tools you add, making sure that the ergonomics around them also make sense, and that using those tools feels natural to you if you were getting to use them yourself. Um, but beyond that, making sure that you, um, 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, um, that might involve very introductory information like, you know, "What's the weather today?" um, 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.

Alex Albert 15:58 Hmm. I often get asked, how many tools can I 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.

Michael Cohen 16:14 Mm.

Alex Albert 16:14 Is that correct, or is there also kind of like a absolute number of MCPs limitation?

John Welsh 16:19 I think you'll, you'll, you'll also end up with an absolute number, like each, if your context window is, 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, um, just, just start. As you give LLMs more information, it, 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, a bunch of servers, um, it'll probably work better if you can give Claude a subset that's relevant to the task that it's looking at.

Alex Albert 16:49 Mm.

John Welsh 16:50 One other point coming out here from what Michael was saying is if you're designing an MCP server, uh, generally if you can have one or two tools in your server, uh, versus having, uh, 15 or 20 tools, it'll help the model a lot. And so it's sometimes M-MCP, like, interface development is, 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, like, as part of, like, filling out the parameters, the model's gonna 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... 'cause your 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 will both play nicer with other MCP servers, and you'll ensure that your server gets called, um, more efficiently and appropriately.

Alex Albert 17:58 Right. So it's not always a one-to-one translation. Like, there's different levels of abstraction-

John Welsh 18:02 Yeah, definitely

Alex Albert 18:03 ... that you can apply, and perhaps the API spec is not the best defined thing for the model to take in either. Yeah. Um, so you guys live and breathe MCP all day, every day, basically. Uh, how are you guys using it, whether it's at work or, uh,

Alex Albert 18:20 whether it's in-At home or a side project or anything else? I, I know the example with Playwright, but is there other ways that you guys are experimenting with MCP on the side?

Michael Cohen 18:27 One of the biggest use cases that I've found personally is, um, 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. Um, and getting the latest status on how the project that I'm currently on is going is not often very, very easy to-

Alex Albert 18:45 Mm

Michael Cohen 18:45 ... understand from just a single source. Um, so what I've gotten in the habit of doing is, um, I will either on claude.ai or on Claude Code, set up my MCP servers to connect to all these various locations. Um, and I'll just ask it, um, "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, uh, using the same exact format?" And I would say that, like, the, the success rate on that is, is much, much higher than I originally thought.

Alex Albert 19:13 Am I reading your status updates then in your Slack, and those are all Claude generated? [laughs]

Michael Cohen 19:18 I, yeah, I'm never-

Alex Albert 19:19 Yes. [laughs]

Michael Cohen 19:19 I'm never actually writing anything anymore.

Alex Albert 19:20 I've just been reading Claude the whole time. Okay, good to know. How about you, John?

John Welsh 19:25 I, I've found, uh, a couple of angles. Uh, from hacking around my home, home hardware, I, I have some MCP servers running on my, my home network that can control things around my house, and so I can go and in a conversation with Claude be like, "Hey, like, did, uh, 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?"

Alex Albert 19:49 Yeah.

John Welsh 19:49 And come back and be like, "Yeah, that'd be great." Uh, that sort of thing's really useful, um, kind of fun to play with. It, it's kind of feels like a sneak peek into

John Welsh 20:01 what the future world might look like. The, it's, there's kind of a magical feeling with MCP servers, uh, because you get these sort of emergent properties from adding them that you might not expect. Like, the, the, an example of, of this is, uh, when we very first time we started playing with MCP servers, I built a knowledge grap-graph server with some of my colleagues here at Anthropic. And-

Alex Albert 20:30 A knowledge graph in this case is?

John Welsh 20:32 A knowledge graph, meaning, uh, we wanted to give Claude the ability to take memories and form, like, connections between memories.

Alex Albert 20:40 I see.

John Welsh 20:40 And so it's an MCP server that had two tools. It's had 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 investigative journalist mode, where I'd, 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, "That's- is there any- anything that's, 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 tastes-"

Alex Albert 21:13 [laughs]

John Welsh 21:13 "... and is like trying to find like, like, uh, is, is skilled in instruments." And, and that's just from like s- and from a 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, um, maybe you can go and Claude can figure out some way to solve a problem that you ask it-

Alex Albert 21:39 Right

John Welsh 21:39 ... by connecting those two together you might never have thought of.

Alex Albert 21:41 Right.

John Welsh 21:42 Yeah.

Alex Albert 21:42 Yeah. So there's kind of that fuzzy in between when these things all get hooked together where-

John Welsh 21:47 Yeah

Alex Albert 21:47 ... pair that with Claude's kind of general intelligence and-

John Welsh 21:50 Yeah

Alex Albert 21:50 ... interesting things can happen.

John Welsh 21:52 And it's like one of the core differences between MCP and, um, like traditional structured APIs where because everything is so fuzzy and because the LLMs are smart enough to just kind of smush 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-

Alex Albert 22:20 Mm-hmm

John Welsh 22:20 ... interact with Gmail, and it changes it from 15 tools with this set of descriptions to like two tools with the other one, um, 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 s- massive way like that-

Alex Albert 22:31 You have to deal with breaking changes

John Welsh 22:32 ... breaking changes-

Alex Albert 22:33 Yeah

John Welsh 22:33 ... talking to users-

Alex Albert 22:34 Right

John Welsh 22:34 ... 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, a read emails tool and a write email tool.

Alex Albert 22:45 Right.

John Welsh 22:45 Um, so it's, it's really cool.

Alex Albert 22:47 Yeah, it's about more like the higher, higher level

Alex Albert 22:50 intent and like actions-

John Welsh 22:51 Yeah

Alex Albert 22:51 ... rather than like the sp- specific technical detail of how we get there.

John Welsh 22:54 Yeah.

Alex Albert 22:55 Yeah, that's really cool. Um, so where is this all headed? Where is MCP gonna be in, you know, six months, 12 months, a year plus?

Michael Cohen 23:04 That's an interesting question because I've always viewed, you know, like John said, MCP is a protocol. Um, so it's very interesting to see popularity for a protocol considering that, um, it, you know, if MCP is successful and, um, us and everybody that integrates with it did their job right, um, we should never know that MCP is, is happening under the hood. Um, it should just be you using whatever program or app that you're using, um, and MCP is happening under the hood, just making everything glued together-

Alex Albert 23:32 Mm

Michael Cohen 23:32 ... and LLMs kind of configure everything. So you're just giving it the arms and the legs that it needs. But yeah, it's, it's, it's always been interesting to me to see the, uh, the hype around MCP.

Alex Albert 23:41 Right. Right. Do you think that's gonna continue? Is there like a plateau here? What does that actually look like in terms of protocol? Is there any sort of precedent we can look at to like judge MCP against?

Michael Cohen 23:54 I think it's hard applying a precedent to anything in the world-

Alex Albert 23:57 Yeah

Michael Cohen 23:57 ... of, of AI that we're in.

Alex Albert 23:58 Yeah. Right. True.

Michael Cohen 23:59 Um, but, uh, I, I definitely see, um, a lot of the stuff that John and, and his colleagues over on the MCP team have been doing, um, is very exciting, and it's very, it, to me, it's been amazing seeing, um, companies big and small-

Alex Albert 24:11 Mm-hmm

Michael Cohen 24:11 ... um, come to the table and come talk about how we can proliferate it-

Alex Albert 24:14 Yeah

Michael Cohen 24:14 ... and make it a, this ubiquitous thing that is just everywhere, um, the same way that, I don't know, our internet is.

John Welsh 24:21 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's servers as prompts analogy, we're in like very early days.

Alex Albert 24:37 Mm.

John Welsh 24:37 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, 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, a really wonderful MCP server that gives Claude the tools it needs to like interact with their services and find those answers, then that's like a huge s- selling point for me as an engineer because then I can, 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, this is gonna make your life so much easier-

Alex Albert 25:42 Right

John Welsh 25:42 ... like you should use us-

Alex Albert 25:43 Right

John Welsh 25:43 ... because we interact with Claude in this way.

Alex Albert 25:47 Well, I'm excited for that future as well. Um, thank you guys for coming on. This has been great.

John Welsh 25:51 Yeah. Thank you so much. [outro music]