Building (Agents) with Model Context Protocol

[upbeat music] Hey, everyone.

Hello.

Hello. Thank you all for coming. Uh, 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. [laughing]

Thank you very much. So today, we're gonna be talking about MCP, Model Context Protocol. Um, this is more of a talk than a workshop, but I'll do my best to keep it interactive.

If you wanna ask questions, uh, feel free to do so, and I'll do my best to answer them. Um, today we're gonna talk about the philosophy behind MCP and why we at Anthropic thought that it was an important thing to launch and build.

Uh, we're gonna talk about some of the early traction about, uh, o-of MCP in the last couple of months. Um, and then some of the patterns that allow MCP to be adopted for AI applications, for agents, um, 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. Um, this is a, a pretty obvious thing to us now, but I think a year ago, when most AI, uh, assistants or applications were chatbots, uh, you would bring in the context to these chatbots by

copy-pasting or by typing, um, or, uh, 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, uh, systems where the, 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 a, an open protocol that enables seamless, seamless integration between AI apps and agents, and your tools and data sources.

The way to think about MCP, uh, is by first thinking about the protocols and systems that preceded it. APIs became a thing, um, a, a while ago to standardize how web apps interact between the front end and the back end.

It's a, uh, a kind of protocol or layer in between them that allows them to translate requests, uh, 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. Uh, LSP is a big part of our inspiration, um, and it's called Language Server Protocol, and allows an IDE that's LSP compatible to go and, uh, talk to and figure

out the right 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, 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, um, and three interfaces that are part of the protocol, which are prompts, tools, and resources.

So here was the, the land before-- the lay of the land before MCP that Anthropic was seeing. Um, we spend 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 the right way.

One team would, uh, 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 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, um, which is the, the world of an MCP client, and there's some client examples here, like our own first-party applications.

Um, recently, applications like Cursor and Windsurf, uh, 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 the right side, uh, is any, uh, it, it's a wrapper or a, a way of federating access to various systems and tools that are relevant, uh, to, to the AI application.

So it could be a database, um, to query and fetch data and to kind of give the LLM access to, 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, uh, but you want the LLM to have access to it.

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

So we can talk about the, the value that we've seen for different parts of the ecosystem over the, 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 LLMs 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, uh, before MCP, we, 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.

Um, and MCP aims to flatten that and be the layer in between the application developers and the tool and API developers that wanna give LLMs access to these data.

For end users, obviously this leads to more powerful and context-rich AI applications. Um, if you've seen any of the demos on, uh, on Twitter with Cursor and Windsurf, um, even our own first-party applications, you've seen that these systems are, um, uh, 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, uh, 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, um, and deal with the, 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, the vector DB interface and turns it into an MCP server. They can own and maintain and improve that, publish a set of APIs.

Um, 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, 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, uh, different people, different teams can own their specific service, uh, and the entire company and the roadmap can move a lot faster.

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

Um, this, this slide covers a few different personas. Um, but we can start with the, the AI applications and the IDEs. Um, 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. Um, and the agents inside those IDEs go and talk to these external systems, uh, like GitHub, like documentation sites, et cetera.

We've also seen a lot of development on the, the server side. Um, I think to date there are something like eleven hundred community-built servers, uh, that folks have built, um, and published open source.

There are also a bunch of servers built by companies themselves. Just built one as an example. Uh, there are folks like,

uh, and, and a bunch of others that have published official integrations for ways to hook into their systems. There's also a ton of adoption, uh, on the open source, uh, side as well.

So people that are actually contributing to the core protocol and the infrastructure layer around it. So those-

bit about what it actually means to build with MCP and some of the core concepts,

uh, that are part of the protocol itself.

Here's kind of the view of the, the world, uh, of, of how to actually build with MCP. So on the, the left side, you have the MCP client that invokes tools, that queries for resources, and interpolates prompts, um, and, and kind of fills prompts with useful context for, 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, 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, uh, usually the way this works is you'll interpolate various tools into the prompt.

Uh, 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, are kind of, uh, the pos-possibilities are kind of endless. I mean, it's, uh, read tools to retrieve data. It's write tools to go and send data to applications or, or kind of, uh, take actions in various systems.

Uh, it's tools to update databases, to write files on your local file system. Uh, it's kind of anything.

Now we get to, to resources. Um, resources are data exposed to the application, and they're application-controlled. What that means is the server could define, uh, or create images. It could create text files, um, JSON.

Maybe it's keeping track of, you know, 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, some of the use cases we've seen for this are files where the server either, uh, 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, uh, resources manifest as attachments. So we let people, when they're interacting with the server, uh, go and click into our UI and then select a resource, and it gets attached to the chat and optionally sent to the model, uh, for whatever they're--

the, 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 on right now.

Let me automatically attach this to the chat or send it to the model, uh, 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. Um, 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, uh, go and summarize the, the work that I've done so far?" And you just type slash GHPR, uh, you give it the PR ID, and it actually will interpolate this longer prompt that's predefined by Zed inside of the, the MCP server, and it gets sent to the LLM, um, and you generate this really nice full

data structure, uh, or full prompt, uh, that you can then send to the LLM itself. A few other common use cases, uh, that we've seen are different teams have these standardized ways of, uh, let's say, doing document Q&A.

Uh, maybe they have formatting rules. They have, you know, uh, inside of a transcript, they'll have a different speakers and different ways they want the data to be presented.

They can service that or, uh, surface that inside the ser-- uh, 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, they all fit together? Yeah. In the back. [background noise]

Yeah. I, I think we-- A, a big part of MCP-- Sorry. The question is: why aren't resources, uh, modeled in the same way as tools? Why couldn't they have just been tools?

Um, a, a big part of the thinking behind MCP broadly is it's not just about making the model better, it's about actually, uh, defining the ways that the application itself can kind of interact with the, 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, uh, when it wants to put a resource into context.

Maybe that's based on predefined rules. Uh, maybe that's based on it, 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, the model and what should be invoked by the application.

Uh, I saw you go first. Yeah. Glasses.

So, so the first example on the tools is to receive slash server. So vector database and...

Would that be-- Is that protocol super fast compared to just, like, using any tools to connect to Python or something?

Yeah. Um, the question is: are tools the right way to expose, let's say, a vector database to, to model? Um, the answer is kind of up to you. Uh, we think that these are really good to use when it's kind of ambiguous when a tool should be invoked.

Um, so maybe the LLM sometimes should go and call a vector DB. Uh, maybe sometimes it already has the information in context, and sometimes it needs to go talk to, uh, maybe it needs to go ask the user for more information before it does a search.

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

Uh, sorry, sir.

So the, the most things, uh, MCP is able to do, the more important authorization and authentication becomes. How are people dealing with this right now? Like, they just inject them as part of the, one of the parameters?

Or is MCP going to provide some way to connect apps with MCP?

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

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

Call a tool and the tool-

Yeah, I think the-- it sounds like the broader question is: how does MCP fit in with agent frameworks? Um, cool. Yeah, I mean, the answer is they, they kind of complement each other.

Um, 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, uh, if it has this connector to MCP servers, you can expose those servers to the agent, uh, without having to

change your system itself as long as that adapter is installed. So we don't think MCP is gonna replace agent frameworks. Uh, we just think it makes it a lot easier to hook into servers, tools, prompts, and resources, uh, in a standardized way.

Okay. So like answer method. The framework was a tool, and the tool could call MCP. So going forward, many of the tools would just be a wrapper for an MCP call.

Yeah. The, 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. Uh, yeah.

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

But, uh, a lot of the agent framework's value, I think, is in the knowledge management and the, the agentic loop, um, and how the agent actually responds to the data that's brought in by tools.

Um, and so I would think that there is still a lot of value in something where the agent framework defines how the LLM is running in the loop and how it actually, uh, decides when to invoke the tools, uh, and reach out to other, 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, the most clear answer, but, uh, that, that's the one that we've at least seen so far. Uh, 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.

Yes. So for the, the design decision behind that, you think that tools, resources from previous taking all this temporary discussion in, in a state where state comes from a-- from user input and via prompts, they can be immutable.

The resources are all immutable tools because of the requirement. So why do you prefer to use text tools that require resources and prompts? So I mean, for me, just fulfilling, but for you guys, I know that you've thought about this a lot.

Uh.

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.

Um, so I think we, we touched on this a little bit, but, um, there's actually a lot more protocol capabilities built around resources and prompts, uh, 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? Uh, in reality, resources and prompts in MCP can also be dynamic.

They can be interpolated with context that's coming in from, uh, from the, the user or from the application, uh, and then the, 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, 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, the various capabilities the server wants to provide. So it's not just you wanna give a, 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, uh, maybe that's a prompt. Maybe I, uh, you know, I have a, a prompt that's like a five-step plan for how someone should, uh, 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. Um, and so I, 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, that kind of makes sense.

Cool. All right. Um, let's see what this actually looks like. The, 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.

Um, let me try to pause as this goes through. So Claude for Desktop, which is on the left side, an MCP client, and on the right side, I'm working inside of a GitHub application.

Um, 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, uh, the Claude for Desktop app the URL of the, the, uh, 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, 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, uh, and actually pulls-- calls that and, 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, uh, 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 they 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, um, and, and those things interplay with each other.

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

So I've also installed an Asana server and has-- that has, like, thirty 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, as tasks inside Asana.

So this might be a pretty common application that you like to use, but the, the things I wanna 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. Um, primarily it's a way of surfacing tools to the server, and so, uh, it's not a ton of additional logic to build.

I, I would expect they could be built in an hour. Um, 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, uh, Claude for Desktop kind of becomes the central dashboard for how I bring in context from my life, and I actually, like, run my day-to-day. Um, and so inside Anthropic, we've been using things like this a ton to go and reach out to, you know, our, our Git repos to, uh, even make PRs or to bring

in context from PRs, and MCP is the standard layer, uh, across all of those.

Cool. And so just to close that out, um, 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.

Uh, it's their own way of talking to the MCP tools. Um, other applications don't even call them MCP tools. For example, Goose calls them extensions. Um, 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, uh, across all of these applications.

Awesome. So, so far we've talked about, um, 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. Um, and there's a few reasons for this.

One is the, the actual protocol features and the capabilities that we're gonna talk about in just a second. Um, but it's also the, the fact that these agent systems are becoming better, the, the models themselves are becoming better, and they use the data you can bring to them, uh, in increasingly effective ways.

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

So, um, you might be familiar with the, the blog that we put out, uh, my friends Barry and Erik put out a couple months ago called Building Effective Agents.

And one of the core things in the blog, um, that one of the first ideas that was introduced is this idea of an augmented LLM. It's an LLM, uh, in the, the traditional way that it takes inputs, it takes outputs, um, and it, 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. Um, 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, 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. Um, 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, uh, a, a standardized way.

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

built in to start. Um, and, and the, 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, uh, concept running in a loop where the augmented LLM goes and does a task. It kind of works towards some kind of goal. It, uh, 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. Uh, what that means is even if you as an agent builder don't know everything that the agent needs to do from the time-- at the time that you're building it, uh, that's okay.

The, the agent can go and discover these things, uh, 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 it-- 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. Uh, 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.

Um, so I wanna talk about-- a little bit about what this actually looks like in practice. Um, let me switch over to screen sharing my screen.

Cool. So to talk about this, um, we're gonna 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, uh, kind of play in with, uh, MCP. So I'm switching over to my code editor.

I'll make this bigger. And what you see here is a pretty simple application. Um, the entire thing is maybe eighty lines of code. Um, and I'm defining a, a set of agents inside of this Python file.

The, the overall task that I want this agent to achieve is defined in this, uh, this task.md. And, uh, basically, I want it to go and do research about quantum computing.

Uh, 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.

Um, its, its role is to, uh, you know, 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, uh, file system.

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

I did not build any of those MCP servers, um, and I'm just telling it the name, and it's gonna go and invoke them and install them, and making sure-- make sure that the agent actually has access to them.

The next one, similarly, uh, is a fact-checker agent. It's gonna go and verify the information that's coming in from the research agent. Um, and it's using the same tools, Brave, Fetch, and File System.

Um, and these are just MCP servers that I'm giving it access to.

And finally, there's the research report, uh, writer agent, and that actually synthesizes all the data, uh, 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 file system and fetch tools or servers. Um, I don't need it to go look at the internet. I just need it to process all the data, uh, that it has here.

Um, and it knows what servers each of them have access to. And then once I kick it off, the first thing it's gonna do is go and form a plan.

Uh, a plan is just a series of steps for how it should go and interact with all these systems and the various steps you should take, uh, until it can call the task done.

So, as an example, the, the first step, it's gonna go and look at authoritative sources on quantum computing, um, and it's gonna invoke the searcher agent in, in various different ways.

It knows-- Uh, it creates this plan based on the context about the agent's task, about the servers it has access to, uh, and so on. The next step is maybe it goes and verifies that information, uh, 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, uh, 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 just gives, uh, 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 gonna kick this off. Um, and what's gonna be going on in the background is it's gonna start doing some research.

Uh, it's invoking the search tool, uh, the, the search agent, and then it's gonna invoke the fact-checking agent, and you'll t-start to see these outputs, uh, appear on the left side of the screen.

Um, 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 a-- 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. Uh, someone else in the community built them.

Maybe, uh, the, the most authoritative, you know, source of research papers on quantum computing wrote them. Um, but all we're doing is telling our agents to go and, uh, interface with them in a specific way.

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

Cool.

Have you seen people try to adapt something like this to their proprietary data and like their databases and other things like that with some cultural things?

Definitely. Yeah. Um, so the question is, have we seen agent systems, uh, also working for proprietary data? Uh, the really nice thing about MCP, again, is that it's open, and so you can actually run MCP servers, uh, on-- inside your own VPC.

Um, you can run it on top of, uh, on your, your employees', uh, individual systems or laptops themselves. Uh, so the answer is, is definitely yeah.

Yeah.

So, um, just to be a quick question. First of all, you're saying that the

Yeah.

So, uh, the question is, what does it mean to separate, uh, the agent itself and now the capabilities, uh, that other folks, uh, kind of give to it? The- I, I think the answer kind of varies.

Um, some of the ways that we've seen to improve agent systems are, uh, you know, what kind of model do you use? Is it actually the right model for the specific task?

If you're building a coding agent, probably you should use, use Claude. Um, and there's also things like context management or knowledge management. How do you store the, 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, uh, in series? Are they in parallel? And so there's a lot more that you can focus on based on your task, uh, in that sense, as well as, uh, the interface itself.

Like, how is the surface to the user? And the separation is then, uh, maybe you build a bunch of your own MCP servers for your agent that are really, really customized to what you wanna do.

But when you wanna 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.

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

Uh, let's do, yeah, that anyway.

Uh, most of the what we call tools here, like, have directly like one specific function. So we call them tools, but it's like bi-functionals, one thing. Are people building agents on top of agents exposing them as MCP accounts?

I don't know what tools he uses. Like, I give him my inbox. I don't know what happens with it. I know that it gets cleaned up. So are people using MCP in this kind of way, like, only, like, one endpoint as a, as a leverage, that the agent knows what tools it's using under?

Yes. Uh, there's a slide that we'll get to, um, which is exactly that. Um-

I'm sorry if this is-

No, you're good. No, no, that's great. Um, really good questions. Let's-- I'm gonna do this side of the room because I didn't, yeah.

Yeah, um, so I, I don't know what conditions, like, for instance, uh, source of error.

Yeah. Um, not a ton of this is specific to Last Mile. I think it's a really great framework. Um, it's called mcp-agent, and specifically what they worked on is they saw these things come out.

One, 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.

Um, 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, the framework, is, uh, these, these different components or building blocks for building agents. So one is the concept of an agent. Um, 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, uh, in different ways that are more agentic, and those are described in the paper.

But one of the things in the, in the blog post was this orchestrator workflow, uh, 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 to, uh, give it access to these various sub-agents, uh, using all of these nice things that are part of, uh, mcp-agent. That being said, it's open source.

Like, it's not that I'm blessing this is the right way to do it necessarily, but it's a really simple and elegant way of doing it. Uh, sorry, there are a lot.

Yeah. [background noise]

Yeah. Uh, so the question is: How do resources and prompts fit in in this case? Uh, the answer is they don't. Um, th-this example was more focused on the agentic loop than giving tools to them.

I would say resources and prompts come in more where, uh, 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, uh, you know, 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's the, the first step, the second step, the third step," and it's getting that as the server surfaces it to, uh, surfaces the plan to it as, as this kind of format.

Uh, prompts could come in if, um... There, there's a few examples, but you could say, uh, a slash command to summarize all of the steps that have occurred already.

You could say, slash summarize, uh, and there's a predefined prompt inside of the server that says, "Here's the right way to give the user a summary. Here's what you should, uh, provide to the LLM when you go and invoke the summarization prompt."

Uh, so the answer to your question is it doesn't fit in here, but there are ways it could. Yeah. Okay, I'll take, like, two more. Let's go with you.

Uh, does this, uh, introduce any, like, new workflows with, as it relates to, like, evaluations, uh, in, in, in this, uh, in this case? If you're, if you're surfacing a bunch of different tools, uh, is there, um, any sort of like MCP-native way to evaluations to understand if it's choosing the right tool or

just, just plug this into your normal eval process?

I think the answer-- So the question is, how does this fit into evaluations, uh, in particular evals related to, uh, assessing tool calls and, and that's being done the right way?

I think, um, largely it should be the same as it is right now. Um, there is potential to have MCP be even a standard layer inside evals themselves. I, I probably need to think this through, but, uh, you can imagine that, uh, there's an MCP server that surfaces, you know, the, the same five tools, and you give

that server to one set of evals. You also, uh, y-- let's say you have one eval system running somewhere to eval, like, th-these five different use cases, and you 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. Um, but largely, I think it's similar to how it's been done already.

Yeah. Uh, in the white.

I actually approach that same theory. Uh, the first thing is like I'm starting to see the infrastructure side of this. So say that this is a private void as well as, uh, making server that is full permission.

Like, are these tools like as a global server start creating that everybody's interfacing with? Or do you think that is-

Um, I'll get to that.

Okay. One is, I feel like the client and server sort of, like, theory had to be similar. Um, because a lot of the stuff that you showed on the back side, um, how would you say that stuff like, I don't know, authentication, like retry logic, or, or all of that stuff, is that all on the client side,

like with feature frameworks, or does that just go right out? Is that more agent, or is that maybe server side? I think I'm gonna hear on where this is working.

Yeah. Um, I can address part of this. So the, the question is where-- what is the separation between a lot of the, uh, 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. Um, I'll get to auth in a bit, but on things like retry logic, um, I think my personal opinion, and I think this remains to see-- be seen how it shakes out, is a lot of

that should happen on the server side. Um, the server is closer to the end application and to the end system that's actually, uh, 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, uh, 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, uh, know the right ways to do retries.

They shouldn't have to know, you know, how to do logging in the exact way that the server wants, uh, and things like that. So the server is ideally closer to the end application, and, and it's the one that's, uh, the end of service, and it's the one that's implementing a lot of that business logic.

Is that a consequence of kind of, kind of a lot of these agent infrastructure frameworks have a lot less value because most of the logic is structured?

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

Um, like maybe the server builders wanna just focus on exposing their APIs and like letting all the agents do the work. Um,

and yeah, honestly, I don't have a really strong take on that. Yeah.

Um, is there a best practice as to how many agents you can use?

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

Um, in practice, the models of today, I think, are, uh, good up to like fifty or a hundred tools. Like, Claude is good up to a couple hundred in my experience.

Um, but beyond that, I think the, the, the question becomes how do you search through or expose tools in the right way without overwhelming the context window, especially if you have thousands?

Um, and I think there are a few different ways. Like one of the ones that's exciting is a tool to search tools. Um, and so you can imagine a tool abstraction that, uh, implements RAG over tools.

Uh, it implements fuzzy search or keyword search, um, based on, you know, the entire library of tools that's available. Um, that's one way. Um, we've also seen like hierarchical systems of tools.

So maybe you have a group of tools that's, uh, you know, finance tools. You have like read data, then you have a group of tools that's for writing data, and you can, uh, 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. Um, but the answer is there's technically no limit if you implement it the right way.

Okay, uh-

I don't know if you're gonna get into this, but have you-- Is there like a, a methodology or best practice of like, I have an idea, what's the steps I could take, like first define the server, first define my prompts and resources?

Like, are you gonna kind of walk through like a step-by-step process to build this server? Do you have that documented somewhere?

Yeah. I'm, I'm not gonna go through it yet, but, um, we do have that documented. So the question is like, what are the right steps to approach building an MCP server?

What's the order of operations? Um, we actually have this entire docs page that's like, how do you build an MCP server using Claude or using LLMs? Um, all the servers that we launched with in November, um, I think there were like fifteen of them.

I wrote all of those in like forty-five minutes each with Claude. Um, and so it's like really easy to approach it, and I think tools are typically the best way for people to start grokking what a server is, uh, and then going to prompts and resources from there.

Do you have share links to-

Yeah, definitely. I'll share links later. Yeah. In the red.

I guess that begs the question then, uh, but scanning the background-

At what point do we need servers where it's kind of a generic boilerplate model where

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

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

Um-

So that's really should-- We should really not focus here on servers unless there's some special sauce that can't be handled at all.

That being said, I, I think that that works for like the simpler servers, like the ones that are closer to just exposing an API, but there are more complex things that you wanna do.

You'll wanna have logging or, or logic for data transformations. Um, but the answer is yeah, for the more simple ones, I, I think that's a pretty nor-normal workflow. Yeah.

Are you talking to any of GitLabs, Googles,

data that state for them?

Yeah. So the question is, are we talking to the actual owners of the services and the data? Answer is yes. Um, 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. Um, we're also talking to, to bigger folks, um, but I can't speak to that yet.

Are they available to be [door closing]

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

You described the practices you've seen that you've already

in-

Uh, you're asking about versioning as it relates to the protocol or to servers?

Servers.

Yeah. So, uh, the question is, how do we do best practices for versioning? Uh, all these servers are, uh, so far a lot of them are TypeScript packages or on NPM or on PIP.

Um, therefore, they also have version-- package versions associated with them. And so there shouldn't generally be, uh, code-breaking changes. There should be a pretty clear upgrade path. Um, but yeah, I don't think we actually have best practices just yet for what to do when a server itself changes.

Um, for something like-- Uh, I mean, generally, I think it might break the workflow, but I don't think it breaks the application if the server changes since, uh, as long as the, the client and server are both following the MCP protocol, the, the tools that are available might change over time or they might evolve.

Uh, but the model can still invoke those in intelligent ways. For resources and prompts, uh, they, they might break users' workflows if those resources and prompts changes, but, like, they'll still work, um, as long as they're being exposed as part of the MCP protocol with the, the right list tools, call tools, list resources, et cetera.

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

I was thinking more on the, the fuzzy side. If your tool changes, your tool change, then it ends up changing.

Right. Um, I think using versioning, uh, of the packages in-- themselves makes sense for that. And then I'm gonna talk a little bit about a registry, and, uh, having a registry-- MCP registry layer on top of all of this will also help a lot with that.

Yeah. Okay, I'll take one more and then continue. Yeah.

That forms a-- Because we were discussing those extensions, distribution of the server. So I wonder how I think about, especially for people who integrate,

because it's quite important.

Yeah. Question is, how are we thinking about distribution and extension system? I'll get there too.

Yeah.

Cool. Let's, let's keep going. So, um, back to...

So we've talked about one way to build effective agents, and I, I showed how to do that using the mcp-agent framework. Now I wanna talk about the actual protocol capabilities that relate to agents and building agentic systems.

Um, with the caveat that these are capabilities in the, the protocol, but, uh, it's still early days for how people are using these. And so I think a lot of this is gonna evolve, but these are some early ideas.

So one of the most powerful things that's underutilized about MCP is this, uh, paradigm called sampling. Sampling allows an MCP server to request completions, um, AKA LLM inference calls from the client, um, instead of the server itself having to go and implement interaction with an LLM or to go, you know, host an LLM or call Claude.

So what this actually means is, you know, in typical applications, the one that we've talked about so far, it's a client, um, where you talk to it, and then it goes and invokes-

Server, uh, 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."

Uh, 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. They can-- the, the client can own hosting the LLM if it's open source.

They can own, uh, you know, 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, um, model preferences, maybe the server says, "Hey, I actually really want, you know, specifically this version of Claude," uh, or, "I want a big model or a

small model. Uh, do your best to, to get me one of those." Um, the, the server obviously will pass through a system prompt and a, a task prompt to the client, um, and then things like temperature max tokens it can in request.

Uh, the client doesn't have to listen to any of this. The client can say, "Hey, uh, this looks like a malicious call. Like, I'm just not gonna do it."

And, uh, the client has full control over things like privacy, over the, the cost parameters. Maybe it wants to limit the server to, you know, a certain number of requests.

Um, 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 gonna be something where the client has never seen them before.

It, it knows nothing about them, yet it still needs to have some way for that server to request intelligence. Um, and so we're gonna talk about how this builds up a little bit to agents, but just, uh, putting this out there as something you should definitely explore, uh, 'cause 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 we look at this, 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, uh, you know, 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. Uh, maybe it decides it wants to call, you know, the file system server, the fetch server, the web search server.

Um, and it, it goes and, uh, 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, of chaining and of these interactions kind of hopping from the user to a client-server combination to the next client-server combination, uh, and so on.

And so this allows you to build these really nice, complicated or complex architectures, um, of, 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, I'll touch on, uh, agents as well soon. Yeah.

Yeah, quick question. [muffled] How do you think about that structure [muffled]

compounding errors [muffled] issue with it?

Yeah. So the question is: how do you deal with compounding errors if, uh, the system itself is, is complex and multilayered? I think the answer is the same as it is for complex hierarchical like agent systems as well.

Um, I don't think, uh, MCP necessarily makes that more or less difficult. Um, but in particular, um, yeah. In, in particular, uh, I think it's up to each successive layer of the, the agent system to, uh, deal with information, uh, or controlling data as it's structured.

So, like, to be more specific, you know, the, the third node there, the, the kind of the middle client-server node, uh, 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, uh, it needs

to before passing that data to the system right before it. Um, but I don't think that's special to MCP. I think that is true for, uh, all of these like multi-node systems.

Um, it's just this provides like a, a nice interface between each of them. Does that answer your question?

Yeah.

Cool. Sorry, I saw other hands. [muffled]

So if I go to the bottom of the layer, so model, model role is just to give the JSON or the thing is, uh, on top of that, if we are going to contract to solve via MCP, what are [muffled] ultimately, it seems like

any API can be, uh, either, uh, an MCP server, it can be an HTTP server also. What are the benefits for me if I'm hosting an MCP server or just a API as a contract for you?

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

Um, like in, in the system that you're kind of talking about here, uh, it-- I, I think that there's-- there are, there are reasons for a bunch of protocol capabilities like resource notifications, like server-to-client communication, the server requesting, uh, 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. Like, let's say each of these are agents. Like, the first agent can ask the next agent for, you know, a specific set of data.

It goes and does, does a bunch of asynchronous work, talks to the real world, brings it back, and then sends that back to the first client, which, um, that might be multi-step.

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

Let's say Google API or the file system that were MCP or just a content, it will be result with the same, right?

I think that the point I'm trying to make is that, uh, each of these-- So you're, you're asking, like, if, uh, the Google API or the file system things were just APIs, like regular non-MCP servers.

But MC-- Making it an MCP server in this, at least in this case, allows you to capture those as, uh, agents. As in, like, they're more intelligent than just, you know, exposing data to the LLM.

It's like the-- Each of them has autonomy. Um, 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.

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

Yeah.

So in terms of controlling flow-ups or independent groups and, uh, rate limits, is that just handled by the first server you call, or is there a more global way of managing them?

Yeah. Um, kinda depends t- on, on the builders, but I, I do think it's federated, uh, because the LLM is at the application layer. Um, and so that has control over, uh, how random rate limits work or how it should actually interact with the LLM.

Uh, it doesn't have to be that way. Like, in theory, if the server builder, like 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.

Uh, 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 quick follow-up is that supposing we want to pull from the, uh, previous client, right, and it's the last client that wants to pull from the previous client and it wants some user input, would that have to go all the way back?

Uh, if it wants user input, it does have to go all the way back. Yeah.

All the way back.

And MCP does allow you to pass those interactions all the way back and then all the way back forward. Yeah. Um, I'm gonna go on this side first. Yeah.

Um, do you have to elect a primary? Like, I'm zooming out a little bit, but if there's a discrepancy, it's this flat. Like, is there room for a tiebreak?

Uh, yeah. The question is, how do you elect a primary and how you make decisions in network? Uh, the answer is it's kind of up to you. I don't-- I'm not opining on, like, network systems themselves or how, uh, you know, these, these, like, logic-

But it's not a requirement?

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

Okay.

Yeah.

How does observability [in audible] with the file system first [in audible]

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

Um, in theory, for example, like the, the first client application or, or the first MCP server you see there, uh, is kind of a black box. Like, it makes the decisions about if it wants to go invoke other sub-agents or, or other services.

And I think that's just how, like, the internet layer, like APIs work today. Like, 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, the builders and the ecosystem itself.

Just building on that, like, debugging sounds like a nightmare [laughs] where it's like, uh, just-- And, and so-- And not even, not even composability. Even without composability, it's like, uh, how do you-- Do you guys have best practices on this where now you don't even know, like you're calling a server that's created by somebody else?

Uh, yeah, you're right. If you call an API, you don't know what-- If I call a certain API, I don't know exactly what that API is gonna do. Like, uh, you know, based on the interface or how they describe the docs.

Mm-hmm.

Um, but the MCP server, if it's more than just a, like a wrapper on AI-- APIs that already exist, um,

like how can you tell-- how can you debug the kind of,

uh, that if you don't actually know what's even going on [in audible]

Yeah. So the question is, how do you actually make MCP servers debuggable, um, especially if it's more than just a wrapper around an API and it's actually doing more complex things?

The answer is it, uh, the protocol itself doesn't enforce like specific observability and, and interactions. It's kind of like incentive alignment for the server builder to expose useful data to the client.

Um, it-- The MCP does of course, have ways for you to pass metadata, um, between the, the client and the server. And so if you build a good server that has good debugging and, and actually provides that data back to the client, you're more likely to be useful and actually like have a good UX.

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

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

So, so I guess somebody already asked this, but for best practices in building MCP servers, um, this kinda goes into that too, right? 'Cause now we're just talking about API wrapper, but when you're talking about resources and the prompts and the other stuff that you brought up, again, there's a whole lot of other things that, you know,

something goes wrong, okay, was it the res-- what was the resource I was given? Uh, it wasn't there. [door closing] I spelled the wrong tool.

Yeah.

Uh, it sounds like those are the kind of things that they are still developing, like best practices on how to build this.

That's right.

You can't have-- Like, best practices are still emerging. These are emerging practices. It's just too new.

Yeah. I, I think the answer is we will get there, like either Anthropic or like MCP builders themselves or the, 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 a, a, an observation to other architectural patterns that we have. If you have a microservice architecture with lots of microservices that you have to have a trace, and you have the techie that's going all the way through, and it's only when you need that microservice upstream to have reasoning that you're now turning it

into agentic. So I think there are patterns that we have that are 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, that's exactly right. Yeah, just comment on, like, 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. Um, yeah.

So I am like, uh, just refers to a REST API server, I can exhibit parameters potentially. Is there something similar for these MCP servers in the sense that let's say you have like a web search MCP server, and, um, you know, LLM says, "Yeah, uh, maybe you tell the LLM, 'Okay, go to Google and use web search,'

and you want to limit, for example, the number of pages."

Do you expect that to happen in natural language or, um, you know, by parameters and conditions we expect to create limits?

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

How do you do that? So yeah, one suggestion is by doing that via the prompt, like that's an obvious one that you can do. Uh, one thing we're thinking about is something called like tool annotations.

Um, these extra parameters or metadata that you can surface, uh, in addition to the regular tool call or specifying the tool name to influence something like, can you limit the number of tools, uh, or limit equals five.

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

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

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

Yeah.

So when, um, along the lines of debugging here, realistically, you have local traces, you have logs. Um, has anyone wrote a, a MCP tool to help diagnose control chains of retrieval code and logs and, uh, looking through the problem?

Yeah. So question on, like, on DevX and how to actually, you know, look at the logs and actually respond to them. So one, um, 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, uh, 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 make changes to, to make that work.

Um, 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, uh, and then I'll come back to these at the end.

Okay. So this is not what [inaudible] It's similar to how a person would look at a server as asking for guidance. How do you think about like, uh, server security and, um, accounts that won't talk to you because you might be spam or something.

What do you think that server logs itself, uh, security information? Because [inaudible]

to be the next stage of this, I figure accounts.

But should be able to do everything [inaudible]

Yeah. The question is around governance and security and who makes the decisions about what a client gets access to. Um, I think a lot of that should be controlled by the server builder.

Um, we're, we're gonna talk about Auth very shortly, but that's a really big part of it. Like, uh, there should be a default way in the protocol to-- There, there is a default way in the protocol to do authorization authentication.

Um, and that should be a control layer to the end application that the server is connecting to. Um, and yeah, I think that's the design principle is like you could have not malicious clients, but clients that wanna ask you for all the information, and it's the server builder's responsibility to control that flow.

Yeah. I'm gonna keep going, and then I'll make sure to get back to questions in just a sec. Um, so I think we basically have covered this, but the com-combination of sampling and composability, um, I think is really exciting for a world with agents.

Um, specifically where if I'm an end user talking to my application and chatbot, uh, I can just go talk to that, and it's a orchestrator agent. That orchestrator agent is a server, and I can reach out to it from my Claude 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 the-- this is composability, and sampling comes in where I am talking to Claude from Claude for Desktop, and the-- 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. Um, so you get these really nice hier-- 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 gonna live, you know, 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.

Um, so in a sec, we're, we're about to talk about, uh, what's next and registry and discovery. Um, but this is kind of the vision that I personally really wanna see, and I think we're gonna get there, um, of this, like, connectivity layer while there are still being guarantees about who has control over the specific interactions in

each of these. Okay. I'll, I'll get to questions in, in a sec. I'm just gonna keep going. So we've talked about a few things. We've talked about how people are using MCP today.

Um, we've talked about how it fits in with agents. Um, there's a lot of really exciting things that a lot of you have already asked about, uh, that are on the roadmap and coming very soon.

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

Uh, Inspector already actually has auth support. So we added auth to the protocol about, uh, two, three weeks ago. We then added to Inspector. It's about to land in all the SDKs, uh, so you should go and, 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. Um, this is happening over SSE, which, uh, as opposed to standard IO, SSE is the, the best way to do remote servers.

Um, and so I just give it the link, uh, 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, uh, 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, in Chrome. The user goes through the flow and clicks, "Yeah, this sounds good. Allow." Uh, and then the server holds the actual, uh, OAuth token itself.

Um, and then the server, uh, federates the interactions between the user and, and the Slack application by giving the client a session token for all future interactions. Um, 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, um, 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, the agent and the LLM can live on a completely different system than wherever the server is running.

Uh, maybe the server is an agent if you bring in that composability pie-piece we just talked about. Um, but this, I think, is gonna be a big, like, 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 n-need to know what MCP is. You don't even need to know, you 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. Cool. So any questions on remote servers actually? 'Cause I know a lot of people are interested in this.

Uh, when you're using the auth protocol, are you also controlling the scope of

Yeah.

People do an adaptation of it. Um, say like to increase the level of access that they have sometimes. So like is there textual limits here to control the scope?

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

A-a-again, starting off with basic permissions, but allowing people to request elevated permissions-

Yeah.

And for those to be respected through the server protocol.

Yeah. Um, like 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.

Thank you.

Yeah.

I'm not sure if this is true. But you said that the server then holds the token. I just want to know if it's

So, uh, the question is, uh, 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, like let's say Slack itself, uh, builds a public

MCP server and decide-- decides the way that people should auth into it, uh, I think Slack will want to control the actual interaction between that server and the Slack application.

Um, and then the, the way that-- I, I think the fundamental reason for this is clients and servers don't know anything about each other before they start interacting. Um, and so giving the server more control over how the interaction with the final application exists, um, I think is what allows there to be a separation.

Does that kinda make sense?

Um, yeah. I mean, I guess is it correct for me to be particular about which MCP servers I auth through given that the server will own the tokens?

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

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

So is the vision for, uh, servers to be like RESTful APIs, um, or is it to complement? Like I understand that we could sit on top of the RESTful API, but is the vision that you don't expose anything on the server

like a RESTful API and it's focused with what you want to like have built?

Yeah. The question is: how does this fit in with RESTful APIs, and does it interact? I think, uh, MCP is particularly good when there's, uh- I don't know, data transformations or some kind of logic that you wanna have on top of just the, the interaction over REST.

Um, 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. Uh, maybe that's the way that the data is formatted.

Maybe that's the amount of context you give back to the model. Um, you get a request, uh, you, you get something back from a server, and you say, "Hey, Claude, like, 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 gonna still exist forever, and that's gonna be more for those stateless interactions where you're just going back and forth.

You just want the data itself. Yeah. Noah?

About MCP, one of the things that like when it comes to things like regressions on our tools here, um, they like change like prompt descriptions or

Mm-hmm. [background noise]

when it comes to wrapping our tools into MCP, how do we kind of think about regressions for evals? How do like, you know, like DSPy-style optimizations so that way our tools are called correctly?

Like how complex [background noise]

Yeah. Um, the question is: how do we think about regressions as servers change, as tool descriptions change? How do we do evals? Um, so a couple of things. One is we're gonna talk about the registry in just a sec, but I, I-- 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. Um, I think that this doesn't change too much about the evals, evals ecosystem around tools. Um, you might imagine, like 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, you know, what's the

right way? What-- When should you be triggering a tool call? How do you handle the response? Um, these are preexisting evals that exist or should exist. Um, 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.

Um, but it does make it easier, right? Because you could, at, at least the way I think about it is like I have my MCP server one point O, my builder, my developer publishes one point one, and then I just run one point one against the exact same evals framework, and it provides this really nice like diff,

I guess. Um, yeah, I don't think it changes too much about the needs of, of building evals themselves. Yeah, just the ergonomics.

Hey, can I confirm, is this available right now? I looked at your roadmap, and it still says that it's on the roadmap.

Um, it's in the draft spec. It's in-- There's an open PR in the SDKs, so it's like, I would say days away. [background noise]

Yeah. Uh, it is in Inspector, though. It's like fully implemented in there, so check it out. Cool. I wanna go to registry because, uh, a lot of questions about registry.

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

Uh, it's kind of a mess. Um, there, there are like a bunch that we launched, there are a bunch that our partners launched, uh, and then like one thousand that the community launched, and then a whole bunch of different ecosystems have spun up around this, um, which is pretty fragmented.

And part of the reason is like we didn't think it would grow this fast, um, and so we weren't quite ready to, to do that. But what we are working on is an official MCP registry API.

This is a unified and hosted metadata service, uh, owned by the MCP team itself, but built in the, the open. Um, that, that means the schema's in the open.

The actual, uh, development of this is completely in the open, uh, but it lives on an API that we're, 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, uh, PyPi.

Um, we've started to see other ones, uh, uh, develop as well around Java and Rust and Go. But the, the point is, a lot of the problems that we've been talking today-- talking about today, like, uh, you know, 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?

Uh, who built it? Are they trusted? Uh, was this verified by, you know, if Shopify has an official MCP server, did Shopify bless this server? Um, and so a lot of these problems, I think, are gonna be solved with a registry.

Um, and we're, we're gonna work to make it as easy as possible for folks to port over the e-entire ecosystem that already exists for MCP servers. Uh, but the point is, this is coming, uh, it's gonna be great, and we're very excited about it because I think a huge problem right now is discoverability, and people don't know

how to find MCP servers, and people don't know how to publish them, uh, and, and where to put them. Um, so we're very, very excited about this. And the last thing I'll touch on is, is versioning, uh, 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? Like, uh, maybe the, the APIs themselves didn't change, but I added a new tool, or I added a new tool description or changed it, uh, and this allows you to capture that within this central ecosystem or,

uh, metadata service.

When [background noise]

When? Um, soon. I, I-- It's under development. We're actually working with, uh, Block, for example. Like, they're one of the open source folks that we work pretty closely with on MCP.

Um, but it's coming. There's a spec, and I've, I've read it. [background noise]

Yeah. So 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, there's an open registry.

You can still obviously do your own. Um, the nice artifact of this as well is, uh, there are ecosystems like Cursor or like VS Code, uh, 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 gonna opine on what the UI for that necessarily looks like. We're just providing the data.

To, uh, putting something in the registry that's not even an NPM or Python module, it's just that SSE endpoint?

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

Oh, sorry. Yeah.

Similar question. How do you think about, uh, like, not like this, and I think about maintaining a fleet of ten thousand machines that

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

More like, you know, if it's not integrated, it's not backed by, how, how do I try out the tool?

As essentially the Docker image.

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

Uh, so it literally could just be Docker. Um, there's also a world where it's entirely remote servers. Like, maybe you self-host, and you don't want anyone to deal with building, uh, so you just publish it at a URL as well.

Yeah.

What's your extension for you considering that there's payments or permission boundaries?

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

Usually, you wanna follow the principle of least privilege.

You know, Dropbox does a great job of scopes, okay? It's not everyone. So we, you know, we kinda trace the core data governance [door closing] of the seed developer.

But when you bring up data governance, that's the first time I just wanna make a decision.

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, like, maybe parallel. Um, honestly, I, I think best practices are still emerging.

That, that's the real answer. Like, people are still figuring out the right way to do data governance around this. Um, so yeah, I don't really have, like, a-- like, the authoritative answer on this just yet.

What do you think about other model, uh, production services using their, uh, registry? Because they can obviously opinionate it. Like, do you know where, where like Claude recognizes these servers better than other models?

Or can everybody talk about other models?

Um, so I think our philosophy or, like, 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 gonna be the world's only MCP clients, and we are totally fine with that.

Uh, we have and are talking to other foundational model providers. Can't comment on, like, who, but, uh, the, the point is this is open, and we intend for it to be open, and if that creates more competition, um, that's broadly good, and I think it's good for users, and it's good for developers.

Um, so I think there will be periods of time where Claude and our first-party services and APIs are the best. Uh, that might always-- not always be the case, and I think that's, that's fine, and that's a good thing as well.

But, um, yeah, we'll, we'll talk to other model companies if they're down.

Um, just doubling down on that one for the last one. What-- So is there an advantage to using your models in MCP right now? Or is there-- Can I just swap in someone else, and it's not really

Uh, there is no specific advantage rela-relating to MCP, uh, that requires you to use Claude with MCP. Claude is just better for many reasons, but, like- [laughing] That's--

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

Um, so you mentioned, like, uh, the client is the great client. I'm just wondering if you have any instances where the server is kind of performing some action on the client.

Um, when I think about it, it seems like the application code of the client is calling the server, but that's actually-

Yeah. Um, the question is, like, how do we think about servers being more proactive or initiating connections to the client? So, uh, there's a lot that we're thinking about here for server-initiated actions.

So the simplest one that we can think about, uh, 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, uh, a new resource is available.

Um, when it comes to sampling, there isn't something in the protocol just yet for the server initiating sampling from scratch, um, where maybe it, it makes some decisions on its own, and it's-- it reaches out.

Uh, that's-- that is something we're going to build, um, where the server will say, "Hey, actually, like, completely unrelated, like, you didn't ask me any questions, but I wanna start this interaction with you," um, and it reaches out to the client, and the client is ready to receive those messages.

Follow-up is, like, the server can have access to the client. I'm just wondering how it would,

like, call, or is it supposed to have it?

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

Predefined.

Not, not even predefined. It could be event-driven. It could be like it just got a request from a user from o-- some other system, got an API request, and it initiates the client thing.

Uh, also, if you think about composability, the server could, in theory, also be a client and have its own LLM that it controls. Uh, so that's another reason why it could initiate connections.

Yeah.

There will be like a practical guidelines. If that was for an existing API, like either you could have one that does standard IO calls the API from your local server, just creates their own like SSE MCP server.

I mean, do you have any guidelines for that or-

Yeah. The question is guidelines, uh, between standard IO and SSE. The answer is like MCP is transport agnostic. Um, so the actual like behavior and the interactions between the client and server don't matter about, uh, you know, the, the fundamental nature of like 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 gonna happen over SSE. Um, and I think that's the pattern that makes most sense.

But, uh, again, it's, it's transport agnostic. If you wanna build your own transports, uh, and support them with MCP, you can easily do that.

We add some way for clients to communicate without having to go through the agent's model. There are so much that we could do,

uh, to rely on, um, Claude, uh, for doing that task.

Yeah.

Most we have read all the repositories and then the ones that we have been using the last two years.

Yeah.

Uh, the first call of giving my, uh, average employees, it is like two thousand times.

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

So call tools, list tools, call resources, list resources. Um, the, the client application can call those deterministically. Um-

But if you want like two different apps, like two different tools to transfer information remotely, there's this way that this would text. And it is something like a firewall that it's like, imagine like the first one is a pretty big JSON and just gives you a tap.

And then the other MCP is able to get that tap and access the JSON, and the model doesn't even see the full JSON.

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

Um, so that would be like, imagine that you have a tool that says like, give me my cost structure.

Mm.

One that is like global. It's like close all my cost structure. The, the, the communication between the both tools will have to read the text through the model.

Mm.

This one is done.

I see. Yes, yes.

Long list, and it will pass it to the second one. I just want to say like, well, this is the list, but we just want to have a firewall next year.

So the second one is like, okay, give me the list.

Yeah.

And that's what we think they want.

I don't think there's a built-in way in the protocol to do this today. Um, 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. Uh, that being said, I-- pretty sure it's possible, like it's pretty flexible, so I, I think you could make that happen.

It's just not like a first-class thing that we support.

Follow-up, I think that it's quite also, um, my understanding of the model comes with the-- due to this idea of JSON tool calls. It takes the schema, the model generates the arguments based on that schema, and then

Mm-hmm.

And, um, there's been like this recent research that involves trying to use like code generation to generate Python code, which is like functions will actually execute the code instead of, um, generating new JSON schema.

So to me, it sounds like there's, there's a bet that like this function calling JSON schemas will evolve, but it has those downsides like what, what you just mentioned.

Um, with like this code approach, I generate code that can save the output in a variable. I don't need to see all the text in each and every-- can pass it to another function and so on.

So, um, what's your opinion on, on that kind of things? How does this code generation, for example, fit in the model-conscious召 code versus some tools to the MCP?

To be quite honest, I don't know or like I, I don't have a strong opinion on this. Um, but yeah, happy to chat with you after.

Yeah.

If that makes sense. Okay, I'm gonna keep going. Um, I wanna talk about real quick why registry is, is amazing, um, besides the reasons of ergonomics and verification, all that stuff we've talked about.

But for agents specifically, uh, 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 act- 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?

Uh, I think something's wrong with them, and can you go fix this bug?" Uh, let's say the agent wasn't programmed to know that the Grafana, uh, server existed. So it's gonna go talk to our registry.

It's gonna do a search for an official verified Grafana server, uh, that has access to the right APIs. Uh, and then it's gonna install or invoke that server. Maybe it lives on, uh, remote over SSE.

Uh, and then go and do the actual querying and go and fix, fix the bug. Um, 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 gonna 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 prepackage these. You don't have to predefine these. The agent itself will go out and look for them and make itself better.

It gives itself context. Um, and I just wanna close that loop because I think that's gonna be really powerful, and, and I'm really excited for that.

When I see that, that looks amazing. Also, the registry, I think people think about that.

My client now installed an essentially arbitrary code on my machine. How are you thinking about getting some control of some integrated, some enterprise systems control over what actually happens on the machine?

Yeah.

Especially to the cross-client, right? Say it's a client problem.

I want to kind of vice versa. I guess I'll come next. Peter can comment on my thoughts and something you found.

Yes. The question is: How do you enforce control over arbitrary servers, arbitrary access? I think the Artifactory example is a really common one. Like, you'll-- You can self-host registries and federate which ones are approved or not approved.

Um, 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, uh, where that agent has to go through that tool, and the tool filters which servers it has access to.

Um, there's also the concept of verification, uh, like we'll, in the registry, figure out how to do this, but, uh, allowing there to be an official Shopify server, an official Grafana server, um, which of course helps with this just a little bit.

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

State. Digital theme parks are becoming common.

This?

Yeah.

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

Do you think we've, uh, trust agents enough yet?

I trust agents to do it correctly from a functional perspective. I don't trust yet, like, the, the servers themselves because there isn't, like, a great registry and all that kind of stuff.

But the Claw-- or, like, again, uh, models are, are good enough already at, like, deciding which tools to use among hundreds. Uh, so I do trust that part of it.

Cool. Um, we're getting close to time, so I'm gonna keep going. There's another complement to server discovery, uh, that's different from a registry, and that is the concept of a .well-known.

Um, on the top here, this is not a real URL, but let's say Shopify had a .well-known/mcp.json, and that provided this, this nice interface for, you know, "Here's Shopify.

We have an MCP endpoint that you should know about." Uh, it has the resources and tools capabilities, and you auth with it, uh, 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."

And 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 wanna go with top-down approach, where you know you wanna talk to Shopify or you, uh, have an agent that's going and looking around on the internet, um, it can go and check this, uh, .well-known as a verified way of, "Hey, these tools do exist, and, uh, this is how you use them," and, 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. Um, Anthropic released computer use model in October, uh, 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.

Um, I'm sure other people are thinking about it as well, and I think MCP is gonna be a, a big part of that.

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

Um, this is roughly in order of, uh, how much we're thinking about it right now. But, uh, there's a big discussion, this is a bit granular, about stateful versus stateless connections.

Right now, MCP servers are somewhat stateful. They, they hold state around the connection between the server and client. Uh, 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, or the request, uh, i-in

the same way without having to re-provide data. So we're working on this, um, idea around maybe that there's a bifurcation between the more basic capabilities, where it's the client asking the server for things, versus, uh, capabilities where the server is asking clients for things.

And, uh, I think this is gonna be really elegant, but, uh, 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?" Uh, maybe that's a, a more short-lived like HTTP or a regular request that doesn't require a long-lived connection.

Streaming, big one we're thinking about, is, um, how do we stream data and actually have, like, chunk-- multiple chunks of data arrive at the client from the server over time, uh, how to f- uh, support that first class in the protocol.

Namespacing, uh, which is also somewhat relevant to agents and, and registries as we've been talking about. But right now, tools, if you install ten servers, they have tools of the same name.

There is conflict, uh, often, and, like, there isn't a great way right now to separate that other than, like, appending the server plus the tool name before you surface it.

I think the registry is gonna help a lot with this, but we also wanna f- uh, kind of allow this to exist first class in the protocol, uh, and maybe even allow people to create these, like, logical groups of different tools that are prepackaged into, uh, a really nice, like, package of, I don't know, finance tools that

are specific to these finance services that people care about. Uh, and finally, I think someone asked about this over there, but, uh, proactive server behavior, uh, 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.

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

Okay. One minute left today.

Cool. That's my talk. Uh, my name is Mahesh. Uh, you can reach out at [REDACTED:email_address], LinkedIn. I don't really use Twitter, but I felt compelled to put it on there.

I'm not gonna respond to you on Twitter, though. Um- [laughs] But yeah. Thanks so much for listening. This was really great. [applause] [upbeat music]