- MCP (Multi-Modal Communication Protocol) is rapidly establishing itself as a crucial standard for AI agent connectivity, enabling diverse applications and sophisticated tool interactions.
- Future agents will be "fully connected" by seamlessly integrating skills, CLI/computer use, and MCP to handle complex tasks across various systems.
- Key techniques for building advanced agents include Progressive Discovery to manage context window bloat and Programmatic Tool Calling for efficient orchestration of multiple tools through code.
The Future of MCP — David Soria Parra, Anthropic
- MCP applications allow agents to ship their own interfaces, enabling both human and model interaction through integrated tools.
- The MCP ecosystem has grown significantly, reaching 110 million monthly downloads, solidifying its role as a common standard for AI agents across various frameworks.
- Agent development is shifting towards "full connectivity" in 2026, where agents will utilize a combination of skills, CLI/computer use, and MCP to connect to various SaaS applications and shared drives.
- Implement "Progressive Discovery" in agent harnesses to reduce context window usage by deferring tool loading and dynamically searching for tools only when the model needs them.
- Leverage "Programmatic Tool Calling" by providing agents with a REPL environment to write and execute code, allowing them to compose and orchestrate multiple tool actions more efficiently than sequential individual calls.
- When designing MCP servers, prioritize an agent-centric design by providing execution environments and rich semantics rather than simply converting REST APIs one-to-one.
- Utilize MCP's unique "rich semantics," including features like MCP applications, skills over MCP, tasks, and elicitations, which offer capabilities beyond simpler communication protocols.
- Upcoming MCP improvements include a stateless transport protocol for better scalability, enhanced asynchronous task primitives for agent-to-agent communication, and new SDK versions.
MCP (Multi-Modal Communication Protocol) — A protocol designed for AI agents to communicate, share tools, and interact with various systems and interfaces.
MCP application — An agent that ships its own user interface, served via an MCP server, allowing direct user interaction.
SDK (Software Development Kit) — A set of tools, libraries, and documentation that developers use to create applications for a specific platform or system.
Agent harness — The client-side component or framework that powers and orchestrates an AI agent's connective parts and tool interactions.
Progressive Discovery — A technique for AI agents to manage context by deferring the loading of tools and only retrieving them when the model explicitly needs them, often via a tool search mechanism.
Context window — The limited input size for a language model, which can become bloated if too many tools or too much information is loaded simultaneously.
Programmatic Tool Calling — An approach where an agent writes and executes code (e.g., in a REPL environment) to compose and orchestrate multiple tool calls, rather than making individual sequential calls.
REPL (Read-Eval-Print Loop) — An interactive programming environment that takes single user inputs, executes them, and returns the result, often used for scripting.
Rich semantics — Advanced features and structured information offered by a protocol (like MCP) that enable more sophisticated interactions and capabilities beyond basic data exchange.
Stateless transport protocol — A communication protocol design where each request from a client to a server contains all the information needed to understand the request, without relying on any stored session information on the server.
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 chat chat, you can put it into VS Code, cursor, and it will just fucking work. And that, I think it's kind of 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 some analytics. You need to have both sides to client and the server to understand what each side is talking to understand how your render is, 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 chip an app, or can chip an app, it can also chip 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, 18 months, an eternity in AI lifecycle, all of this did not exist. There was just a little spec document, a few SDKs, mostly written by Klott, local only, with little more than just tools. It in that last 18 or 12 months, you guys have been absolutely crazy building stuff, building servers building, and crazy ecosystem around this, and we on our side have been 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 have just seen. And in the meantime, we have reached, I think, a really cool milestone, because, again, all of you have been absolutely crazy building, and building, and building, of course, luckily with the help of a bunch of agents. We're now at 110 million monthly downloads, and that's just, of course, not us using it in our clients and servers, that's like open AI's agents SDK, that's Google's ADC, that's Langshane, thousands of frameworks and tools that you might have never ever heard of it, pulling it as a dependency, which means there's one common standard that all of us have at our disposal to speak to each other. Just a bit for context, React, one of the most successful 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've all been building really, really cool servers from like little toy projects of WhatsApp servers and blender servers to building SaaS integrations like linear Slack and notions that are really powering what everyone does every day when they use MCPs, but most importantly, the vast majority of MCPs server, most of all of us have built or behind closed doors, connecting company systems to agents in AI applications. But I still think this is just the absolute beginning of where we are, because I think 2025 was all about exploring in 2026, is all about putting these agents into production. Because if you really think about, in my mind, 2024, we just build a bunch of demos and show cool stuff to people, and there was a little bit of a buzz there. 2025 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 very viable, you can call a compiler, like you have a developer who can fix shit if it goes wrong in front of the computer, and you can display a tool 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 this start, where we're not just doing coding agents, we're going to have general agents that will do real knowledge work or stuff, like things of financial analysis, analysts want to do, a marketing person want to do, and they need one thing in particular. They don't need a local agent that calls a compiler, but what they need is something that could connect to like five SAS applications 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 someone tells you there's one solution to all your connectivity problem, be it computer use, be it CLI, be it MCP, they are probably pretty wrong, because the right thing of course is that it always means it depends, and there's a real big connectivity stack, and there's a right tool for the right job. And in my mind, there are three major things that you want to consider building an agent in 2026. It's skills, MCP, and of course CLI, or computer use, depending on the use case. And they have three very distinct things that they can do, and three different things you want to 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 most irreducible, 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 close 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 CLI's, like GitHub, Git, and other things that are in pre-training, CLI is an amazing solution for your connectivity part, and they are 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 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, end up boring, but important enterprise stuff, or if you want to have experiments like MCP applications, or what comes soon, skills over MCP, then I think MCP is just like additional connective tissue that's 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 going to 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 because our agents kind of still suck, and partially because I think we just haven't talked enough about like some of the techniques you can do to really put this connective tissue together. The number one thing that we need to go and start building is on the client's, on the agent harness side, on the things that powers the connective parts that be it a Claude Code, be it a pie, be it whatever application you're going to build. And the number one thing we're going to do there, and what we all have to do, and something I want to really get across today, is that we need to go and start building something called progressive discovery. Most people when they think about like, oh, I'm C.P., they can't think about like context bloat. But if you really consider what a protocol does, the protocol just puts information across the wire, but the client is responsible for dealing with that information. And what everybody so far has done, because we 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. 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, and the API, and people can use this 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 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 Claude Code, before we added this to Claude Code, and then after it to Claude Code. So you see a massive reduction in tool context usage. The second part of that is something called programmatic tool calling, or what other people usually refer to code mode. This is the idea that one thing that you really want to do, is you want to 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 effectively doing is you're letting the model orchestrate things together, and in that orchestration you're using inference, it's latency sensitive, and all of its stuff could be done way more effective, if you would instead write a script. And in fact, that's actually what you constantly do, and what you constantly see, things like Claude Code do, when it's writes the bash command. But you can of course do this with everything, and you can do this with mtp, and you should do this with mtp. So what does this mean? So what you want instead of having one tool at another, you want to give the model a repel tool, provide 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 neatly feature, an mtp-code structured output, that tells you what the return value of the mtp-code, of the output will be. And the model can use this information to figure out type information, which then means it can really nicely compose these things together. And in this example here, instead of doing tool different calls, you do one call, and you can filter, the model will automatically remove things from Jason, 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, by just extracting it and saying, hey, call us 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 something where we can improve our agent harnesses. And then last but not least, of course you can just compose these things together with executables, like with CLIs, with other components, with APIs as well. Next, what we need to do, besides the client work, which is progressive discovery and 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 an MCP server. Every time I see someone building another rest to MCP server, a conversion tool, it's a bit cringed because I think it just results in horrible things. And what you should do instead, you should design for an agent. Basically, you can start designing for you as a human, how you would want to interact with this, because that's actually a very, very good start for an agent. If you want to 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. And the CloudFlem.mpcP 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 usage, cuts on latency, 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 skills over MCP. It means using things like tasks and other aspects that the protocol offers that we're 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 going to 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 hyper-scaler. And so we have a proposal from our friends at Google who are working with something called a stateless transport protocol, which make it significantly easier to just treat MCP servers like another stateless rest server, something like that, that we're used to know how to deploy to Claude runs or Kubernetes and so on. So that's coming down in June and hopefully lining 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 want to have agent to agent communication. We have a very experimental version of the protocol that very few clients support. So we're going to 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 going to ship a TypeScript version SDK version two and Python SDK version two, based on a lot of the lessons learned over the last year. There's a SDK called FastMCP. Who's using FastMCP? Yeah, it's just way fucking better than Python SDK that we ship in, right? And that's on me because I wrote the Python SDK. And so I have a bunch of people who are way better at Python developers and me help me write it better. The second part is we need to start integrating everywhere. We're going to 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 once you log in once with your local company identity provider, be it a Google, be an actor, you will be able to just use mcp servers without having to re-log in. So it's a bit more smoothness. In addition, we're going to add something called a server discovery by specifying how you can discover servers on well known URLs automatically. So crawlers, browsers, agents can just go to a website and say, oh, I'm instead of just parsing the website, is there also mcp server I can use? And we will be able to automatically discover this. This is a really cool thing that will come down also in June when we launch an ex-specification and will be supported there. And then last but not least, we are starting to use our extension mechanisms 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 are a CLI, you just have a hard time rendering HTML. And we will do more of these extensions. One of the most exciting extensions that I think is cool, we're just going to 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 want to ship the main 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 as you are the server author, to continuously ship updated skills without having to rely on plug-in mechanisms and registries and other stuff. So that's coming down. There's a lot of experimentation from people already in that space. You can already do some of that today if you just give the model load skills to a like day. You can build primitives of versions of this today without having to rely on the semantics, but of course, we're going to define the semantics. Okay, so that's for me a long-winded way to say that I think mcp is actually in a really good shape. And I think in this year, we're going to push agents to full connectivity. mcp will continue to play a major, major, major role. And we want of course your feedback. We are very open community. We just have created a foundation where most do running as an open source community with a discord with issues. Just come to us and tell us where the fuck are we wrong? What are we getting right? So that we can improve this on a continuous basis. So 2026, 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 mcp's, and they will use skills. Because they want to have a right variety of things they can do. And then they can ship cool stuff like this. Which is one of the product features we ship recently. Under the hood, it's nothing but an mcp application that renders stuff. Cool. So we can now look at the model writing graphs. Anyway, thank you.
TL;DR
- MCP (Multi-Modal Communication Protocol) is rapidly establishing itself as a crucial standard for AI agent connectivity, enabling diverse applications and sophisticated tool interactions.
- Future agents will be "fully connected" by seamlessly integrating skills, CLI/computer use, and MCP to handle complex tasks across various systems.
- Key techniques for building advanced agents include Progressive Discovery to manage context window bloat and Programmatic Tool Calling for efficient orchestration of multiple tools through code.
Takeaways
- MCP applications allow agents to ship their own interfaces, enabling both human and model interaction through integrated tools.
- The MCP ecosystem has grown significantly, reaching 110 million monthly downloads, solidifying its role as a common standard for AI agents across various frameworks.
- Agent development is shifting towards "full connectivity" in 2026, where agents will utilize a combination of skills, CLI/computer use, and MCP to connect to various SaaS applications and shared drives.
- Implement "Progressive Discovery" in agent harnesses to reduce context window usage by deferring tool loading and dynamically searching for tools only when the model needs them.
- Leverage "Programmatic Tool Calling" by providing agents with a REPL environment to write and execute code, allowing them to compose and orchestrate multiple tool actions more efficiently than sequential individual calls.
- When designing MCP servers, prioritize an agent-centric design by providing execution environments and rich semantics rather than simply converting REST APIs one-to-one.
- Utilize MCP's unique "rich semantics," including features like MCP applications, skills over MCP, tasks, and elicitations, which offer capabilities beyond simpler communication protocols.
- Upcoming MCP improvements include a stateless transport protocol for better scalability, enhanced asynchronous task primitives for agent-to-agent communication, and new SDK versions.
Vocabulary
MCP (Multi-Modal Communication Protocol) — A protocol designed for AI agents to communicate, share tools, and interact with various systems and interfaces.
MCP application — An agent that ships its own user interface, served via an MCP server, allowing direct user interaction.
SDK (Software Development Kit) — A set of tools, libraries, and documentation that developers use to create applications for a specific platform or system.
Agent harness — The client-side component or framework that powers and orchestrates an AI agent's connective parts and tool interactions.
Progressive Discovery — A technique for AI agents to manage context by deferring the loading of tools and only retrieving them when the model explicitly needs them, often via a tool search mechanism.
Context window — The limited input size for a language model, which can become bloated if too many tools or too much information is loaded simultaneously.
Programmatic Tool Calling — An approach where an agent writes and executes code (e.g., in a REPL environment) to compose and orchestrate multiple tool calls, rather than making individual sequential calls.
REPL (Read-Eval-Print Loop) — An interactive programming environment that takes single user inputs, executes them, and returns the result, often used for scripting.
Rich semantics — Advanced features and structured information offered by a protocol (like MCP) that enable more sophisticated interactions and capabilities beyond basic data exchange.
Stateless transport protocol — A communication protocol design where each request from a client to a server contains all the information needed to understand the request, without relying on any stored session information on the server.
Transcript
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 chat chat, you can put it into VS Code, cursor, and it will just fucking work. And that, I think it's kind of 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 some analytics. You need to have both sides to client and the server to understand what each side is talking to understand how your render is, 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 chip an app, or can chip an app, it can also chip 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, 18 months, an eternity in AI lifecycle, all of this did not exist. There was just a little spec document, a few SDKs, mostly written by Klott, local only, with little more than just tools. It in that last 18 or 12 months, you guys have been absolutely crazy building stuff, building servers building, and crazy ecosystem around this, and we on our side have been 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 have just seen. And in the meantime, we have reached, I think, a really cool milestone, because, again, all of you have been absolutely crazy building, and building, and building, of course, luckily with the help of a bunch of agents. We're now at 110 million monthly downloads, and that's just, of course, not us using it in our clients and servers, that's like open AI's agents SDK, that's Google's ADC, that's Langshane, thousands of frameworks and tools that you might have never ever heard of it, pulling it as a dependency, which means there's one common standard that all of us have at our disposal to speak to each other. Just a bit for context, React, one of the most successful 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've all been building really, really cool servers from like little toy projects of WhatsApp servers and blender servers to building SaaS integrations like linear Slack and notions that are really powering what everyone does every day when they use MCPs, but most importantly, the vast majority of MCPs server, most of all of us have built or behind closed doors, connecting company systems to agents in AI applications. But I still think this is just the absolute beginning of where we are, because I think 2025 was all about exploring in 2026, is all about putting these agents into production. Because if you really think about, in my mind, 2024, we just build a bunch of demos and show cool stuff to people, and there was a little bit of a buzz there. 2025 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 very viable, you can call a compiler, like you have a developer who can fix shit if it goes wrong in front of the computer, and you can display a tool 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 this start, where we're not just doing coding agents, we're going to have general agents that will do real knowledge work or stuff, like things of financial analysis, analysts want to do, a marketing person want to do, and they need one thing in particular. They don't need a local agent that calls a compiler, but what they need is something that could connect to like five SAS applications 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 someone tells you there's one solution to all your connectivity problem, be it computer use, be it CLI, be it MCP, they are probably pretty wrong, because the right thing of course is that it always means it depends, and there's a real big connectivity stack, and there's a right tool for the right job. And in my mind, there are three major things that you want to consider building an agent in 2026. It's skills, MCP, and of course CLI, or computer use, depending on the use case. And they have three very distinct things that they can do, and three different things you want to 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 most irreducible, 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 close 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 CLI's, like GitHub, Git, and other things that are in pre-training, CLI is an amazing solution for your connectivity part, and they are 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 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, end up boring, but important enterprise stuff, or if you want to have experiments like MCP applications, or what comes soon, skills over MCP, then I think MCP is just like additional connective tissue that's 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 going to 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 because our agents kind of still suck, and partially because I think we just haven't talked enough about like some of the techniques you can do to really put this connective tissue together. The number one thing that we need to go and start building is on the client's, on the agent harness side, on the things that powers the connective parts that be it a Claude Code, be it a pie, be it whatever application you're going to build. And the number one thing we're going to do there, and what we all have to do, and something I want to really get across today, is that we need to go and start building something called progressive discovery. Most people when they think about like, oh, I'm C.P., they can't think about like context bloat. But if you really consider what a protocol does, the protocol just puts information across the wire, but the client is responsible for dealing with that information. And what everybody so far has done, because we 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. 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, and the API, and people can use this 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 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 Claude Code, before we added this to Claude Code, and then after it to Claude Code. So you see a massive reduction in tool context usage. The second part of that is something called programmatic tool calling, or what other people usually refer to code mode. This is the idea that one thing that you really want to do, is you want to 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 effectively doing is you're letting the model orchestrate things together, and in that orchestration you're using inference, it's latency sensitive, and all of its stuff could be done way more effective, if you would instead write a script. And in fact, that's actually what you constantly do, and what you constantly see, things like Claude Code do, when it's writes the bash command. But you can of course do this with everything, and you can do this with mtp, and you should do this with mtp. So what does this mean? So what you want instead of having one tool at another, you want to give the model a repel tool, provide 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 neatly feature, an mtp-code structured output, that tells you what the return value of the mtp-code, of the output will be. And the model can use this information to figure out type information, which then means it can really nicely compose these things together. And in this example here, instead of doing tool different calls, you do one call, and you can filter, the model will automatically remove things from Jason, 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, by just extracting it and saying, hey, call us 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 something where we can improve our agent harnesses. And then last but not least, of course you can just compose these things together with executables, like with CLIs, with other components, with APIs as well. Next, what we need to do, besides the client work, which is progressive discovery and 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 an MCP server. Every time I see someone building another rest to MCP server, a conversion tool, it's a bit cringed because I think it just results in horrible things. And what you should do instead, you should design for an agent. Basically, you can start designing for you as a human, how you would want to interact with this, because that's actually a very, very good start for an agent. If you want to 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. And the CloudFlem.mpcP 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 usage, cuts on latency, 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 skills over MCP. It means using things like tasks and other aspects that the protocol offers that we're 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 going to 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 hyper-scaler. And so we have a proposal from our friends at Google who are working with something called a stateless transport protocol, which make it significantly easier to just treat MCP servers like another stateless rest server, something like that, that we're used to know how to deploy to Claude runs or Kubernetes and so on. So that's coming down in June and hopefully lining 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 want to have agent to agent communication. We have a very experimental version of the protocol that very few clients support. So we're going to 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 going to ship a TypeScript version SDK version two and Python SDK version two, based on a lot of the lessons learned over the last year. There's a SDK called FastMCP. Who's using FastMCP? Yeah, it's just way fucking better than Python SDK that we ship in, right? And that's on me because I wrote the Python SDK. And so I have a bunch of people who are way better at Python developers and me help me write it better. The second part is we need to start integrating everywhere. We're going to 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 once you log in once with your local company identity provider, be it a Google, be an actor, you will be able to just use mcp servers without having to re-log in. So it's a bit more smoothness. In addition, we're going to add something called a server discovery by specifying how you can discover servers on well known URLs automatically. So crawlers, browsers, agents can just go to a website and say, oh, I'm instead of just parsing the website, is there also mcp server I can use? And we will be able to automatically discover this. This is a really cool thing that will come down also in June when we launch an ex-specification and will be supported there. And then last but not least, we are starting to use our extension mechanisms 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 are a CLI, you just have a hard time rendering HTML. And we will do more of these extensions. One of the most exciting extensions that I think is cool, we're just going to 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 want to ship the main 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 as you are the server author, to continuously ship updated skills without having to rely on plug-in mechanisms and registries and other stuff. So that's coming down. There's a lot of experimentation from people already in that space. You can already do some of that today if you just give the model load skills to a like day. You can build primitives of versions of this today without having to rely on the semantics, but of course, we're going to define the semantics. Okay, so that's for me a long-winded way to say that I think mcp is actually in a really good shape. And I think in this year, we're going to push agents to full connectivity. mcp will continue to play a major, major, major role. And we want of course your feedback. We are very open community. We just have created a foundation where most do running as an open source community with a discord with issues. Just come to us and tell us where the fuck are we wrong? What are we getting right? So that we can improve this on a continuous basis. So 2026, 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 mcp's, and they will use skills. Because they want to have a right variety of things they can do. And then they can ship cool stuff like this. Which is one of the product features we ship recently. Under the hood, it's nothing but an mcp application that renders stuff. Cool. So we can now look at the model writing graphs. Anyway, thank you.