Building Agents with Model Context Protocol - Full Workshop with Mahesh Murag of Anthropic

Hey everyone.

Hello.

Hello. Thank you all for coming. My name is Mahesh, and I'm on the Applied AI team at Anthropic. I'm really excited to see a very full room, and very excited that you chose me over OpenAI.

Thank you very much.

So today we're going to be talking about MCP, Model Context Protocol. This is more of a talk than a workshop, but I'll do my best to keep it interactive. If you want to ask questions, feel free to do so, and I'll do my best to answer them.

Today we're going to talk about the philosophy behind MCP and why we at Anthropic thought that it was an important thing to launch and build. We're going to talk about some of the early traction of MCP in the last couple of months, and then some of the patterns that allow MCP to be adopted for AI applications, for agents, and then the roadmap and where we're going from here.

Cool. So our motivation behind MCP was the core concept that models are only as good as the context we provide to them. This is a pretty obvious thing to us now, but I think a year ago, when most AI assistants or applications were chatbots, you would bring in the context to these chatbots by copy-pasting, or by typing, or kind of pasting context from other systems that you're using.

But over the past few months, in the past year, we've seen these evolve into systems where the model actually has hooks into your data and your context, which makes it more powerful and more personalized. And so we saw the opportunity to launch MCP, which is an open protocol that enables seamless integration between AI apps and agents and your tools and data sources.

The way to think about MCP is by first thinking about the protocols and systems that preceded it. APIs became a thing a while ago to standardize how web apps interact between the front end and the back end. It's a kind of protocol or layer in between them that allows them to translate requests from the back end to the front end and vice versa.

And this allows the front end to get access to things like servers and databases and services. LSP came later, and that standardizes how IDEs interact with language-specific tools. LSP is a big part of our inspiration, and it's called Language Server Protocol, and it allows an IDE that's LSP compatible to go and talk to and figure out theright ways to interact with different features of coding languages.

You could build a Go LSP server once, and any IDE that is LSP compatible can hook into all the things about Go when you're coding in Go. So that's where MCP was born. MCP standardizes how AI applications interact with external systems and does so in three primary ways and three interfaces that are part of the protocol, which are prompts, tools, and resources.

So here is the land before, the lay of the land before MCP that Anthropic was seeing. We spent a lot of time with customers and people trying to use our API to build these agents and AI applications. And what we were seeing is, across the industry, but also even inside of the companies that we were speaking to, there was a ton of fragmentation about how to build AI systems in theright way.

One team would kind of create this AI app that hooks into their context with this custom implementation that has its own custom prompt logic with different ways of bringing in tools and data, and then different ways of federating access to those tools and data to the agents.

And if different teams inside of a company are doing this, you can imagine that the entire industry is probably doing this as well.

The world with MCP is a world of standardized AI development. You can see in the left box, which is the world of an MCP client, and there's some client examples here, like our own first-party applications. Recently, applications like Cursor and Windsurf, agents like Goose, which was launched by Block, all of those are MCP clients.

And there's now a standard interface for any of those client applications to connect to any MCP server with zero additional work. An MCP server, on theright side, is any, it's a wrapper or a way of federating access to various systems and tools that are relevant to the AI application.

So it could be a database to query and fetch data and to kind of give the LM access to databases and records. It could be a CRM like Salesforce, where you want to read and write to something that is hosted on a remote server, but you want the LM to have access to it.

It could even be things on your local laptop or your local system, like version control and Git, where you want the LM to be able to connect to the APIs that run on your computer itself.

So we can talk about the value that we've seen for different parts of the ecosystem over the past few months. The value for application developers is, once your client is MCP compatible, you can connect it to any server with zero additional work.

If you're a tool or API provider or someone that wants to give LMs access to the data that matters, you can build your MCP server once and see adoption of it everywhere across all of these different AI applications.

And just a quick aside, the way I like to frame this is, before MCP, we saw a lot of the n times m problem, where there were a ton of different permutations for how these folks interact with each other, how client applications talk to servers.

And MCP aims to flatten that and be the layer in between the application developers and the tool and API developers that want to give LMs access to these data. For end users, obviously, this leads to more powerful and context-rich AI applications.

If you've seen any of the demos on Twitter with Cursor and Windsurf, even our own first-party applications, you've seen that these systems are kind of context-rich, and they actually know things about you and can go and take action in the real world.

And for enterprises, there's now a clear way to separate concerns between different teams that are building different things on the roadmap. You might imagine that one team that owns the data infrastructure layer has a vector DB or a RAG system that they want to give access to to other teams building AI apps.

In a pre-MCP world, what we saw was every single individual team would build their own different way of accessing that vector database and deal with the prompting and the actual chunking logic that goes behind all of this. But with MCP, an enterprise can have a team that actually owns the vector DB interface and turns it into an MCP server.

They can own and maintain and improve that, publish a set of APIs, they can document it, and then all of the other teams inside their company can now build these AI apps in a centralized way, where they're moving a lot faster without needing to go and talk to that team every time that they need access to it or need a way to get that data.

And so you can kind of imagine this is like a world with microservices as well, where different people, different teams can own their specific service, and the entire company and the roadmap can move a lot faster.

Cool. So let's talk about adoption. This is something that's been really exciting over the past couple of months. It kind of comes up in almost every Anthropic conversation with people that we work with and a lot of our customers.

This slide covers a few different personas, but we can start with the AI applications and the IDEs. This has been really exciting

recently, and it provides this really nice way for people that are coding in an IDE to provide context to that IDE while they're working, and the agents inside those IDEs go and talk to these external systems like GitHub, like documentation sites, et cetera.

We've also seen a lot of development on the server side. I think to date, there are something like 1,100 community-built servers that folks have built and published open source. There are also a bunch of servers built by companies themselves.

I just built one as an example. There are folks like and a bunch of others that have published official integrations for ways to hook into their systems. There's also a ton of adoption on the open source side as well, so people that are actually contributing to the core protocol and the infrastructure layer around it.

So those

about what it actually means to build with MCP and some of the core concepts that are part of the protocol itself.

Here's kind of a view of the world of how to actually build with MCP. So on the left side, you have the MCP client that invokes tools, that queries for resources, and interpolates prompts, and kind of fills prompts with useful context for the model.

On the server side, the server builder exposes each of these things. They expose the tools, the resources, and the prompts in a way that's consumable by any client that connects to it. So let's talk about each of these components.

A tool is maybe the most intuitive and the thing that's developed the most over the past few months. A tool is model-controlled, and what that means is the server will expose tools to the client application, and the model within the client application, the LLM, can actually choose when the best time to invoke those tools is.

So if you use Claude for Desktop or any of these agent systems that are MCP compatible, usually the way this works is you'll interpolate various tools into the prompt. You'll give descriptions about how those tools are used as part of the server definition, and the model inside the application will choose when the best time to invoke those tools are.

And these tools are kind of, the possibilities are kind of endless. I mean, it's read tools to retrieve data. It's write tools to go and send data to applications or kind of take actions in various systems. It's tools to update databases, to write files on your local file system.

It's kind of anything. Now we get to resources. Resources are data exposed to the application, and they're application-controlled. What that means is the server could define or create images. It could create text files, JSON. Maybe it's keeping track of the actions that you've taken with the server within a JSON file, and it exposes that to the application, and then it's up to the application how to actually use that resource.

Resources provide this rich interface for applications and servers to interact that go just beyond you talking to a chatbot using text. So some of the use cases we've seen for this are files where the server either surfaces a static resource or a static file, or a dynamic resource where the client application can send the server some information about the user, about the file system that they're working in, and the server can interpolate that into this more complex data structure and send that back to the client application.

Inside Claude for Desktop, resources manifest as attachments. So we let people, when they're interacting with the server, go and click into our UI and then select a resource, and it gets attached to the chat and optionally sent to the model for whatever the user is working on.

But resources could also be automatically attached. You could have the model decide, hey, I see that there's this list of resources. This one is super relevant to the task we're working onright now. Let me automatically attach this to the chat or send it to the model and then proceed from there.

And finally, prompts. Prompts are user-controlled. We like to think of them as the tools that the user invokes as opposed to something that the model invokes. These are predefined templates for common interactions that you might have with this specific server.

A really good manifestation of this I've seen is in the IDE called Zed, where you have the concept of slash commands, where you're talking to the LLM, to the agent, and you say, hey, I'm working on this PR.

Can you go and summarize the work that I've done so far? And you just type slash GHPR. You give it the PR ID, and it actually will interpolate this longer prompt that's predefined by Zed inside of the MCP server, and it gets sent to the LLM, and you generate this really nice full data structure or full prompt that you can then send to the LLM itself.

A few other common use cases that we've seen are different teams have these standardized ways of, let's say, doing document Q&A. Maybe they have formatting rules. They have, inside of a transcript, they'll have different speakers and different ways they want the data to be presented.

They can service that or surface that inside the server as a prompt, and then the user can choose when it makes the most sense to invoke.

Cool. I'll pause there. Any questions so far about these various things and how they all fit together? Yeah, in the back.

Yeah, I think a big part of MCP, sorry, the question is, why aren't resources modeled in the same way as tools? Why couldn't they have just been tools? A big part of the thinking behind MCP broadly is it's not just about making the model better.

It's about actually defining the ways that the application itself can kind of interact with the server in these richer ways. And so tools are typically model-controlled, and we wanted to create a clean separation between what's model-controlled and application-controlled.

So you could actually imagine an application that's MCP compatible decides when it wants to put a resource into context. Maybe that's based on predefined rules. Maybe that's based on, it makes an LLM call and makes that decision. But we wanted to create a clean separation for the client builder and the server builder for what should be invoked by the model and what should be invoked by the application.

I saw you go first. Yeah, glasses. So the first example on the tools is the receives slash search, so vector database.

Is that protocol super fast compared to just using any tools to connect to my code? Yeah, the question is, are tools theright way to expose, let's say, a vector database to model? The answer is kind of up to you.

We think that these are really good to use when it's kind of ambiguous when a tool should be invoked. So maybe the LLM sometimes should go and call a vector DB. Maybe sometimes it already has the information in context, and sometimes it needs to go talk to, maybe it needs to go ask the user for more information before it does a search.

So that's probably how we think about it. If it's predetermined, then you probably don't need to use a tool. You just always call that vector DB.

Sorry. So the most things that MCP is able to do, the more important authorization and authentication becomes. How are people dealing with thisright now? They just inject them as part of one of the parameters, or is MCP going to provide some way to connect apps?

I'm going to get to that one later because it's very relevant, and we have a lot to say.

So I may have missed this, I'm down. So if you've gone down the route of using an agentic framework, which did tool calling, as you progress, would you just wrap the MCP with a tool if you had an existing solution?

Call it tool and then call it tool. Yeah, I think that it sounds like the broader question is, how does MCP fit in with agent frameworks? Cool. Yeah, I mean, the answer is they kind of complement each other.

Actually, LangGraph just this week released a bunch of connectors for, or I think they're called adapters for LangGraph agents to connect to MCP. So if you already have a system built inside LangGraph or another agent framework, if it has this connector to MCP servers, you can expose those servers to the agent without having to change your system itself, as long as that adapter is installed.

So we don't think MCP is going to replace agent frameworks. We just think it makes it a lot easier to hook into servers, tool prompts, and resources in a standardized way. OK, so my current the framework was a tool, and the tool could call MCP, so going forward, many of the tools would just be a wrap for an MCP call?

Yeah, the framework could call a tool, and that tool could be exposed to that framework from an MCP server if the adapter exists. Does that make sense? Yeah. Cool. I'll take one more if there are. Yeah. This is a loaded question that might be a bit early, but feel free to punt.

Why use an agent?

So the question is kind of, does MCP replace an agent framework, and why still use one? I don't think it replaces them. I think parts of it, it might replace the parts related to bringing context into the agent and calling tools and invoking these things.

But a lot of the agent frameworks' value, I think, is in the knowledge management and the agentic loop and how the agent actually responds to the data that's brought in by tools. And so I would think that there's still a lot of value in something where the agent framework defines how the LLM is running in the loop and how it actually decides when to invoke the tools and reach out to other systems.

But I don't think MCP as a protocol itself fully replaces it. MCP is more focused on being the standard layer to bring that context to the agent or to the agent framework. Yeah, I don't know if that's the most clear answer, but that's the one that we've at least seen so far.

That might change as MCP evolves.

Cool. Sorry, I saw one more, which I'll take, and then I will move on if that exists. Yeah.

You think that tools and resources are from. Thinking of this discussion,

say it comes from user input and prompts, they can be immutable. The resources are also immutable.

So why do you expect tools that return your resources and prompts? So I mean, for me, just confusing, but for you guys, I know that you talked about this a lot.

Yeah, so the question is, why do resources and prompts exist, and why isn't this all baked into tools? Because you can serve a lot of the same context via tools themselves. So I think we touched on this a little bit, but there's actually a lot more protocol capabilities built around resources and prompts than what I'm talking about here.

So part of your question was, aren't resources and prompts static? Can't they just be served as static data as part of a tool? In reality, resources and prompts in MCP can also be dynamic. They can be interpolated with context that's coming in from the user or from the application, and then the server can return a dynamic or kind of customized resource or customized prompt based on the task at hand.

Another kind of really valuable thing we've seen is resource notifications, where the client can actually subscribe to a resource, and anytime that resource gets updated by the server with new information, with new context, the server can actually notify the client and tell the client, hey, you need to go update the state of your system or surface new information to the user.

But the broader answer to your question is, yes, you can do a lot of things with just tools, but MCP isn't just about giving the model more context. It's about giving the application richer ways to interact with the various capabilities the server wants to provide.

So it's not just you want to give a standard way to invoke tools. It's also, if I'm a server builder and I want there to be a standard way for people to talk to my application, maybe that's a prompt.

Maybe I have a prompt that's like a five-step plan for how someone should invoke my server, and I want the client applications or the users to have access to that. That's a different paradigm because it's me giving the user access to something as opposed to me giving the tool access to something.

And so I kind of tried to write this out as model-controlled, application-controlled, and user-controlled. The point of MCP is to give more control to each of these different parts of the system as opposed to only just the model itself.

Yeah, I hope that kind of makes sense.

Cool. Allright, let's see what this actually looks like. The Wi-Fi is a bit weird. Hopefully, this works. Cool. So what we're looking at is Claude for Desktop, which is an MCP client. Let me try to pause as this goes through.

So Claude for Desktop, which is on the left side, an MCP client. And on theright side, I'm working inside of a GitHub application. Let's say I'm a repo maintainer for the Anthropic Python SDK. I need to get some work done.

What I'm doing here is I give the Claude for Desktop app the URL of the repo I'm working in, and I say, can you go and pull in the issues from this GitHub repo and help me triage them or help suggest the ones that sound most important to you?

The model, Claude, automatically decides to invoke the List Issues tool, which it thinks is the most relevant here, and actually calls that and pulls these into context and starts summarizing it for me. You'll also notice that I told it to triage them.

So it's automatically using what it knows about me from my previous interactions with Claude, maybe other things in this chat or in this project, to kind of intelligently decide, here are the top five that sound most important to you based on what I know about you.

And so that's where the interplay between just giving models tools and actually the application itself having other context about who I am, what I'm working on, the types of ways I like to interact with it, and then those things interplay with each other.

The next thing I do is I ask it, can you triage the top three highest priority issues and add them to my Asana project? I don't give it the name of the Asana project, but Claude knows that it needs to go and find that information autonomously.

So I've also installed an Asana server, and that has like 30 tools. It first decides to use List Workspaces, then Search Projects. It finds the project, and then it starts invoking tools to start adding these as tasks inside Asana.

So this might be a pretty common application that you like to use, but the things I want to call out are, one, I didn't build the Asana server or the GitHub server. These were built by the community. Each of them are just a couple hundred lines of code.

Primarily, it's a way of surfacing tools to the server. And so it's not a ton of additional logic to build. I would expect they could be built in an hour. And they're all kind of playing together with Claude for Desktop being the central interface.

It's really powerful to have these various tools that someone else built for systems that I care about all interplaying on this application that I like to use every single day. Claude, Claude for Desktop, kind of becomes the central dashboard for how I bring in context from my life, and I actually run my day-to-day.

And so inside Anthropic, we've been using things like this a ton to go and reach out to our Git repos to even make PRs or to bring in context from PRs. And MCP is the standard layer across all of those.

Cool. And so just to close that out, here's Windsurf. And it's an example with using different servers, but it's Windsurf's own application layer for connecting to MCP. They have their own kind of UI inside of their agent. It's their own way of talking to the MCP tools.

Other applications don't even call them MCP tools. For example, Goose calls them extensions. It's really up to the application builder how to actually bring this context into the application. The point is that there's a standard way to do this across all of these applications.

Awesome. So far, we've talked about how to bring context in and how MCP brings context into a lot of AI applications that you might already be familiar with. But the thing that we're most excited about and starting to see signs of is that MCP will be the foundational protocol for agents broadly.

And there's a few reasons for this. One is the actual protocol features and the capabilities that we're going to talk about in just a second. But it's also the fact that these agent systems are becoming better, that the models themselves are becoming better, and they use the data you can bring to them in increasingly effective ways.

And so we think that there's some really nice tailwinds here. And let's talk about how or why we think that this is going to be the case.

So you might be familiar with the blog that we put out. My friends Barry and Eric put out a couple months ago called Building Effective Agents. And one of the core things in the blog, one of the first ideas that was introduced, is this idea of an augmented LLM.

It's an LLM in the traditional way that it takes inputs, it takes outputs, and it kind of uses its intelligence to decide on some actions. But the augmentation piece are those arrows that you see going to things like retrieval systems, to tools, and to memory.

So those are the things that allow the LLM to query and write data to various systems. It allows the LLM to go and invoke tools and respond to the results of those tools in intelligent ways. And it allows the LLM to actually have some kind of state such that every interaction with it isn't a brand new fresh start.

It actually kind of keeps track of the progress it's made as it goes on. And so MCP fits in as basically that entire bottom layer. MCP can federate and make it easier for these LLMs to talk to retrieval systems, to invoke tools, to bring in memory.

And it does so in a standardized way. It means that you don't need to pre-build all of these capabilities into the agent when you're actually building it. It means that agents can expand after they've been programmed, even after they've been initialized and are starting to run, to start discovering different capabilities and different interactions with the world, even if they weren't programmed or built in to start.

And the core thing in the blog, or one of the simpler ideas in the blog, is agent systems at its core aren't that complicated. They are this augmented LLM concept running in a loop, where the augmented LLM goes and does a task.

It kind of works towards some kind of goal. It invokes a tool, looks at the response, and then does that again and again and again until it's done with the task. And so where MCP fits in is it gives the LLM, the augmented LLM, these capabilities in an open way.

What that means is even if you, as an agent builder, don't know everything that the agent needs to do at the time that you're building it, that's OK. The agent can go and discover these things as it's interacting with the system and as it's interacting with the real world.

You can let the users of the agent go and customize this and bring in their own context and their own ways that they want the agent to touch their data. And you, as the agent builder, can focus on the core loop.

You can focus on context management. You can focus on how it actually uses the memory, what kind of model it uses. The agent can be very focused on the actual interaction with the LLM at its core.

So I want to talk a little bit about what this actually looks like in practice. Let me switch over to screen sharing my screen.

Cool. So to talk about this, we're going to be talking about this framework, this open-source framework called MCP Agent that was built by our friends at Last Mile AI. I'm just using it as a really clean and simple example of how we've seen some of these agent systems kind of play in with MCP.

So I'm switching over to my code editor. Make this bigger. And what you see here is a pretty simple application. The entire thing is maybe 80 lines of code. And I'm defining a set of agents inside of this Python file.

The overall task that I want this agent to achieve is defined in this, this task.md. And basically, I want it to go and do research about quantum computing. I want it to give me a research report about quantum computing's impact on cybersecurity.

And I tell it a few things I want. I want to go look at the internet, synthesize that information, and then give that back to me in this nicely formatted file. And so what MCP Agent, the framework, lets us do is define these different sub-agents.

The first one I'm defining is what's called a research agent, where I give it the task that it's an expert web researcher. Its role is to go look on the internet, to go visit some nice URLs, and to give that data back in a nice and structured way in my file system.

And you'll see on the bottom is I've given it access to a few different MCP servers. I've given it access to Brave for searching the web. I've given it a fetch tool to actually go and pull in data from the internet.

And I've given it access to my file system. I did not build any of those MCP servers. And I'm just telling it the name, and it's going to go and invoke them and install them and make sure that the agent actually has access to them.

The next one, similarly, is a fact-checker agent. It's going to go and verify the information that's coming in from the research agent. And it's using the same tools, Brave, Fetch, and FileSystem. And these are just MCP servers that I'm giving it access to.

And finally, there's the research report writer agent. And that actually synthesizes all the data, looks at all the references and the fact-checking, and then produces a report for me in this nice format. This time, I'm only giving it the FileSystem and Fetch tools or servers.

I don't need it to go look at the internet. I just need it to process all the data that it has here.

And it knows what servers each of them have access to. And then once I kick it off, the first thing it's going to do is go and form a plan. A plan is just a series of steps for how it should go and interact with all these systems and the various steps it should take until it can call the task done.

So as an example, the first step, it's going to go and look at authoritative sources on quantum computing. And it's going to invoke the searcher agent in various different ways. It creates this plan based on the context about the agent's task, about the servers it has access to, and so on.

The next step is maybe it goes and verifies that information by focusing on the fact-checker agent specifically. And then finally, it intends to use the writer agent to go and synthesize all of this. The kind of core piece of this is MCP becomes this abstraction layer where the agent builder can really just focus on the task specifically and the way that the agent should interact with the systems around it, as opposed to the agent builder having to focus on the actual servers themselves or the tools or the data.

It kind of declares this in this really nice declarative way of, this is what your task is supposed to be, and here are the servers or tools that you have available to you to go and accomplish that task.

And so just to close out that part of the demo, I'm just going to kick this off. And what's going to be going on in the background is it's going to start doing some research. It's invoking the search tool, the search agent, and then it's going to invoke the fact-checking agent.

And you'll start to see these outputs appear on the left side of the screen. And so this is a pretty simple demo, but I think it's a very powerful thing for agent builders because you can now focus specifically on the agent loop and on the actual core capabilities of the agent itself and the tasks that the sub-agents are working on, as opposed to on the server capabilities and the ways to provide context to those agents.

The other really nice piece of this, which is obvious, is we didn't write those servers. Someone else in the community built them. Maybe the most authoritative source of research papers on quantum computing wrote them. But all we're doing is telling our agents to go and interface with them in a specific way.

And so you start to see the outputs form. It looks like the searcher agent put a bunch of sources in here. It's already started to draft the actual final report. And it's going to continue to iterate in the background.

Cool.

Have you seen people try to adapt something like this to their proprietary data and like a database or some other things like that?

Definitely. Yeah. So the question is, have we seen agent systems also working for proprietary data? The really nice thing about MCP, again, is that it's open. And so you can actually run MCP servers inside your own VPC. You can run it on your employees' individual systems or laptops themselves.

So the answer is definitely yeah. Yeah.

So this would be a big question. First of all, you're saying we can focus now on what the agent itself does. Does that mean that it's that we don't have as much control of the sources, the web server?

I'm just trying to separate these pieces together. What does the agent have as well? What is the context that's provided to the agent?

Yeah. So the question is, what does it mean to separate the agent itself and now the capabilities that other folks kind of give to it? I think the answer kind of varies. Some of the ways that we've seen to improve agent systems are what kind of model do you use?

Is it actually theright model for the specific task? If you're building a coding agent, you should use Claude. And there's also things like context management or knowledge management. How do you store the context and summarize it or compress that context as the context window gets larger?

There's orchestration systems. Like if you're using multi-agent, are they in series? Are they in parallel? And so there's a lot more that you can focus on based on your task in that sense, as well as the interface itself.

Like how is this surfaced to the user? And the separation is then maybe you build a bunch of your own MCP servers for your agent that are really, really customized to what you want to do. But when you want to expand the context to what the rest of the world is also working on or the systems that exist in the rest of the world, that's where MCP fits in.

You don't need to go and figure out how to hook into those systems. That's all pre-built for you.

Let's do yeah, that.

And most of what we call tools here, I have directly only one specific function. We call them tools that it's like one function, one thing. Are people building agents and develop agents exposing?

I don't know what tools he uses. I give him my inbox. I don't know what happens with it. I know that that's enough. So are people using MCP in this kind of way? Like only one endpoint that has a develop agent?

That the agent knows what tools it's using?

Yes. There is a slide that we'll get to, which is exactly that.

I'm sorry.

No, you're good. No, that's great. Really good questions. I'm going to do this side of the room because I didn't yeah.

What conditions? Like for instance, if you have a source repair.

Yeah. Not a ton of this is specific to Last Mile. I think it's a really great framework. It's called MCP-Agent. And specifically, what they worked on is they saw these things come out. One was the agents framework. There's really simple ways to think about agents.

Then they saw MCP, which is there are really simple ways to think about bringing context to agents. And so they built this framework, which allows you to implement the various workflows that were defined in the agents blog post using MCP and using these really nice declarative frameworks.

So what's specific to MCP Agent, the framework, is these different components or building blocks for building agents. So one is the concept of an agent. And an agent, as we've talked about, is an augmented LLM running in a loop.

So when you invoke an agent, you give it a task, you give it tools that it has access to, and the framework takes care of running that in a loop. It takes care of the LLM that's under the hood and all of those interactions.

And then using these building blocks, you go a layer above and you hook those agents together in different ways that are more agentic. And those are described in the paper. But one of the things in the blog post was this orchestrator workflow example.

So that's what I've implemented here, which is I've initialized an orchestrator agent, which is the one in charge of planning and keeping track of everything. And then I give it access to these various sub-agents using all these nice things that are part of MCP Agent.

That being said, it's open source. It's not that I'm blessing this is theright way to do it necessarily, but it's a really simple and elegant way of doing it. Sorry, there are a lot. Yeah.

Yeah. So the question is, how do resources and prompts fit in in this case? The answer is they don't. This example was more focused on the agentic loop and giving tools to them. I would say resources and prompts come in more where the user is within the loop.

So you might imagine, instead of me just kicking this off as a Python script, I have this nice UI where I'm talking to the agent, and then it goes and does some asynchronous work in the background. And it's a chat interface like what you might see with Claude.

In that case, the chat interface, the application could take this plan that I just showed you and surface this to me as a resource. The application could have this nice UI on the side that says, here is the first step, the second step, the third step.

And it's getting that as the server surfaces it to surface is the plan to it as this kind of format. Prompts could come in if

there's a few examples. But you could say a slash command to summarize all of the steps that have occurred already. You could say slash summarize. And there's a predefined prompt inside of the server that says, here's theright way to give the user a summary.

Here's what you should provide to the LLM when you go and invoke the summarization prompt. So the answer to your question is it doesn't fit in here, but there are ways it could. Yeah. OK, I'll take like two more.

Let's go with you.

Does this introduce any new workflows as it relates to evaluations

in this case? If you're surfacing a bunch of different tools, is there

any sort of MCP-native way to evaluations to understand if it's choosing theright tool or

just plug this into your normal eval pipeline?

I think the answer to the question is, how does this fit into evaluations? In particular, evals related to assessing tool calls and that being done theright way. I think

largely, it should be the same as it isright now. There is potential to have MCP be even a standard layer inside evals themselves. I probably need to think this through. But you can imagine that there's an MCP server that surfaces the same five tools.

And you give that server to one set of evals. Let's say you have one eval system running somewhere to evaluate these five different use cases. They have a different eval system. The MCP server could be the standard way to surface the tools that are relevant to your company to both of them.

But largely, I think it's similar to how it's been done already. Yeah. In the way.

I have two questions.

The first thing is that I'm trying to see the infrastructure side of this. So when you say that the server is in the way,

the server that it's with,

are these tools as a Google service that everybody is interfacing with? Or do you have other things that are similar?

I'll get to that.

OK. One is, I feel like the client and the server are sort of not clearly attributed because a lot of the stuff that you showed on the client side, how would you say that stuff like, I don't know, authentication or retry logic or all of that stuff, is that more on the client side with the agent frameworks or the one that you showedright now?

Or is that more on the server side? I feel like I'm not clear on where this is going.

Yeah. I can address part of this. So the question is, what is the separation between a lot of the logic that you need to implement in these systems? Where should it sit? Should it sit with the client or the server?

And the specific examples are things like retry logic, authentication. I'll get to auth in a bit. But on things like retry logic, I think my personal opinion, and I think this remains to be seen how it shakes out, is a lot of that should happen on the server side.

The server is closer to the end application and to the end system that's actually running somewhere. And therefore, the server should have more control over the interactions with that system. A big part of the design principle is, ideally, MCP supports clients that have never seen a server before.

They don't know anything about that server before the first time it's connected. And therefore, they shouldn't have to know theright ways to do retries. They shouldn't have to know how to do logging in the exact way that the server wants and things like that.

So the server is ideally closer to the end application. And it's the one that's the end service. And it's the one that's implementing a lot of that business logic.

Is there a consequence of either one of these frameworks have a lot less value because most of the logic is just?

It depends. I don't have a really strong opinion to take on where the agent frameworks themselves go. I could see one counterargument being that you don't always want the server builders to have to deal with that logic either.

Maybe the server builders want to just focus on exposing their APIs and letting all the agents do the work. And yeah, honestly, I don't have a really strong take on that. Yeah.

Is there a best practice as to how many agents you can use?

Yeah. That's a really good question. I'm glad you asked that. So a lot of the questions that we get sorry, the question here is, is there a best practice or a limit to the number of servers that you expose to an LLM?

In practice, the models of today, I think, are good up to like 50 or 100 tools. Like Claude is good up to a couple hundred in my experience. But beyond that, I think the question becomes, how do you search through or expose tools in theright way without overwhelming the context window, especially if you have thousands?

And I think there are a few different ways. Like one of the ones that's exciting is a tool to search tools. And so you can imagine a tool abstraction that implements RAG over tools. It implements fuzzy search or keyword search based on the entire library of tools that's available.

That's one way. We've also seen hierarchical systems of tools. So maybe you have a group of tools that's finance tools. You have read data. Then you have a group of tools that's for writing data. And you can progressively expose those groups of tools based on the current task at hand as opposed to putting them all in a system prompt, for example.

So there are a few ways to do it. I don't think everyone's landed on one way. But the answer is there's technically no limit if you implement it theright way. OK.

I don't know if you're going to get into this. But in terms of a methodology or best practice of like, I have an idea of the steps I need to take, like first, define the server, first, define my prompts and resources, are you going to kind of walk through a step-by-step process?

Do you have that documented somewhere?

Yeah. I'm not going to go through it yet. But we do have that documented. So the question is, what are theright steps to approach building an MCP server? What's the order of operations? We actually have this entire docs page that's like, how do you build an MCP server using Claude or using LLMs?

All the servers that we launched with in November, I think there were like 15 of them, I wrote all of those in like 45 minutes each with Claude. And so it's really easy to approach it. And I think tools are typically the best way for people to start grokking what a server is and then going to prompts and resources from there.

Do you want to share links to?

Yeah. Definitely. I'll share links later. Yeah. In the red.

I guess that begs the question that I've been scanning in the background on these servers. At what point do we need the servers whereas we just have a generic Claude model generator to make the servers? Everything I've seen is like API repertoires.

And so at some point, just one at night, what point of just

suddenly it shouldn't Claude be generating these? It has to be Claude because we know we're off the Google Maps. So maybe we're generating more of that. And I don't know why it needs a single.

Yeah. So the question is, if a lot of these servers are simple, can LLMs just generate them automatically? The answer is yes. If you guys have heard of CLIMB, which is one of the most popular IDEs that's open source, it has like 30K stars on GitHub.

They actually have an MCP auto-generator tool inside the app. You can just say, hey, I want to start talking to GitLab. Can you make me a server? And it just auto-generates on the fly.

So that's really not focused on servers, unless there's some special sauce that can't be handled with that tool.

That being said, I think that that works for the simpler servers, like the ones that are closer to just exposing an API. But there are more complex things that you want to do. You'll want to have logging or logic or data transformations.

But the answer is, yeah, for the more simple ones, I think that's a pretty normal workflow.

Are you talking to any GitHubs, Google's data that's saved for them to use?

Yeah. So the question is, are we talking to the actual owners of the services and the data? The answer is yes. A lot of them, a lot of the servers actually are official and public already. So if I just scroll through official integrations, these are like real companies like Cloudflare and Stripe that have already built official versions of these.

We're also talking to bigger folks. But I can't speak to that yet.

Are they available to the client?

They might also host the servers remotely. Yes. Yeah. They'll build it. And then they'll also maybe provide the infrastructure to expose it. Yeah. In the back.

Is there any practice that you've seen?

You're asking about versioning as it relates to the protocol or to servers?

Servers.

Yeah. So the question is, how do we do best practices for versioning? All these servers are so far, a lot of them are TypeScript packages on NPM or on pip. Therefore, they also have package versions associated with them.

And so there shouldn't generally be code breaking changes. There should be a pretty clear upgrade path. But yeah, I don't think we actually have best practices just yet for what to do when a server itself changes. For something like I mean, generally, I think it might break the workflow.

But I don't think it breaks the application if the server changes since as long as the client and server are both following the MCP protocol, the tools that are available might change over time or they might evolve. But the model can still invoke those in intelligent ways.

For resource and prompts, they might break users' workflows if those resources and prompt changes. But they'll still work as long as they're being exposed as part of the MCP protocol with theright list tools, call tools, list resources, et cetera.

I don't know if that answers your question, though.

I was thinking more on the fuzzy side that your tools change when your tools change.

Right. I think using versioning of the packages themselves makes sense for that. And then I'm going to talk a little bit about a registry. And having an MCP registry layer on top of all of this will also help a lot with that.

Yeah. OK. I'll take one more and then continue. Yeah.

I was thinking about

the server. I wonder how I think about

especially for people who are immigrated.

Yeah. The question is, how are we thinking about distribution and extension system? I'll get there, too. Yeah. Cool. Let's keep going.

So

we've talked about one way to build effective agents. And I showed how to do that using the MCP agent framework. Now I want to talk about the actual protocol capabilities that relate to agents and building agentic systems, with the caveat that these are capabilities in the protocol.

But it's still early days for how people are using these. And so I think a lot of this is going to evolve. But these are some early ideas. So one of the most powerful things that's underutilized about MCP is this paradigm called sampling.

Sampling allows an MCP server to request completions, AKA LLM inference calls, from the client instead of the server itself having to go and implement interaction with an LLM or to go host an LLM or call Claude. So what this actually means is, in typical applications, the one that we've talked about so far, it's a client where you talk to it.

And then it goes and invokes.

Server to have some kind of capability to get user inputs and then decide, hey, I actually don't have enough input from the user. Let me go ask it for more information. Or let me go formulate a question that I need to ask the user to give me more information.

And so there's a lot of use cases where you actually want the server to have access to intelligence. And so sampling allows you to federate these requests by letting the client own all interactions with the LLM. The client can own hosting the LLM if it's open source.

They can own what kind of models it's actually using under the hood. And the server can request inference using a whole bunch of different parameters, so things like model preferences. Maybe the server says, hey, I actually really want specifically this version of Claude.

Or I want a big model or a small model. Do your best to get me one of those. The server obviously will pass through a system prompt and a task prompt to the client. And then things like temperature, max tokens, it can request.

The client doesn't have to listen to any of this. The client can say, hey, this looks like a malicious call. I'm just not going to do it. And the client has full control over things like privacy, over the cost parameters.

Maybe it wants to limit the server to a certain number of requests. But the point is, this is a really nice interaction because one of the design principles, as we talked about, is oftentimes these servers are going to be something where the client has never seen them before.

It knows nothing about them. Yet it still needs to have some way for that server to request intelligence. And so we're going to talk about how this builds up a little bit to agents. But just putting this out there as something you should definitely explore because I think it's a bit underutilized thus far.

Cool. One of the other kind of building blocks of this is the idea of composability. So I think someone over there asked about composability, which is a client and a server is a logical separation. It's not a physical separation.

And so what that means is any application or API or agent can be both an MCP client and an MCP server. So if you look at this very simple diagram, let's say I'm the user talking to Claude for Desktop on the very left side.

And that's where the LLM lives. And then I go and make a call to an agent. I say, hey, can you go find me this information? I ask a research agent to go do that work. And that research agent is an MCP server.

But it's also an MCP client. That research agent can go and invoke other servers. Maybe it decides it wants to call the file system server, the fetch server, the web search server. And it goes and makes those calls and then brings the data back, does something with that data, and then brings it back to the user.

So there's this idea of chaining and of these interactions kind of hopping from the user to a client-server combination to the next client-server combination and so on. And so this allows you to build these really nice, complicated or complex architectures of different layers of LLM systems where each of them specializes in a particular task that's particularly relevant as well.

Any questions about composability? I'll touch on agents as well soon.

Yeah. Question.

How do you think about structure?

Yeah. So the question is, how do you deal with compounding errors if the system itself is complex and multi-layered? I think the answer is the same as it is for complex hierarchical agent systems as well. I don't think MCP necessarily makes that more or less difficult.

But in particular, yeah, in particular, I think it's up to each successive layer of the agent system to deal with information or controlling data as it's structured. So to be more specific, the third node there, kind of the middle client-server node, should collect data and fan in data from all of the other ones that it just reached out to.

And it should make sure it's up to par or meets whatever data structure JSON spec it needs to before passing that data to the systemright before it. I don't think that's special to MCP. I think that is true for all these multi-node systems.

It's just this provides a nice interface between each of them. Does that answer your question?

Yeah.

Cool. Sorry, I saw other hands.

On top of that, if you're calling the contract part via MCP, what are ultimately any API can be either MCP server? It can be MCP server also. What are the benefits for me hosting as an MCP server or just the API as a consent for you?

Yeah. The question is, why are these and why do they have to be MCP servers as opposed to just a regular HTTP server? The answer in this case for composability and the layered approach is that each of these can basically be agents.

In the system that you're kind of talking about here,

I think that there are reasons for a bunch of protocol capabilities like resource notifications, like server-to-client communication, the server requesting more information from the client that are built into the MCP protocol itself so that each of these interactions are more powerful than just data passing between different nodes.

Let's say each of these are agents. The first agent can ask the next agent for a specific set of data. It goes and does a bunch of asynchronous work, talks to the real world, brings it back, and then sends that back to the first client, which that might be multi-step.

It might take multiple interactions between each of those two nodes. And that's a more complex interaction that's captured within the MCP protocol that might not be captured if it were just regular HTTP servers.

Is that by using a Google API or the file system server MCP or just a function call? It will be results be the same,right?

I think that the point I'm trying to make is that

each of these so you're asking if the Google API or the file system things were just APIs, like regular non-MCP servers. But making it an MCP server, at least in this case, allows you to capture those as agents.

As in, they're more intelligent than just exposing data to the LLM. It's like each of them has autonomy. You can give a task to the second server. And it can go and make a bunch of decisions for how to pull in richer data.

You could, in theory, just make them regular APIs. But you lose out on these being independent, autonomous agents, each node in that system in the way it interacts with the task it's working on. Yeah.

So in terms of controlling the web source and rate limits, is that just handled by the first server you call? Or is there a more global way of managing that?

Yeah. It kind of depends on the builders. But I do think it's federated because the LLM is at the application layer. And so that has control over how rate limits work or how it should actually interact with the LLM.

It doesn't have to be that way. In theory, if the server builder, the first node, wanted to own the interaction with a specific LLM, maybe it's running open source on that specific server, it could be the one that controls the LLM interaction.

But in the example I'm giving here, the LLM lives at the very base layer and at the application layer. And it's the one that's controlling rate limits and control flow and things like that.

So a quick follow-up is that supposing you want to call from the previous client,right? And it's the last client that wants to call this client and wants the user input, would that have to go all the way back?

If it wants user input, it does have to go all the way back. Yeah. And MCP does allow you to pass those interactions all the way back and then all the way back forward. Yeah. I'm going to go on this side first.

Yeah.

Do you have to select a binary? I'm assuming that a little bit. There's a discrepancy. Is this flat? Is there room for a tie-break?

Yeah. The question is, how do you elect a primary? How do you make decisions in network? The answer is, it's kind of up to you. I'm not opining on network systems themselves or how these logic it's not a requirement.

It's not part of the protocol itself. It's just that MCP enables this architecture to exist. Yeah.

How do you do observability in this case? Either with the C++.

So I think the idea so the question is, how do you do observability? How do you know the other systems that are being invoked? From a technical perspective, there is no specific reason that the application or the user layer would know about those servers.

In theory, for example, the first client application or the first MCP server you see there is kind of a black box. It makes the decisions about if it wants to go invoke other sub-agents or other services. And I think that's just how the internet layer or APIs work today.

You don't exactly know always what's going on behind the hood. The protocol doesn't opine on how observability should work or enforcing that you need to know the interactions. That's really up to the builders and the ecosystem itself.

Building on that, debugging sounds like a nightmare.

Not even composability. Even without composability, it's like, do you guys have best practices on this where now you don't even know you're calling a server that's created by somebody else? Yeah, you'reright. You're calling an API. You don't know what if I call a Stripe API, I don't know exactly what that API does in the end.

I can kind of

based on the interface or how they describe in the docs. But the MCP server, if it's more than just a wrapper on APIs that already exist,

how can you tell? How can you debug

that if you don't actually know what's even going on?

Yeah. So the question is, how do you actually make MCP servers debuggable, especially if it's more than just a wrapper around an API and it's actually doing more complex things? The answer is that the protocol itself doesn't enforce specific observability and interactions.

It's kind of like incentive alignment for the server builder to expose useful data to the client. MCP does, of course, have ways for you to pass metadata between the client and the server. And so if you build a good server that has good debugging and actually provides that data back to the client, you're more likely to be useful and actually have a good UX.

But the protocol itself doesn't kind of enforce that, if that's kind of what you're asking, which I think is the same answer for APIs. People will use your API if it's ergonomic and it's good and it makes sense and provides you debugging and logs.

So we think servers should do that. I think we do have best practices. I don't know off the top of my head. But I can follow up with that.

So I guess somebody already asked this. But for best practices in building MCP servers, this kind of goes into that too. Because now we're just talking about API wrapper. But when you're talking about resources and the problems that have been brought up, there's a whole other layer of things that if something goes wrong, what was the resource that was given?

Was it wrong there? Was the call the wrong tool? It sounds like those are the kind of things that are still developing, the best practices about builders.

That'sright.

Best practices are still emerging. These are emerging practices.

Yeah. I think the answer is we won't get there, either Anthropic or MCP builders themselves or the community will start to converge on best practices. But I agree with you that there needs to be best practices on how to debug and stuff.

This is more of an observation to other architectural patterns. Do you have a microservice architecture or microservices that you have to have a trace and you have to detect what's going on through? It's only when you need that microservice to have reasoning that you're not turning it into an agent.

But I think there are patterns that we've kind of figured out analogous to what we're doing here. It's just like finally we're bringing in, hey, we also want this service to now reason.

That's exactlyright. Yeah. Just comment on this is very similar to microservices, except this time we're bringing in intelligence. But there are patterns that exist that we should be drawing from. Yeah.

So if I make a test to a risk API server, I can get private access potentially. Is there something similar for these MCP servers? In the sense that, let's say you have a web search MCP server. And the LLM says, OK, I only need to tell the LLM, OK, go to Google and do this web search.

But you want to limit, for example, the number of pages. Do you expect that to happen in natural language or

by parameters in addition to the security?

Yeah. The question is, let's say that the client wants some amount of control or influence over the server itself or the tool call, like limit the number of web pages you go and look at. How do you do that?

So yeah, one suggestion is by doing that via the prompt. That's an obvious one that you can do. One thing we're thinking about is something called tool annotations, these extra parameters or metadata that you can surface in addition to the regular tool call or specifying the tool name to influence something like, can you limit the number of tools or limit equals 5?

That's something that the server builder and the tool builder inside that server would have to expose to be invoked by the client. But we're thinking about, at least in the protocol, a couple of standard fields that could help with this.

So one example that comes to mind is maybe the server builder exposes a tool annotation that's read versus write. And so the client actually can now know, hey, is this tool going to take action or is it only just read only?

And I think the opposite, vice versa of that is what you're talking about, where is there a way for the server to expose more parameters for how to control its behavior? Yeah.

So along the lines of the plug-in here, realistically, if you have local traces and logs, how does any row to an MCP tool to help diagnose and troubleshoot itself, or treat its code and its logs and working through the problem?

Yeah. So question on DevX and how to actually look at the logs and actually respond to them. So one shout-out is we have something called Inspector in our repo. And Inspector lets you go look at logs and actually make sure that the connections to servers are making sense.

So definitely check that out. I think your question is, could you build a server that debugs servers? I'm pretty sure that exists. And I've seen it where it goes and looks at the standard IO logs and goes and makes changes to make that work.

I've seen servers that go and set up the desktop config to make this work. So yeah, the answer is definitely you can have loops here. I'll take the last one. And then I'll come back to these at the end.

It's similar to how I've heard your question about the blocked stuff versus authenticator. How do you think about server security? And can we share more config?

Would you do that to the server, the blocked stuff, security?

To me, the next stage here is figuring out what's going on. So should we be able to do everything that's best for the server?

Yeah. The question is around governance and security and who makes the decisions about what a client gets access to. I think a lot of that should be controlled by the server builder. We're going to talk about auth very shortly.

But that's a really big part of it. There should be a default way in the protocol to there is a default way in the protocol to do authorization authentication. And that should be a control layer to the end application that the server is connecting to.

And yeah, I think that's the design principle. It's like you could have not malicious clients, but clients that want to ask you for all the information. And it's the server builder's responsibility to control that flow. Yeah. I'm going to keep going.

And then I'll make sure to get back to questions in just a sec. So I think we basically have covered this. But the combination of sampling and composability, I think, is really exciting for a world with agents, specifically where if I'm an end user talking to my application and chatbot, I can just go talk to that.

And it's an orchestrator agent. That orchestrator agent is a server. And I can reach out to it from my Cloud for Desktop. But it's also an MCP client. And it goes and talks to an analysis agent that's an MCP server, a coding agent, another MCP server, and a research agent as well.

And this is composability. And sampling comes in where I am talking to Claude from Claude for Desktop. And each of these agents and servers here are federating those sampling requests through the layers to get back to my application, which actually controls the interaction with Claude.

So you get these really nice hierarchical well, they will exist. They don't exist yet. But you will get these really nice hierarchical systems of agents. And sometimes these agents are going to live on the public web or they won't be built by you.

But you'll have this way to connect with them while still getting the privacy and security and control that you actually want when you're building these systems. So in a sec, we're about to talk about what's next and registry and discovery.

But this is kind of the vision that I personally really want to see. And I think we're going to get there of this connectivity layer while there's still being guarantees about who has control over the specific interactions in each of these.

OK. I'll get to questions in a sec. I'm just going to keep going. So we've talked about a few things. We've talked about how people are using MCP today. We've talked about how it fits in with agents. But there's a lot of really exciting things that a lot of you have already asked about that are on the roadmap and coming very soon.

So one is remote servers and auth. So let me pause this to say what's going on. So first, this is Inspector. This is the application I was just talking about where it lets you install a server and then see all the kinds of various interactions.

Inspector already actually has auth support. So we added auth to the protocol about two, three weeks ago. We then added to Inspector. It's about to land in all the SDKs. So you should go and check for that as soon as it's available.

But basically, what we're doing here is we provide a URL to an MCP server for Slack. This is happening over SSE, which as opposed to standard IO, SSE is the best way to do remote servers. And so I just give it the link, which is on the left side of the screen there.

And then I hit Connect.

And what happens now is that the server is orchestrating the handoff between the server and Slack. It's doing the actual authentication flow. And the way it's doing that is the protocol now supports OAuth 2.0. And the server deals with the handshake where it's going out to the Slack server, getting a callback URL, giving it to the client.

The client opens that in Chrome. The user goes through the flow and clicks, yeah, this sounds good, Allow. And then the server holds the actual OAuth token itself. And then the server federates the interactions between the user and the Slack application by giving the client a session token for all future interactions.

So the highlight here, and I think this is the number one thing we've heard since day one of launch, is this will enable remotely hosted servers. This means servers that live on a public URL and can be discoverable by people through mechanisms I'll talk about in a sec.

But you don't have to mess with standard IO. You can have the server fully control those interactions, those requests. And they're all happening remotely. The agent and the LLM can live on a completely different system than wherever the server is running.

Maybe the server is an agent if you bring in that composability piece we just talked about. But this, I think, is going to be a big explosion in the number of servers that you see because it removes the DevX friction.

It removes the fact that you, as a user, even don't need to know what MCP is. You don't even need to know how to host it or how to build it. It's just there. It exists like a website exists.

And you just go visit that website. So any questions on remote servers, actually? Because I know a lot of people are interested in this.

When you're using remote protocol, are you also controlling the scope of the client? Can people do an adaptation of it? Say I'd like to increase the level of access that they have sometimes? Is there textual limits here to control the scope?

Yeah. I think the question is, does our support of OAuth also allow for, it sounds like, scope change or.

Again, starting off with basic permissions but allowing people to request elevated permissions and for those to respect that through the server protocol?

Yeah. Elevating from basic to advanced permissions. I think in the first version of it, it does not support it out of the box. But we are definitely interested in evolving our support for auth.

If you have a question, it's really you said that the server then holds the token. I just want to know.

So the question is, isn't it a bad thing that the server holds the actual token? I think if you think about the design principle of the server being the one that actually is closest to the end application of Slack or wherever you want the data to exist, let's say Slack itself builds a public MCP server and decides the way that people should auth into it.

I think Slack will want to control the actual interaction between that server and the Slack application. And then the way that I think the fundamental reason for this is clients and servers don't know anything about each other before they start interacting.

And so giving the server more control over how the interaction with the final application exists, I think, is what allows there to be a separation. Does that kind of make sense?

Is it correct for me to read particular applications about which MCP server is liable to improve, given that the server will own the tokens?

Yes. You should be judicious about what servers you connect to. I think that's true for all web apps today as well.

Or what servers they have access to. But yes, trust of servers is going to be increasingly important, which we'll talk about with the registry in just a sec.

So is the vision for MCP servers to be fully like restful APIs? Or is it too complex? I understand that we could sit on top of the restful API. But is the vision that you don't expose anything of the server like the restful API and it's fully fluent?

Or you want to have both?

Yeah. The question is, how does this fit in with restful APIs? And does it interact? I think MCP is particularly good when there's data transformations or some kind of logic that you want to have on top of just the interaction over rest.

Maybe that means there are certain things that are better for LLMs than they would be for just a regular old client application that's talking to a server. Maybe that's the way that the data is formatted. Maybe that's the amount of context you give back to the model.

You get a request. You get something back from a server. And you say, hey, Claude, these are the five things you need to pay attention to. This is how you should handle this interaction after this. The server is controlling all that logic and surfacing it.

Restful is going to still exist forever. And that's going to be more for those stateless interactions where you're just going back and forth. You just want the data itself. Yeah.

No?

About MCP, one of the things that we've come to conclusion is regressions are tools that change prompt descriptions and a lot of times in the future. When it comes to routing our tools into MCP, how do we kind of think about regressions or evals?

Kind of like Disney-style optimizations so that way our tools are called correctly?

Yeah. The question is, how do we think about regressions as servers change, as tool descriptions change? How do we do evals? So a couple of things. One is we're going to talk about the registry in just a sec.

But this is probably something we talked about with versioning, where you can pin a registry. And as it changes, you should test that new behavior. I think that this doesn't change too much about the evals ecosystem around tools.

You might imagine a lot of the customers that we work with, we help them go and build these frameworks around how their agent talks to tools. And that's what's theright way? When should you be triggering a tool call?

How do you handle the response? These are pre-existing evals that exist or should exist. I think MCP makes it easier for people to build these systems around tool calls. But that doesn't change anything about how robust these evals need to be.

But it does make it easier because you could at least the way I think about it is I have my MCP server 1.0. My builder, my developer, publishes 1.1. And then I just run 1.1 against the exact same evals framework.

And it provides this really nice diff, I guess. But yeah, I don't think it changes too much about the needs of building evals themselves. Yeah, just the ergonomics.

Can I confirm this? This is availableright now. I look at it your roadmap. And it still says that it's on the roadmap.

It's in the draft spec. There's an open PR in the SDKs. So it's like I would say days away. Yeah. It is in Inspector, though. It's fully implemented in there. So check it out. Cool. I want to go to registry because a lot of questions about registry.

So a huge, huge thing that we've seen over the past two months is there is no centralized way to discover and pull in MCP servers. You've probably seen the servers repo that we launched. It's kind of a mess.

There are a bunch that we launched. There are a bunch that our partners launched. And then 1,000 that the community launched. And then a whole bunch of different ecosystems have spun up around this, which is pretty fragmented. And part of the reason is we didn't think it would grow this fast.

And so we weren't quite ready to do that. But what we are working on is an official MCP registry API. This is a unified and hosted metadata service owned by the MCP team itself but built in the open.

That means the schema is in the open. The actual development of this is completely in the open. But it lives on an API that we're owning just for the sake of there being something hosted. And what it allows you to do is have this layer above the various package systems that already exists, where MCP servers already exist and are deployed.

These are things like npm, pypi. We've started to see other ones develop as well around Java and Rust and Go. But the point is a lot of the problems that we've been talking about today, like how do you discover what the protocol for an MCP server is?

Is it standard IO? Is it SSE? Does it live locally on a file that I need to go and build and install? Or does it live at a URL? Who built it? Are they trusted? Was this verified by if Shopify has an official MCP server, did Shopify bless this server?

And so a lot of these problems, I think, are going to be solved with a registry. And we're going to work to make it as easy as possible for folks to port over the entire ecosystem that already exists for MCP servers.

But the point is this is coming. It's going to be great. And we're very excited about it because I think a huge problemright now is discoverability. And people don't know how to find MCP servers. And people don't know how to publish them and where to put them.

So we're very, very excited about this. And the last thing I'll touch on is versioning, which a lot of people are asking about. But you can imagine that this has its own versioning where there's this log of, hey, what's changed between this and this?

Maybe the APIs themselves didn't change. But I added a new tool or I added a new tool description or changed it. And this allows you to capture that within this central ecosystem or metadata service.

When?

When? Soon. It's under development. We're actually working with Block, for example. They're one of the open source folks that we work pretty closely with on MCP. But it's coming. There's a spec. And I've read it.

Will companies be able to host their own registry?

Yeah. So the question is, can companies host their own registry? Yeah. We think of it, I think, kind of like Artifactory, where there's a public one. There's an open registry. You can still obviously do your own. The nice artifact of this as well is there are ecosystems like Cursor or like VS Code where you could hook into if you have an existing application and marketplace that you work with, you just hook into the API as like a second set of servers.

But we are not going to opine on what the UI for that necessarily looks like. We're just providing the data.

Is there a path to putting something in the registry that's not even an NPM or pypod module but just that SSE endpoint?

Yes. Yeah. That's a great point because, yeah, not all of these need to live on NPM. I think, yeah, the answer is yes. Basically, we can just let you put in a URL as long as it's trusted and you provide more metadata.

Oh, sorry. Yeah.

So a question. How are you thinking about this? And I think about maintaining a fleet of 10,000 machines that will be used every day. How are you thinking about

packaging beyond NPM?

When you say execution, do you mean how to actually surface these tools and let them be built? Or can you say more about that?

More like if it's not NPM, if it's not pypod, how do I describe how the tool works? Essentially the Docker element.

Yeah. I mean, it could actually just be Docker. We work really closely with Docker themselves. And they have an exact mirror of that repository, the servers repo. But it's all Docker images. And they've done the whole build system.

So it literally could just be Docker. There's also a world where it's entirely remote servers. Maybe you self-host. And you don't want anyone to deal with building. So you just publish it at a URL as well. Yeah.

What's the extension for you to respect to payments or permission boundaries?

Payments and permission boundaries. So I haven't thought about payments yet. It's not something we're thinking aboutright now. Permission boundaries, what do you mean by that? Does that mean who gets to install or look at one of these servers?

Usually, you want to follow the principle of least privilege.

Now, GitHub does a great job for scope tokens. So you need to be able to kind of trace the permitted governance.

Yeah. It's a good question. I think we've touched on this a bit. And this sounds a little bit separate from the registry API or maybe parallel. Honestly, I think best practices are still emerging. That's the real answer. People are still figuring out theright way to do data governance around this.

So yeah, I don't really have the authoritative answer on this just yet.

Are you thinking about other models or services using their registry? Obviously, if any of it is there a word where Claude recognizes these servers better?

So I think our philosophy or the principle maybe generally about open source is we built it, we launched it, and we want our products to be the world's best MCP clients. But they're not going to be the world's only MCP clients.

And we are totally fine with that. We have and are talking to other foundational model providers. Can't comment on who. But the point is this is open. And we intend for it to be open. And if that creates more competition, that's broadly good.

And I think it's good for users. And it's good for developers. So I think there will be periods of time where Claude and our first-party services and APIs are the best. That might not always be the case. And I think that's fine.

And that's a good thing as well. But yeah, we'll talk to other model companies if they're down.

Just doubling down on that one for the last thing. So is there an advantage to using more models in MCPright now? Or can I just swap in someone else?

There is no specific advantage relating to MCP that requires you to use Claude with MCP. Claude is just better for many reasons. But

that's I mean, it's true. But that's more about Claude is just really good at tool use and agentic work. And that's not about something fundamental with MCP itself, at least for now.

So you mentioned the clients. I'm just wondering if you have any instances where the server is kind of performing sadly.

When I think about it, the application host, the clients, helping the server.

Yeah. The question is, how do we think about servers being more proactive or initiating connections to the client? So there's a lot that we're thinking about here for server-initiated actions. So the simplest one that we can think about that already is supported is server-initiated notifications when a resource changes or the server is maintaining a file or a log list.

And it wants to tell the client, hey, I just made an update to this or a new resource is available. When it comes to sampling, there isn't something in the protocol just yet for the server initiating sampling from scratch, where maybe it makes some decisions on its own.

And it reaches out. That is something we're going to build where the server will say, hey, actually, completely unrelated, you didn't ask me any questions. But I want to start this interaction with you. And it reaches out to the client.

And the client is ready to receive those messages.

The server doesn't have access to the client. I'm just wondering how it would work.

Or is it supposed to happen?

The server reaching out to the client would happen if the system itself decides it needs something deterministically. Maybe it.

Predefined?

Not even predefined. It could be event-driven. It could be it just got a request from a user from some other system, got an API request, and initiates the client thing. Also, if you think about composability, the server could, in theory, also be a client and have its own LLM that it controls.

So that's another reason why it could initiate connections. Yeah.

Yeah. I guess I put the support for both standard IO and SSE where

there will be

guidelines for that. For an existing API, either you could have one that does standard IO and calls the API from your local portal. The server just creates their own SSE MCP portal. Do you have any guidelines for that?

Or

anything else that needs to be done?

Yeah. The question is guidelines between standard IO and SSE. The answer is MCP is transport-agnostic. So the actual behavior and the interactions between the client and server don't matter about the fundamental nature of the underlying transport. That being said, the divide that we've seen so far is local or in-memory communication happens over standard IO.

And remote is going to happen over SSE. And I think that's the pattern that makes most sense. But again, it's transport-agnostic. If you want to build your own transports and support them with MCP, you can easily do that.

Is there some way for clients to communicate without having to go through the language model? Is there some action that we follow that

has to relate on Code for doing that test?

Yeah.

Mostly have big repositories. And then the clients didn't have any issue the last two years. The first call of giving my repositories is 2,000.

Yeah. The question is, does the model have to be in the loop to interact with the server? The answer is no. The server exposes a standard set of APIs. Or that's probably the wrong word to use. But a standard set of functions.

So call tools, list tools, call resources, list resources. The client application can call those deterministically.

If you want two different apps, two different tools to transfer information among them, is there a specific way that this would be fixed? Can it be something like a variable that you say, imagine that the first one is a really big JSON and just gives you a tag?

And then the other MCP is able to get that tag and access that JSON. And the model didn't see that full JSON.

Oh, interesting. Are you talking about server-to-server communication perhaps as well?

So the term would be like, imagine that you have a tool that says give me my repositories. Repositories. One that is close. It's like close all my repositories and give me access. The communication between both tools will have to be fixed through the model.

This one is done.

I see. Yes. Yes.

Long list. And you're passing the second one. I just want to say, well, this is the list. But you just want to have a variable name. So the second one is like, OK, give me the list.

Yeah.

I don't think there's a built-in way in the protocol to do this today. A lot of the interactions do have to go back to the client before it allows the tools to talk to each other. And the main reason for that is servers don't really know that other servers exist for the most part.

That being said, I'm pretty sure it's possible. It's pretty flexible. So I think you could make that happen. It's just not a first-class thing that we support.

Hold on. I think that's quite awesome. My understanding of the model comes from all this idea of JSON tool calls. It takes a schema. The model generates the arguments based on that schema and. There's been this recent research that most folks try to use code generation, generate Python code, which functions will actually execute the tools instead of generating JSON schemas.

So it really sounds like this is a bet that this function calling JSON schemas will evolve. But it has those downsides. And what you just mentioned with this code approach, I generate code that can save the output on a variable.

I don't need to see what the text that we generate can pass into another function or so on. What's your opinion on that kind of thing? So how does this code generation, for example, fit in the model context protocol?

Is this something you considered necessarily?

To be quite honest, I don't know. Or I don't have a strong opinion on this. But yeah, happy to chat with you after, if that makes sense. OK. I'm going to keep going. I want to talk about real quick why registry is amazing besides the reasons of ergonomics and verification, all that stuff we've talked about.

But for agents specifically, an MCP server registry allows you to make agents self-evolving. What that means is you can dynamically discover new capabilities, new data on the fly without having to know anything about those from the time that that agent was initialized or programmed in the first place.

So if you're a user and you have this general coding agent that knows exactly how you work and knows the systems that you usually already have access to and it has a control flow that really works well for you, you say, can you go check my Grafana logs?

I think something's wrong with them. And can you go fix this bug? Let's say the agent wasn't programmed to know that the Grafana server existed. So it's going to go talk to our registry. It's going to do a search for an official verified Grafana server that has access to theright APIs.

And then it's going to install or invoke that server. Maybe it lives on remote over SSE. And then go and do the actual querying and go and fix the bug. So this is a pretty simple example. But the point is, as Barry mentioned in his talk a couple of days ago at this conference, agents are going to become self-evolving by letting them discover and choose their own tools.

And that makes that augmented LLM system that we've talked about even more powerful because you don't have to pre-package these. You don't have to pre-define these. The agent itself will go out and look for them and make itself better.

It gives itself context. And I just want to close that loop because I think that's going to be really powerful. And I'm really excited for that.

I see that that was amazing. Also, the registry.

My client now installed an essentially arbitrary code on my machine. Already thinking about getting some control over some integrator, some enterprise that wants control over what actually happens on the machine.

Yeah.

Especially across clients. Say it's a client problem.

But once you have widespread data about the MCP, you can kind of like, oh my god, it's MCP.

Yeah. So the question is, how do you enforce control over arbitrary servers, arbitrary access? I think the artifactory example is a really common one. You can self-host registries and federate which ones are approved or not approved. You could also, instead of using, let's say, if we had a search API, you could have a whitelist of specific servers and allow there to be a tool in between where that agent has to go through that tool.

And the tool filters which servers it has access to. There's also the concept of verification. We'll, in the registry, figure out how to do this. But allowing there to be an official Shopify server, an official Grafana server, which, of course, helps with this just a little bit.

But largely, it will follow similar things to artifactory and enterprise tools as they exist today.

Interesting.

This is the future. Yeah. Not something that I currently am using. But I don't think it's very far away.

So do you trust agents enough to be something?

I trust agents to do it correctly from a functional perspective. I don't trust yet the servers themselves because there isn't a great registry and all that kind of stuff. But Claude or, again, models are good enough already at deciding which tools to use among hundreds.

So I do trust that part of it. Cool. We're getting close to time. So I'm going to keep going. There's another complement to server discovery that's different from a registry. And that is the concept of a .well-known. On the top here, this is not a real URL.

But let's say Shopify had a .well-known slash mcp.json. And that provided this nice interface for, here's Shopify. We have an MCP endpoint that you should know about. It has the resources and tools capabilities. And you auth with it using OAuth 2.0.

And what that means is, if I'm a user and I talk to my agent and I say, hey, help me go manage my store on shopify.com.

So this is a really nice complement to the registry where the registry is focused on discovery and verification and the ability for people to find tools from scratch. But if you also want to go a top-down approach where you know you want to talk to Shopify or you have an agent that's going and looking around on the internet, it can go and check this .well-known as a verified way of, hey, these tools do exist.

And this is how you use them. And that's really powerful. And a specific thing that I'm particularly excited about is there's a really nice complement to computer use. Anthropic released a computer use model in October. Or just our regular model is a computer use model.

And what it allows you to do is go and click around in these systems and these UIs that it's never seen before that don't have APIs that it can go and interact with. But what if you could have that plus mcp.json?

There's a predefined way for that agent to go and call the APIs that are surfaced by shopify.com. But for the long tail where that doesn't work, it can use computer use. It can click around on the UI. It can go log in.

It can go interact with buttons. And I think the world where those coexist inside one agent is the future. And I think that's something we're thinking about. I'm sure other people are thinking about it as well. And I think MCP is going to be a big part of that.

Cool. I'm going to keep going. And I'll take questions at the end. Actually, this is the last slide. But besides everything that we've talked about today, there's a lot more things that we're thinking about in the medium term.

This is roughly in order of how much we're thinking about itright now. But there's a big discussion this is a bit granular about stateful versus stateless connections. Right now, MCP servers are somewhat stateful. They hold state around the connection between the server and client.

But a lot of folks are interested in these more short-lived connections where the client can disconnect from an MCP server, go offline for a little bit, come back later, and continue the conversation or the request in the same way without having to reprovide data.

So we're working on this idea around maybe that there's a bifurcation between the more basic capabilities where it's the client asking the server for things versus capabilities where the server is asking clients for things. And I think this is going to be really elegant.

But you can imagine for more advanced capabilities like sampling or server-to-client notifications, they use something like SSE, which requires there to be a long-lived connection. But for short-lived things where it's just say, hey, can you help me invoke this tool, maybe that's a more short-lived like HTTP or a regular request that doesn't require a long-lived connection.

Streaming, a big one we're thinking about is how do we stream data and actually have multiple chunks of data arrive at the client from the server over time? How to support that first pass in the protocol? Name spacing, which is also somewhat relevant to agents and registries, as we've been talking about.

Butright now, tools, if you install 10 servers, they have tools of the same name. There is conflict often. And there isn't a great wayright now to separate that other than appending the server plus the tool name before you surface it.

I think the registry is going to help a lot with this. But we also want to kind of allow this to exist first class in the protocol and maybe even allow people to create these logical groups of different tools that are pre-packaged into a really nice package of finance tools that are specific to these finance services that people care about.

And finally, I think someone asked about this over there. But proactive server behavior, elicitation, where the server is either event-driven or has some kind of deterministic system where it decides it needs to go and ask the user for more information or notify them about something.

We're just trying to figure out better patterns for that existing in the protocol.

Cool.

That's my talk. My name is Mahesh. You can reach out. LinkedIn. I don't really use Twitter. But I felt compelled to put it on there. I'm not going to respond to you on Twitter, though. But yeah, thanks so much for listening.

This was really great.