The Future of MCP

[upbeat music] Well, welcome.

Let's get started. This is an MCP application. That's an agent shipping its own interface, not through like a plugin, not through an SDK, not rendered on the fly by the model on the client side, or hard-coded into the product.

That is something that is served over an MCP server, and you can take the server, put it into Claude, you can put it into ChatGPT, you can put it into VS Code, Cursor, and it will just fucking work.

And that, I think, is kinda cool because for doing that, you need something that a lot of things that we're-- want in the ecosystem do not offer. You need semantics.

You need to have both sides, the client and the server, to understand what each side is talking, to understand how you render this, understand that there's a UI coming.

And for that, you need a protocol. And the best part about this, an MCP server doesn't just ship an app or can ship an app, it can also ship tools with it, and so you can interact with it, with the application as a human, and you can have the model interact with it through tools, which is, I

think, a very unique thing that I think we have not explored much just yet. Okay. But let's quickly rewind a little bit from this, what I think is a really cool glimpse into the future of MCP into over a year ago, eighteen months, an eternity in AI life cycle, um, all of this did not exist.

There was just a little spec document, a few SDKs, uh, mostly written by Claude, local only, with little more than just tools. And in that last eighteen or twelve months, you guys have been absolutely crazy building stuff, um, building servers, building, um, and crazy ecosystem around this.

And we on our side have been busy, busy taking this local only thing, added remote capabilities, added centralized authorization, added new primitives like elicitation and tasks, and last but not least, added new experimental features to the protocol like the MCP applications that you've just seen.

And in the meantime, we have reached, I think, a really cool milestone because, again, you-- all of you have been absolutely crazy building, building, and building, of course, luckily with the help of, uh, a bunch of agents.

Um, we're now like at a hundred ten million monthly downloads, and that's just, of course, not us using it in our clients and servers. That's like OpenAI's Agents SDK, it's Google's ADK, it's LangChain, thousands of frameworks and tools that you might have never even heard of it, pulling it as a de- as a dependency, which means there's

one common standard that all of us have at our disposal to speak to each other. Um, just a bit for context, uh, React, one of the most successful, um, uh, open source projects probably of the last decades, took roughly double the amount of time to reach that download volume.

And in the meantime, of course, you all have been building really, really cool servers from like little toy projects of WhatsApp servers and Blender servers, uh, to building SaaS integrations like Linear, Slack, and Notion that are really powering what everyone does every day when they use MCPs.

But most importantly, the vast majority of MCP server most of all of us have built are behind closed doors, uh, connecting company systems to agents, uh, and AI applications.

But I still think this is just the absolute beginning of where we are

because I think twenty twenty-five was all about exploring, and twenty twenty-six is all about putting these agents into production. Because if you really think about, in my mind, twenty twenty-four, we just built a bunch of like demos and showed cool stuff to people, and there was a little bit of a buzz there.

Twenty twenty-five was really all about coding agents. But coding agent, if you really think about, are the most ideal scenario for an agent. It's local, it's verifiable. You can call a compiler.

Like you have a developer who can fix shit if it goes wrong in front of the, in front of the computer. Uh, and you can display a GUI interface, and the user is quite happy.

But I think now with the capabilities of the model increasing, we are going into a new era, which I think this year will be-- we will see the start, where we're not just doing coding agents, we're gonna have general agents that will do real knowledge worker stuff, like things a financial analysis-- uh, analyst wanna do, uh, a

marketing person wanna do, and they need one thing in particular. They don't need a local agent that calls a compiler. What they need is something that could connect to like five SaaS applications and a, and a shared drive because the most important part for them for an agent is connectivity.

And in my mind, connectivity is not one thing. If one-- if someone tells you there's one solution to all your connectivity problem, be it computer use, be it CLIs, be it MCP, they are probably pretty wrong.

Because the right, because the right thing, of course, is that it always means it depends, and there is a real, a big connectivity stack, and there's a right tool for the right job.

And in my mind, there are three major things that you wanna consider building an agent in twenty twenty-six. It's skills, MCP, and of course like CLI or computer use, depending on your use case.

And they have three very distinct things that they can do and three different things you wanna consider when you build your agent. Number one, skills, of course, is just like domain knowledge.

It's just like capture specific capabilities, put into a very simple file, and it's mostly reusable. There are some minor differences between the different platform.

Of course, CLI is very popular when local coding agents. It's an amazing tool-

To get simply started, to have something that you can compose in a bash that you-- that automatically discover, where the model can automatically discover what the CLI is capable of.

And most importantly, if you have things that are like CLIs, like GitHub, Git, and other things that are in pre-training, CLI is an amazing solution for your connectivity part, and they're particularly good when you have a local agent where you can assume a sandbox, where you can assume a code execution environment.

But if you don't have this, if you need rich semantics, when you need a UI that can display long-running tasks, when you can have-- when you need things like resources, when you need to build something that is fully decoupled and needs platform independence, or you don't have a sandbox, when you need things like authorization, governance, policies, or

short to say boring enter- boring but important enterprise stuff, or if you wanna have experiments like MCP applications or what comes soon, skills over MCP, then I think MCP is this, like, additional connective tissue that is just yet another tool in the toolbox for you to build an amazing agent.

And so this is all to say that I think in 2026, we're gonna start building agents that use all of it. They don't use one thing, they use all of it, and they use them quite seamlessly together.

But I don't think we're quite there just yet because we need to build a lot of stuff, partially, um, because our agents kinda still suck, um, and partially because I think we just haven't talked enough about, like, some of the techniques you can do, uh, to really put this connective tissue together.

The number one thing that we need to go and start building is on the client side, on the s- on the agent harness side, on the things that powers the connective parts, that be it a Claude Code, uh, be it a Pi, be it whatever application you're gonna build.

And the number one thing we're gonna do there and what we all have to do and something I wanna really get across today, is that we need to go and start s- building something called progressive discovery.

Most people, when they think about like, oh, uh, MCP, they can think about, like, context load. But if you really consider what a protocol does, a protocol just puts information across a wire, but the client is responsible for dealing with that information.

And what everybody so far has done, because we're in this very early experimentation phase, is to simply put all the tools into the context window and then be quite surprised that maybe the context window gets large.

Um, but what you can do instead, and what you should do instead, you should start using this progressive discovery pattern, which is to say, use something like tool search to defer the loading of the tools and start loading the tools when the model needs it.

And we have this in the Anthropic product, in the API, um, people can use this, uh, on, on competitors' APIs as well. But also you can just build this in yourself, where you just don't load the tool directly, and the moment you give the, you give the model a tool loading tool, basically, and the model goes like,

"Ah, maybe I need a tool now. Let me look up what tools I need." And then you load them on demand.

And here in this example, what you're seeing is on the left side is, uh, Claude Code before we'd added this to Claude Code and then after it, uh, uh, to Claude Code.

So you see a massive reduction in tool, uh, use-- uh, tool context usage. The second part to that is, is something called programmatic tool calling or what other people usually refer to, um, to code mode.

Um, this is the idea that one thing that you really wanna do is you wanna compose things together. You don't want the model to go call a tool, take the result, then go and talk, call another tool, take the result, call another tool.

Because what you're effectively doing is you're letting the model orchestrate things together, and in that orchestration, you're using inference, you're u-- it's, it's latency sensitive, and all of its stuff could be done way more effective if you would instead write

a script. Um, and in fact, that's actually what you constantly do and what you constantly see things like Claude Code do when it writes the bash command. But you can of course do this with everything, and you can do this with MCP, and you should do this with MCP.

So what does this mean? So what you want, instead of having one tool after another, you want to give the model a REPL tool, provide like a com-- like a execution environment like a V8 isolate or a Monty or something like that, or a Lua interpreter, and just have the model write the code for you, and the

model just executes that code and then composes them together. And there's a neat little feat- feature in MCP called structured output that tells you what the return value of the output will be.

And the model can use this information to, uh, to figure out type information, which then mean it can really nicely compose these things together. And in this example here, instead of doing two different calls, you do one call, and you can filter.

The, the model will automatically ex-- uh, remove things from a JSON and just continue.

Of course, if you don't have a structured output, you can always just ask the model to give you a structured output, um, uh, by just extracting it and saying, "Hey, call a cheap model," and say, "I want this expected type.

Give it back to me." And bam, you have a type. The model can compose things together. And I think this is something we're just not doing enough yet, and this is, I think, something where we can improve our agent harnesses.

And then last but not least, of course, you can just compile-- compose these things together with executables, like with CLIs, with other components, with APIs as well.

Um, next, what we need to do, besides the client work, which is progressive discovery and Um, programmatic tool calling, we need to go and start building properly for agents.

And that means we all need to stop taking REST APIs and put them one-to-one into, uh, an MCP server. Every time I see someone building another REST to MCP server, a conversion tool, I'm-- it's a bit cringe because I think it just, it just results in horrible things.

Um, and what you should do instead, you should design for an agent. Or basically, you can start designing for you as a human, how you would wanna interact with this, because that's actually a very, very good start for an agent.

If you wanna orchestrate things together, you should reach, of course, for programmatic tool calling, and you can do this on the client side, as I said before, but you can also do this on the server side.

The Cloudflare MCP server and others like that are great examples how you can have, instead of providing tools, provide an execution environment to the model and then just have them orchestrate things together, which again, cuts on token usages, uh, cuts on latency, uh, and is way more powerful in its composition.

And then last but not least, you should start, and we should start as server authors, to use this rich semantics that MCP offers over alternatives. This means shipping MCP applications.

It means shipping, um, skills over MCP. It means, um, using, uh, things like task and other aspects that the protocol offers that were currently slightly underused, or things like elicitations, things that only MCP can do for you.

And of course, that's all the work you all need to do, and maybe some of our product people need to do. We also need to do a lot of work on MCP itself.

And there's a few things down the line that we're gonna go and have to go and solve. The number one thing is we need to improve the core. There's a few things that as we have developed the protocol over the last year, that are just not in a good shape.

Number one is that the current Streamable HTTP, it's very hard to scale if you're a large hyperscaler. And so we have a proposal from, uh, our friends at Google, um, who are working with something called a stateless transport protocol, which make it significantly easier to just treat MCP servers like, uh, you know, another stateless, uh, REST

server or something like that that we used to know how to deploy to like Cloud Run or Kubernetes and so on. So that's coming down in June and hopefully landing in the SDKs very soon.

In addition, we need to improve our asynchronous task primitive, which basically is a very fancy way to say we just wanna have agent-to-agent communication. We have a very experimental version of the protocol that very few clients support, so we're gonna start building more clients out like that, and most importantly, we are improving some of the little semantics

that we need to do. We're gonna ship a TypeScript version, uh, SDK version two and Python SDK version two based on, um, a lot of the lessons learned, uh, over the last year.

There's a, there's a, um, a, a, a SDK called FastMCP. Uh, who's using FastMCP? Yeah. It's just way fucking better than Python SDK that we're shipping, right? And that's on me because I wrote the Python SDK.

Um, and, and so I have a bunch of people who are way better Python developers than me help me, uh, write it better. Um, the second part is we need to start integrating everywhere.

We're gonna ship for, particularly for enterprises, something called cross-app access. It's a new thing that we're working closely together with identity providers, which just allows you-- It's a very fancy way to say, uh, once you log in once with your local company identity provider, be it a Google, be it an Okta, you will be able to just

use MCP servers without having to re-log in. So it's a bit more smoothness. Um, in addition, we're gonna add something called a server discovery by, um, so by, uh, specifying, uh, how you can discover servers on well-known URLs automatically.

So crawlers, browsers, um, agents can just go to a website and say, "Oh, um, instead of just parsing the website, is there also an MCP server I can use?"

And we will be able to automatically discover this. This is a really cool thing that will come down, uh, also in June when we launch the next specification, uh, and will be supported there.

And then last but not least, we are starting to use our extension mechanisms in, in MCP, which means that some clients will support this, like for example, MCP applications will only be supported by web-based interfaces because if you're a CLI, you just have a hard time rendering HTML, right?

Um, and we'll do more of these extensions. One of the most exciting extensions that I think is, is cool, we're just gonna ship skills over MCP because it's very obvious that if you have a large MCP server with tons and tons of tools, you just wanna ship domain knowledge with it and say, "Oh, this is how

you're supposed to use this. This is how you're supposed to use this." And it allows you as a server author to continuously ship updated skills without having to rely on plugin mechanisms and registries and other stuff.

So that's coming down. Um, there's a lot, a lot of experimentation from people already in that space. You can already do some of that today if you just give the model a load skills tool.

Like you can, you can build primitives of versions of this today without having to rely on the semantics, but of course we're gonna define the semantics. Okay. So that's for me, a long-winded way to think, to say that I think MCP is actually in a really good shape, and I think in this year we're gonna push, uh,

agents to full connectivity. Um, MCP will continue to play a major, major, major role. And we want, of course, your feedback. We are a very open community. We just have created a foundation.

We're mostly running as an open source community with a Discord, with issues. Um, just come to us and tell us where the fuck are we wrong? What are we getting right?

Um, so that we can improve this on a continuous basis. So twenty twenty-six I think is all about connectivity, and the best agents use every available method. They will use computer use, they will use CLIs, they will use MCPs, and they will use, will use skills because they wanna have a wide variety of things they can do,

and then they can ship cool stuff like this, um, which is, um,

one of the product features we shipped recently. Uh, under the hood, it's nothing but an MCP application, um, that renders stuff, right? Cool.

So we can now look at, uh, the model writing graphs.

Anyway, thank you. [upbeat music]