If you have ever tried to run a remote MCP server behind a load balancer and discovered that request #2 has no idea what request #1 did, this post is for you. One of the largest changes to the protocol since launch is aimed squarely at that pain, and it does it by removing things.
For its entire life, MCP has spoken in text. Tools return strings and JSON; the model narrates the result back to you in prose. That was a deliberate, sensible constraint, and it was always going to hit a ceiling. Some answers are a paragraph. Others are a chart, a date picker, a seat map, a diff you want to click.
As of early 2026, MCP has an answer: MCP Apps, the protocol's first official extension, which lets a tool ship interactive UI that renders right inside the conversation.
Here is a cost nobody warns you about when you wire up your fifth MCP server: your agent gets dumber and more expensive at the same time, and it happens before the user has typed a single word.
The reason is boring and brutal. Every tool your servers expose ships a definition: a name, a description, a JSON schema for its inputs, often examples. All of it gets serialized into the model's context window on every single turn, just so the model might pick the right tool. Connect a few busy servers and you are spending six figures of tokens describing tools the model will never call for this particular request.
Pop quiz. Name the MCP primitives.
If you've read any MCP introduction in the last eighteen months, you said: Tools, Resources, Prompts. You're right. Those are the things you build, the things you expose, the things every tutorial walks you through.
You are also wrong, in the sense that you are halfway right.
MCP has six primitives. The three you know are server-side: things your server exposes to the client. The three nobody seems to want to talk about are client-side: things the client exposes to your server. They are Roots, Sampling, and Elicitation, and the reason they get ignored is exactly the reason you should care about them.
Every developer who has integrated an AI with a real backend knows this pain. The user says, "Run the data refresh." The MCP tool kicks off a job. The job takes four minutes. The MCP request times out at thirty seconds. The model receives an error and confidently tells the user, "I was unable to run the data refresh," even though the refresh is, at this very moment, happily running.
For about a year, MCP had no good answer for this. You either polled, you faked it, or you accepted that long-running operations weren't really part of the protocol's worldview. The 2025-11-25 spec changed that by introducing Tasks: a first-class way to say "this isn't going to finish in the next thirty seconds, and that's fine."
This post is about what Tasks are, what they replace, and why the addition is more interesting than the headline makes it sound.
Here is a tool description from a real, public MCP server. The name has been changed because I'm not in the business of public shaming, but the wording is verbatim:
query_data: Queries the data.
Two words. One of which is the tool's own name. The other a tautology. This is what happens when a developer treats description as a field on a struct rather than what it actually is: a prompt fragment that the AI reads to decide whether to call your tool.
If you are writing tool descriptions the way you write Swagger comments, you are writing them wrong. Let's talk about why.
Every time you write a bespoke AI tool integration without a standard, you're making a promise to your future self: I will maintain this forever, or I will rewrite it later.
You're not going to maintain it. And "later" has a way of arriving at the worst possible moment.
Asimov's Three Laws of Robotics encoded a philosophy about how robots should relate to humans. They weren't just rules, they were a framework for reasoning about harm, autonomy, and control. The laws conflicted with each other by design, forcing a hierarchy.
MCP's three primitives, Tools, Resources, and Prompts, encode a similar philosophy. They're not just API categories. They're a framework for reasoning about how AI should interact with the world: what it can change, what it can only read, and what humans explicitly invoke.
Get them right, and your MCP server is intuitive, safe, and composable. Get them wrong, and you'll wonder why the AI keeps calling the wrong thing at the wrong time.
Remember 2018? Every device had a different port. Your laptop needed USB-A. Your phone needed Micro-USB or Lightning depending on the religion of its manufacturer. Your camera used Mini-USB because it was made by people who clearly hated you.
Carrying a bag of adapters was not a software problem. It was a standards problem. USB-C solved it not by being a better technology than its predecessors (it was also just a connector), but by being a common connector. One port. One cable. Every device.
The AI tool integration ecosystem looks exactly like 2018's port situation. MCP is the USB-C moment.
Your AI knows things. An extraordinary amount of things. It can explain the Krebs cycle, debug a segfault, and write a sonnet about dependency injection. And yet, it cannot tell you what's currently in your calendar.
This isn't a capability gap. It's an architecture problem. And MCP exists to solve it.