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.

The session problem​

Today's remote MCP relies on a session: the client and server do an initialization handshake, the server issues an Mcp-Session-Id, and subsequent requests carry it. That works beautifully on one process and miserably across many. The moment you want to scale horizontally, that session id becomes a sticky leash, because every request for a session has to land on the one instance that holds its state, so you reach for sticky load balancing, shared session stores, and a lot of operational duct tape.

What changed​

The 2026-07-28 revision removes session management: the Mcp-Session-Id header is gone, and so is the initialize/notifications/initialized handshake. Each request now carries its protocol version, client identity, and client capabilities in _meta instead. Servers gain a new server/discover RPC that clients can call up front to negotiate versions and capabilities. The protocol becomes effectively stateless at the transport layer: any request can be served by any instance, because no instance is special.

This is one of the largest revisions since MCP launched, and it lines up with the 2026 roadmap's stated priorities of Transport Evolution and Scalability and Enterprise Readiness. Notably, it does this without introducing a new transport. Streamable HTTP remains the one remote transport; the change is about removing session coupling, not adding plumbing.

What breaks​

Be honest with yourself about what leaned on the session:

• Server-held per-session state has nowhere to live implicitly anymore. If your server stashed "what we're doing" in memory keyed by session id, that assumption is gone.
• Code that reads or asserts Mcp-Session-Id needs to stop.
• Init-handshake-dependent flows must tolerate a world where there is no handshake to hang setup on.

What gets much easier​

This is the trade you are being offered, and it's a good one:

• Horizontal scaling becomes boring: spin up N identical instances behind a plain round-robin balancer, no stickiness, no shared session store required for the protocol's sake.
• Resilience improves: an instance dying no longer orphans a session's worth of in-memory state.
• Deploys get simpler: rolling restarts stop being a session-eviction event.

State doesn't vanish; it just has to become explicit. Anything durable moves to your data layer and is referenced by handle in requests, rather than living implicitly in a session on one box.

Migrating, roughly​

The migration shape is:

1. Inventory everything that depends on the session or the handshake.
2. Move per-session memory into an external store, keyed by an explicit handle you pass in requests.
3. Stop emitting and requiring Mcp-Session-Id.
4. Put your instances behind a stateless balancer and delete the sticky-session config you no longer need.

The bottom line​

MCP is trading a convenience (implicit session state) for the thing enterprises actually need (trivial horizontal scaling). It's the right trade, and the ink is now dry. The remaining constraint is your SDK rather than the spec: make your state explicit now, because that part runs on today's SDKs, and pick up the protocol-level changes as your SDK ships them.

This is the spine of our MCP at Scale course, which goes deeper on stateless transport, explicit state handles, routing, and horizontal scaling.

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.

The text-only ceiling​

You have felt this. You ask an agent for "revenue by region this quarter" and get back a tidy ASCII-ish table that you immediately want to sort, filter, or export. The model has the data; the channel just can't render anything you can interact with. Every rich interaction had to bounce out to a separate app.

MCP Apps closes that gap without abandoning the protocol's safety model.

What MCP Apps actually is​

It is not a new transport or a new primitive grab-bag. It is a focused extension built on two pieces you already know, resources and tools:

• A tool can advertise a UI resource via _meta.ui.resourceUri. That resource is HTML, served with the MIME type text/html;profile=mcp-app.
• The host renders that HTML inside a sandboxed iframe, isolated from the page, the model, and your other tools.
• The iframe talks back to the host over JSON-RPC sent across postMessage, brokered by the App SDK.

So a tool result is no longer just text. It can be "here is the data, and here is a sandboxed widget to render it."

The part that should make you comfortable: consent didn't change​

The first question a security-minded engineer asks is "so a server can now run arbitrary UI in my client?" The reassuring answer: the widget is sandboxed, and actions still flow through the same tool-call consent path you already trust.

When a user clicks "Export" in the widget, the iframe doesn't get to quietly do something. It sends a JSON-RPC message that becomes a tool call, and that tool call goes through the host's normal approval flow, the same gate that governs every other tool invocation. The UI is new; the trust boundary is not.

Write once, render across hosts​

The reason this is a big deal and not just a vendor feature: it is a shared extension, and the early host list is broad, with Claude, ChatGPT, VS Code, Goose, Postman, and MCPJam among the documented adopters. An MCP App you build is meant to render across compliant hosts rather than being locked to one assistant. That cross-host portability is exactly what made base MCP win, now applied to UI.

What this means if you build MCP servers​

• Your reach just expanded from "return good text" to "return a usable interface" (pickers, dashboards, confirmations, forms) without shipping a separate frontend app.
• The widget is HTML/JS, by design. It renders in a browser iframe, so the UI layer is web tech regardless of what your server is written in.
• For the Java crowd (us included): there is real nuance here. You can absolutely serve an MCP App from a Java server by exposing the ui resource and wiring the tool's _meta.ui.resourceUri through the Java SDK. But the widget itself is HTML/JS, and the official App SDK published in the ext-apps repo today is TypeScript/JavaScript. So the honest framing is: Java server, web widget. Don't expect to write the UI in Java.

The bottom line​

MCP Apps is the protocol admitting that some answers aren't sentences. It does it the right way, by building on resources and tools, sandboxing the UI, and keeping every action on the existing consent rails. If you've been treating MCP as a backend-only concern, this is the moment it became a product-surface concern too.

We're building a full Building MCP Apps course around this: the ui resource, the iframe security model, the postMessage/App SDK bridge, the consent path, and a widget built end-to-end (served from a Java MCP server, with an honest accounting of where the web layer begins).

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.

The tax you didn't know you were paying​

There are actually two separate bloat problems, and conflating them is why people "optimize" the wrong one.

1. Definition bloat (up front). Before any work happens, the client loads every tool definition from every connected server. This is fixed per turn and scales with how many tools you have connected, not with what you are doing. Three hundred tools at ~500 tokens each is ~150,000 tokens of overhead on turn one.

2. Result bloat (at runtime). A tool returns 4,000 rows of JSON, the model needs three of them, and the other 3,997 sit in the transcript forever, getting re-sent on every subsequent turn.

Definition bloat makes your agent expensive and slow and dumber, because a context window crammed with tool schemas has less room for the actual problem, and models genuinely degrade as the relevant signal gets buried. Result bloat compounds it turn over turn.

The fix: stop describing tools, start importing them​

The technique Anthropic documented flips the model's relationship to your tools. Instead of presenting every tool as a definition the model reads and then calls via JSON, you present your MCP servers as a filesystem of code, a directory of typed functions the model can import and call from inside a sandboxed code-execution environment.

// The model doesn't see 300 tool schemas.
// It sees a filesystem and writes code against it:
import { getInvoices } from "./servers/billing";
import { getCustomer } from "./servers/crm";

const overdue = (await getInvoices({ status: "overdue" }))
  .filter(i => i.daysLate > 30);

// Only the 3 rows it needs ever re-enter the context, not 4,000.
console.log(overdue.map(i => ({ id: i.id, customer: i.customerName })));

Two things just happened:

• The model only loads the definitions it actually imports, also known as progressive disclosure. The other 295 tools cost nothing this turn.
• The model processes results in code and returns only the slice it cares about, so result bloat collapses too.

Anthropic's worked example moved an agent from roughly 150,000 tokens to roughly 2,000 for the same task, about a 98.7% reduction. Treat that as "an order of magnitude or two, in a favorable case," not a number to put on a slide.

Progressive disclosure is the real idea​

"Code execution" is the mechanism; progressive disclosure is the principle, and it long predates MCP. Don't put everything in front of the model at once. Let it discover the tool surface lazily: list what's available cheaply, load the full signature of a tool only when it intends to use it, fetch only the fields a step needs.

You can apply the principle even without a full code sandbox:

• Group tools and load definitions per-group on demand instead of all at once.
• Return compact, paginated, or summarized results by default and offer a "drill in" tool for detail.
• Keep large payloads as resources the model references by handle, not as inline tool output it has to carry forever.

So who is supposed to fix this, you or the client?​

This is the honest nuance the headline glosses over: a lot of definition bloat is the client's problem, not your server's. How tool definitions are packed into context, whether the host supports a code-execution surface, whether results can be offloaded to resources, much of that lives in the MCP host, not your server.

What you control as a server author:

• Right-size your results. Default to lean; make verbosity opt-in.
• Lean on resources for big data instead of stuffing it through tool outputs.
• Write tight definitions (see Your Tool Description Is a Prompt; every wasted word is a wasted token, on every turn).

What you control as a host/client author:

• Whether you expose tools as schemas-in-context or as an importable code API.
• Whether you implement progressive disclosure of definitions at all.

What to do Monday​

1. Measure first. Log the token count of your tool definitions on a cold turn. People are routinely shocked.
2. Cut definition bloat before you touch anything clever: fewer, sharper tools; tighter descriptions.
3. Move big results to resources so they stop riding along every turn.
4. If your host supports it, try the code-execution surface on your most tool-heavy agent and measure the delta on a real task.

The agents that win in 2026 aren't the ones connected to the most MCP servers. They're the ones that can ignore the most servers, cheaply, until the moment a tool is actually needed.

Want the full treatment? This is the heart of our upcoming Context Engineering for MCP course, covering token accounting, code execution, progressive disclosure, and how to measure the savings instead of trusting a blog post's numbers (including this one).

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.

Why You've Never Heard of the Other Half​

The first six months of MCP content focused, sensibly, on the obvious story: you build a server, it exposes tools, the AI uses them. That's the part most developers need first. Most people writing tutorials never get past it.

But MCP is not actually a one-way protocol. The spec is fully bidirectional. Servers can ask clients for things, not just respond to client requests. The client capabilities are how that conversation works.

The asymmetry of attention is partly an SDK story. Until quite recently, most Java and Python frameworks made the server-side primitives much easier to use than the client-side ones. If you were building with Spring AI, you were probably writing @Tool-annotated beans long before you knew you could write a RootsHandler. The protocol always supported it; the ergonomics didn't.

That has changed in the last year. The 2025-06-18 spec made the client-side primitives more useful by adding Elicitation. The 2025-11-25 spec polished the corners. And the SDKs are catching up. If you only know the three server-side primitives, you're working with half the protocol.

Primitive 4: Roots (The Server Asks "What Am I Allowed To See?")​

Suppose you write a filesystem MCP server. It can read files. Wonderful. Now: which files?

The server doesn't have arbitrary access to the user's machine. It can't. Imagine the security disaster if it did. Some entity has to decide what's on-limits and what isn't. That entity is the client, because the client is the part that knows what the user has authorised.

Roots are the mechanism for that conversation. When a client supports Roots, it advertises that it can answer the question: "Here are the directories (or, more generally, URI scopes) that this server is allowed to operate on." A filesystem MCP server can call roots/list on the client to find out: maybe the user has granted access to ~/Documents/work and nothing else. The server then knows the boundary of its world.

If the user adds a folder to the workspace, the client emits notifications/roots/list_changed. The server re-queries. The boundary updates live, mid-session, without anyone reconnecting.

What this enables in practice:

• Workspace-aware servers. Your IDE plugin (Cursor, Continue, Claude Code) can tell the MCP server which project the user is currently working in. The server scopes everything to that project. Switch projects, the scope changes.
• Multi-tenant clients. A single client can serve multiple users; each user has their own roots; the server doesn't have to manage that mapping.
• Principle of least access at the protocol layer. The server cannot accidentally read outside its roots, because there's an explicit protocol-level fence. This is much stronger than "we'll just be careful in the code."

If you've ever shipped an MCP server that took a base_directory configuration parameter at startup time, Roots are the more honest version of that pattern. The user, through the client, gets to dynamically tell you what counts as the base.

Primitive 5: Sampling (The Server Asks the AI for Help)​

This one bends people's brains, so we'll go slowly.

When you think of an MCP server, you think of something the AI uses. The AI calls a tool; the server runs code; the result goes back to the AI. The intelligence is in the AI; the server is just hands.

But what if the server needs the intelligence too?

Suppose your MCP server fetches a web page and needs to summarise it. Or fetches a code file and needs to extract its dependencies. Or processes a customer support ticket and needs to classify its sentiment. These are tasks that ought to use an LLM. But your MCP server doesn't have direct access to one. It doesn't have an API key. It doesn't know which provider the user is using. It doesn't know if the user wants their requests sent to a third party at all.

Sampling is the protocol's answer. The server can call sampling/createMessage on the client to say: "I have a prompt. Please run it through whatever model you're using, with whatever budget you allow, and give me the response." The client owns the model relationship. The client can refuse, log, redact, change models, or budget the request. The server doesn't have to think about any of that. It just gets a completion.

This is what makes truly composable agents possible. Without Sampling, every MCP server has to either:

1. Be entirely deterministic (no LLM reasoning inside the server), or
2. Bring its own model (with all the configuration, secrets, and surprise-vendor-coupling that implies).

With Sampling, the server can borrow the client's brain. A summarise_url tool that uses Sampling internally to produce a high-quality summary, in whatever model the user has chosen, with the user retaining full control. That's a kind of architectural cleanness you can't get any other way.

The caveat, and it's a real one: Sampling has historically been one of the least-implemented capabilities. Many clients don't support it. In fact, the current draft spec proposes to deprecate Sampling (alongside Roots and Logging) under SEP-2577, with the suggested migration being direct integration with LLM provider APIs from inside your server. Sampling is still in the stable spec today, but if you're designing new servers, weigh that direction carefully and check whether your target clients support it before depending on it.

Primitive 6: Elicitation (The Server Asks the User a Question)​

This is the newest of the client-side primitives. It landed in 2025-06-18 and is the one most likely to change how you design tools.

Picture this. Your MCP server has a deploy_service tool. The user (through the AI) asks to deploy payment-service. Your tool is ready to run, but you need one more piece of information: which environment? Staging, production, or canary?

Before Elicitation, you had four bad options:

1. Make the AI ask the user in chat. ("Which environment?") The user answers, the AI parses, the AI re-calls your tool. Three round-trips, hope nothing gets lost in translation.
2. Add environment to your tool's required parameters and hope the AI guessed right.
3. Pop up an OS-level dialog. Out of band. Awful UX.
4. Just pick a default and pray.

Elicitation is option 5. Mid-tool-call, the server can call elicitation/create on the client with a JSON Schema describing the structured input it needs. The client surfaces a form to the user, in the host UI, that exactly matches that schema. The user fills it in. The response comes back to the server as a validated object. The tool continues.

The user always retains the right to cancel. The schema is what the server asked for, but the client owns the rendering. The conversation in chat is uninterrupted.

What this changes:

• Structured questions stop bouncing through the model. Previously, "ask the user" had to happen via the model, which meant the model had to understand the question and the answer. Now the question can be structured (a date picker, a dropdown, a typed text field) and the model just receives the validated answer.
• Trust boundaries become cleaner. The server explicitly admits when it doesn't have all the information. The user explicitly approves before the operation proceeds. No more "the AI just decided to deploy to production because it interpreted my sentence aggressively."
• The "are you sure?" pattern gets a protocol-level home. High-risk operations can elicit explicit confirmation, with the confirmation being a typed response, not a chat string the model might paraphrase.

This is the primitive I'd predict will reshape tool design over the next year. Once developers internalise that "ask the user a structured question" is a protocol-supported operation, a lot of tools that currently overstuff their parameter schemas will quietly transition to "elicit what's missing."

Why the Asymmetry Matters​

The three server-side primitives encode what your server provides. The three client-side primitives encode what your server can ask for. Both are about explicit capabilities, declared at the start of a session.

This explicit declaration is the part that makes MCP feel different from other AI integration approaches. In a normal SDK, you have to assume the worst about what the other side can do. You write defensive code. You handle the cases that may never arise. You build for the lowest common denominator.

In MCP, the capability declaration at session start tells you exactly what the other side can do. If the client doesn't advertise sampling, you don't call sampling/createMessage, and you also don't have to write code defending against the case where it might not work. If the client advertises elicitation, you can write your tool assuming you can ask for structured input. The contract is upfront.

That bidirectional capability negotiation is what makes MCP, in my view, a serious protocol rather than a thin convention around tool calls. The other half of the primitives is where it shows.

Practical Translation​

If you're designing an MCP server today, here are concrete questions to ask:

On Roots:

• Does my server have a notion of "scope"? Could it benefit from the client telling me what scope to use?
• Am I currently accepting a base_directory (or workspace, or project) configuration parameter that should really be dynamic?

On Sampling:

• Are there steps inside my tool implementation that would benefit from an LLM call (classification, summarisation, decision-making)?
• If yes, am I currently solving that by either (a) being deterministic, or (b) bringing my own model? Could Sampling let me offload that decision to the client?

On Elicitation:

• Are there optional parameters in my tools that the model frequently gets wrong, that a structured question to the user would always answer correctly?
• Are there high-risk operations where I'd like explicit user confirmation outside the chat stream?

The first time you ask these questions, you'll probably find at least one tool in your server that would be better if it used one of the client-side primitives. That's how I knew, the first time, that the other half of the protocol was load-bearing.

The Bigger Picture​

The fact that "MCP has three primitives" became conventional wisdom is a textbook case of protocols being learned through tutorials rather than specs. The tutorial writers wanted to ship the minimum viable mental model. The minimum viable mental model is "tools, resources, prompts." That's good enough to get someone building. It's also wrong by half.

If you're building servers, the three server-side primitives are where you'll spend most of your time. Roots, Sampling, and Elicitation are where you'll unlock the next layer of capability. Many of the patterns that look hard in a server-only world (live workspace scoping, embedded reasoning, mid-tool user input) become clean when you remember that the protocol is two-way.

So: MCP has six primitives. Tools, Resources, Prompts on one side. Roots, Sampling, Elicitation on the other. They're not optional. They're not advanced. They're the part of the protocol that explains the design choices in the part you already know.

For the protocol-level mechanics, the Capability Negotiation module walks through how clients and servers declare and discover these capabilities at session start.

For a deeper dive on Elicitation specifically (the human-in-the-loop primitive), the Human in the Loop module of the Agentic Workflows course shows how to design tools around it — that course is coming soon.

And if you want to see how all six primitives compose into a real architecture, the MCP Architecture Patterns course threads them through the bigger picture. It is also coming soon.

Three primitives is the bumper sticker. Six is the protocol.

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.

The Synchronous Trap​

MCP, like JSON-RPC underneath it, started life as a request/response protocol. You send tools/call. You get back CallToolResult. The transport assumes that pair of messages will fit comfortably inside one HTTP round-trip, or one back-and-forth on a stdio pipe, or one quick SSE exchange.

For most tools, that assumption is fine. search_customers runs a database query and returns in 200ms. read_file reads a file and returns immediately. calculate is, well, calculation.

But real systems have operations that don't fit this shape:

• Deployments that take minutes to roll out.
• Data refreshes that scan terabytes.
• CI runs that compile, test, and lint at their own pace.
• External integrations that legitimately take a while because they're sending email, generating PDFs, or waiting on a human.
• Anything involving "approval" where a human has to actually look at something.

The original MCP answer was: don't do that. Make every tool fast. If you have something slow, kick off a background job from the tool and return a job ID, then have the model poll a separate get_job_status tool until done.

This worked, in the same way that walking up the stairs with a sofa works. You can do it. You won't enjoy it. And every team reinvented it slightly differently.

Enter Tasks​

The 2025-11-25 spec added experimental support for Tasks (SEP-1686). The core idea is small and elegant: certain MCP requests (today, tools/call for clients, and sampling/createMessage/elicitation/create for servers) can be augmented with a task. The receiver returns a task handle instead of holding the original request open, and the requestor polls for status and eventually fetches the result. Capability negotiation declares exactly which request categories support task augmentation in each direction.

A task has a lifecycle. The spec defines explicit states:

• working: the task is running
• input_required: the task is paused, waiting for more input from the user
• completed: the task is done; the result is ready to fetch
• failed: the task ran but produced an error
• cancelled: the task was cancelled (by the client or the server)

That state machine alone solves a lot of problems. The "input_required" state is particularly clever: it gives a clean answer to operations that need to ask the user a question mid-flight, which previously required hacking around the request/response model. (Elicitation, which landed in 2025-06-18, becomes much more powerful when it can be invoked from inside a long-running task instead of having to fit inside a single tool call.)

Why This Is Not Just "Async"​

The first time I read about Tasks, my reaction was: "Okay, MCP got promises. Took them long enough."

I was wrong. Tasks aren't just async/await for the protocol.

The interesting design choice is that the client decides whether to wait. In a normal async API, the server decides whether something runs synchronously or asynchronously, and the client lives with it. In MCP Tasks, the client (the requestor) decides whether to augment a request with a task, choosing between a synchronous call and a task handle. The server doesn't unilaterally upgrade a synchronous call; instead it controls which tools may be run as tasks by declaring each tool's execution.taskSupport as forbidden, optional, or required (a required tool returns an error if the client doesn't augment the call).

That's not promises. That's a negotiation about how long the client is willing to wait.

It also opens up patterns that weren't really possible before:

• Background work that survives client disconnects. Start a task. Close your laptop. Open it tomorrow. The task is still there. Fetch the result.
• Multi-step approvals. The task pauses at input_required, the user gets a notification in their host UI, they answer, the task continues.
• Cancellation that actually works. Previously, cancelling a tool call meant ignoring its result. Now there's an explicit cancelled state and a way for the server to clean up.
• Resumable interactions across sessions, devices, or even different clients of the same MCP server.

These aren't new ideas in distributed systems. They're new in protocols designed for AI agents, and that's where the leverage is.

What This Means for Tool Design​

The introduction of Tasks doesn't mean every tool should be a task. The default is still synchronous, because most tools really should be fast.

But for the operations where Tasks fit, they change how you should think about tool design:

1. Stop returning fake "job started" messages. If your tool kicks off background work, return a task handle. The client knows what to do with one. It doesn't know what to do with a string that says "Started job 47, check back later."

2. Stop polling from the model side. A model that calls get_status in a loop is burning your token budget and not actually waiting on anything useful. With Tasks, the client (Spring AI, Claude Desktop, whatever) handles polling for you, with proper exponential backoff, at a layer the model doesn't need to think about.

3. Use input_required instead of inventing your own approval dance. I have seen MCP servers implement approval flows by returning a tool result that says "Please call approve_deployment(approval_token=...) next." This is, charitably, a workaround. A task that transitions to input_required and uses elicitation to ask the question is the protocol-native version.

4. Design your tool's granularity around the task boundary. "Run database migration" is one task with several phases. "Run database migration phase 1, then phase 2, then phase 3" is three separate tools that the model has to coordinate, badly. Tasks let you fold internal complexity inside a single logical operation.

Where It's Going​

Tasks are marked experimental in 2025-11-25. That word matters: SDKs may implement them at different speeds, transport semantics may shift, edge cases may produce surprising behaviour. If you're building production servers today, treat Tasks as something to plan for rather than something to bet the farm on this quarter. The current draft spec actually moves Tasks out of the core protocol and into an official extension (io.modelcontextprotocol/tasks) under SEP-2663, with a redesigned API (polling via tasks/get, client input via tasks/update). Watch that work carefully if you're writing against the experimental version today.

But the direction is clear. The 2026 MCP roadmap leans heavily into stateless servers, agent-to-agent coordination, and longer-lived interactions. All of those need a vocabulary for "this is going to take a while." Tasks give the protocol that vocabulary for the first time.

There's a deeper architectural point hiding in here. Up until Tasks, MCP encoded one specific kind of interaction: a human (or a model) initiates a step, something happens immediately, a result comes back. That's the shape of a conversation. With Tasks, the protocol can also encode the shape of an operation, something that has its own lifecycle, independent of any particular conversation turn.

Agents, especially multi-agent systems, fundamentally need both. A coordinator agent should be able to dispatch a long-running task to a worker agent, get a handle, do other things, and check back later. That's how real systems are built. Tasks are MCP catching up to that reality.

The Counterintuitive Bit​

Here's the thing about Tasks that surprised me when I sat with it.

The most useful Task is not the one that runs for ten minutes. The most useful Task is the one that runs for fifteen seconds.

Long operations (minutes, hours, days) are obvious candidates. Everyone agrees those should be tasks.

But there's a vast middle ground of "long enough to be awkward, short enough that you didn't bother engineering for it." A tool that takes 8-12 seconds. A tool that takes 25 seconds on a bad day. A tool that has to call an external API whose latency is 95th-percentile-bimodal. These are the ones that quietly poison user experience. They're too short to engineer like a job. They're too long to ignore.

Tasks let you handle the "awkwardly long" case the same way you handle the "obviously long" case. That uniformity is the actual win. You stop deciding, per tool, which side of the synchronous/asynchronous fence to land on. You just return a task handle when it makes sense, and the client figures out the rest.

Reading the Tea Leaves​

If you want to know which direction MCP is moving, the addition of Tasks is one of the strongest signals you'll find. The protocol started as a way to expose tool calls to AI models. It's becoming a way to coordinate work with AI models. Those are different products. The transition is mostly silent, but Tasks are one of the loud moments.

Two more developments to watch in the same direction:

• Agent Communication. The 2026 roadmap calls out an "Agent Communication" priority area, with an Agents WG closing operational gaps around Tasks (retry semantics, expiry policies). The combination of Tasks plus richer agent-communication semantics is what you'd build a multi-agent system on top of.
• Transport Evolution and Scalability. Also on the 2026 roadmap. Pairs well with Tasks: a stateless task handler can be horizontally scaled because the state lives in the task itself, not the server process.

The 2025-11-25 spec is the first time MCP felt less like an RPC and more like an orchestration substrate. Tasks are the centerpiece of that shift.

If you're building Spring AI + MCP servers and want a deeper look at long-running operations, asynchronous tool composition, and the patterns that surround Tasks (resilience, retries, idempotency), the MCP Architecture Patterns course has a thread of these patterns running through it. That course is coming soon.

If you want to understand the full evolution of the spec from the first 2024 release to today, the MCP Ecosystem module walks through every revision and what it added.

Either way: MCP stopped watching the clock. Your tools can finally take as long as they actually take.

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.

The Misconception​

When you define an MCP tool, you provide three things: a name, an inputSchema, and a description. Most developers correctly understand that name and inputSchema are mechanical: they're how the protocol identifies and validates the call. So they treat description the same way: a quick label, half a sentence, just enough to make the linter happy.

But description is not a label. The model never sees the schema as natural language. It sees the schema as structured data. The only natural-language signal the model has, when deciding which of your seventeen tools to call, is the description.

In other words: the description is the prompt that decides whether your tool gets used. Treating it like a code comment is treating a load-bearing wall like a coat of paint.

What the Model Actually Sees​

Here is the rough shape of what arrives in the model's context window when an MCP client surfaces your tool:

You have access to the following tools:

- query_data
  Queries the data.

- search_customers
  Look up customer records in the CRM. Accepts a search string (matches name,
  email, or phone) and an optional account-status filter. Returns up to 50
  matching customers with id, name, email, account_status, and last_active_at.
  Use this when the user asks about specific customers or wants a list of
  customers matching some criterion. Do not use for bulk export (max 50) or
  for billing data (see get_customer_billing).

Now imagine you're the model. The user just asked: "Can you find John Smith's record?"

Which tool are you going to call?

The model is doing the same thing a junior developer does when they read your team's documentation: picking the most useful-looking option based on the words on the page. If the words on the page say "Queries the data," that tool is going to be either ignored entirely or called catastrophically wrong, because the model has nothing to ground its decision in except the noun "data" and the verb "queries."

The Anatomy of a Good Tool Description​

There are four things every tool description should contain. Skip any of them and the model will guess. Models guessing is how you end up debugging at 2am.

1. What it does, in one specific sentence. Not "queries the data." Specifically: "Look up customer records in the CRM by name, email, or phone." Notice the verbs (look up), the object (customer records), the source (CRM), and the parameters (name, email, or phone). Specificity is the entire game.

2. What it returns, in concrete terms. The model is about to incorporate your output into its reasoning. If it knows your tool returns "up to 50 matching customers with id, name, email, account_status, and last_active_at," it can plan a multi-step interaction. If your description says it returns "data," the model might call your tool, then call it again because it doesn't trust the result, then summarise it incorrectly.

3. When to use it. This is the part most developers skip. The description has to position the tool relative to the user's likely intent. "Use this when the user asks about specific customers or wants a list of customers matching some criterion." That sentence is doing the work of about three rounds of trial and error.

4. When not to use it. This is the part nobody puts in. And it's the most important one. "Do not use for bulk export (max 50) or for billing data (see get_customer_billing)." This single negative clause prevents an entire category of misuse. The model has bounded its own search space.

A Worked Example​

Here is the same tool, written badly and written well.

Bad:

{
  "name": "create_ticket",
  "description": "Creates a support ticket."
}

The model will call this when the user mentions tickets. It will guess at the priority field. It will not know whether to put the user's whole message in description or summarise it. It will not know if this tool also notifies the assigned engineer. It will call it once, then call it again with different arguments, because nothing in the description tells it that this operation is not idempotent.

Good:

{
  "name": "create_ticket",
  "description": "Create a new support ticket in the helpdesk system. The ticket is assigned to the on-call engineer for the relevant team based on the `category` field. The reporter is notified by email; the on-call engineer is paged for severity P0 and P1 tickets. Use this when the user explicitly asks to file a ticket or report an issue. Do not use to comment on an existing ticket (use `add_ticket_comment`) or to escalate an existing ticket (use `escalate_ticket`). This operation is NOT idempotent: calling twice creates two tickets."
}

That is a paragraph. It feels excessive when you're writing it. It is exactly the right length when you remember that the model reads it once and uses it forever.

Tool Descriptions Are Code​

Here is the reframing that helps me write better descriptions: the description is part of the contract, not the documentation. If it's wrong, the tool is broken. If it's ambiguous, the tool is fragile. If it's terse, the tool is unsafe.

This has practical consequences:

• Review descriptions in code review the way you review function signatures. "Is this clear? Is this complete? Does it explain the edge case?" These are not soft questions.
• Test descriptions empirically. Run your tool against a model with realistic user prompts. If the model calls it at the wrong time, the description is wrong. If the model fails to call it when it should, the description is missing something.
• Update descriptions when behaviour changes. A function with a stale comment is a minor sin. A tool with a stale description will produce wrong results in production until somebody notices.

The MCP spec itself agrees: since revision 2025-06-18, tools (alongside resources and prompts) carry an optional title field for human-friendly display, so that name can be used as a programmatic identifier and description is free to be aggressively model-oriented. That's the protocol telling you, directly, that these two audiences are different and the description belongs to the model.

The Counterintuitive Bit​

Writing good tool descriptions feels like over-engineering. You're sitting there writing a four-sentence paragraph for a function that's eight lines long, and your inner code reviewer is screaming about brevity.

Ignore that voice. It evolved for a different audience.

When you write a Java function, your audience is another developer who has type signatures, tests, the surrounding codebase, and Stack Overflow. Brevity is a virtue because they can recover any missing context.

When you write a tool description, your audience is a language model with one context window, no IDE, no grep, no ability to ask follow-up questions, and a hard incentive to just pick something and try it. It cannot recover missing context. The description is all there is.

In that environment, the brief description is not elegant. It's a failure to communicate.

The Test​

Here's a five-minute exercise that will improve every tool description you write.

For each tool in your server, write down the answer to these questions, in plain English:

1. What is the most specific verb-and-object phrase that describes what this tool does?
2. What does it return, listed by field?
3. What is a one-line description of when the user would want this called?
4. What other tool in this server might the model confuse this with, and what's the difference?
5. Are there irreversible side effects? Should the model warn the user before calling it?

Now collapse those five answers into a paragraph. Drop the bullet structure. Use complete sentences. That's your description.

If your answer to question 4 is "no other tool," you probably have a server with one tool, or you're missing a tool. If your answer to question 5 is "no side effects," your tool might be a Resource instead. (See the Three Laws of MCP for the Tool-vs-Resource decision.)

The Bigger Pattern​

The lesson here generalises. Anywhere you're writing natural language that an LLM will read, you're writing a prompt. Tool descriptions are prompts. Resource descriptions are prompts. System messages are prompts. The strings inside your retrieval pipeline are prompts.

Software engineering has spent forty years training us to write text aimed at compilers (precise, terse) and humans (clear, structured). LLMs are a third audience. They want specificity, examples, constraints, and explicit negative guidance. They reward verbosity in ways that compilers and humans don't.

Once you internalise that, you stop feeling self-conscious about writing four-sentence descriptions for two-line tools. You start feeling self-conscious about the opposite.

If you want a more systematic treatment of tool design (including descriptions, schema, granularity, and the subtle art of when to split a tool in two), the Implementing Tools module of the Java SDK course walks through the patterns end-to-end. The Three Laws of MCP covers the Tool / Resource / Prompt decision, which is where description quality starts to matter most.

Your description is a prompt. Write it like one.

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.

What Hardcoded Tool Calls Look Like​

Here's a pattern you've probably written, or will write soon:

def call_ai_with_tools(user_message):
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": user_message}],
        tools=[
            {
                "type": "function",
                "function": {
                    "name": "search_customers",
                    "description": "Search customers",
                    "parameters": {
                        "type": "object",
                        "properties": {
                            "query": {"type": "string"}
                        }
                    }
                }
            }
        ]
    )

    if response.choices[0].message.tool_calls:
        tool_call = response.choices[0].message.tool_calls[0]
        if tool_call.function.name == "search_customers":
            args = json.loads(tool_call.function.arguments)
            results = db.search_customers(args["query"])
            # ... feed results back to model

This code works. Right now. For this model. In this application.

The debt isn't visible yet. The debt appears when:

• You want the same tool in a different application → copy-paste, diverge forever
• You switch from GPT-4 to Claude → the tool definition format is different, rewrite
• You want to use a specialised AI client (Cursor, Claude Desktop) → they can't use your custom function definitions, rewrite
• A colleague builds the same tool for their project → you now have two implementations of search_customers, slowly diverging

This is technical debt in its purest form: a decision that makes today faster at the cost of tomorrow's flexibility.

The Root Cause: Integration Without a Standard​

The underlying problem isn't that your code is bad. It's that you're implementing the integration layer from scratch, with no standard to ensure interoperability.

Every AI provider has slightly different function-calling APIs:

• OpenAI: tools array with type: "function" wrappers
• Anthropic: tools array with different schema structure
• Google: function_declarations in a different format altogether

Every AI client has different integration mechanisms:

• Claude Desktop: process-based, reads config JSON
• Cursor: extension-based, different config format
• Your custom chat UI: whatever you built last year

Without a standard, you're writing N × M integrations, where N is the number of tools and M is the number of clients/models. Every combination is custom. Every combination is technical debt.

MCP as the Technical Debt Cure​

MCP changes the equation. Instead of N × M integrations, you write N + M.

Write your search_customers Tool in an MCP server once. It works with every MCP-compatible AI client: Claude Desktop, Cursor, GitHub Copilot, any agent framework that implements the spec. Write your client integration once (or just configure a supported client). It works with every MCP server.

The math is simple. The implications are significant.

"But I'm Moving Fast Right Now"​

The most common objection: "MCP is extra complexity I don't need yet."

Let me challenge that framing. Writing a custom tool integration isn't "moving fast." It's taking on debt with a high interest rate. You will pay that debt: when you switch models, when you add a second client, when a colleague needs the same tool, when you need to audit every place your database is accessed by an AI.

MCP is not extra complexity. It's upfront complexity in exchange for long-term simplicity. It's the architectural equivalent of writing a test, it costs time now, saves time continuously.

The developers who say "we'll standardise later" are the same developers who rewrite their entire data access layer after three years of accumulated debt. Standardising later always costs more than standardising now.

The One Valid Exception​

If you're building a one-off prototype that will be thrown away after a demo, hardcode everything. Life's short. Ship the prototype.

The moment "prototype" becomes "this is what we're building on," you're in the technical debt danger zone. The prototype's tool integration doesn't get deleted, it becomes the foundation. And foundations matter.

The Migration Path​

Already have custom tool integrations? Migration to MCP is mechanical, not creative:

1. Extract your tool's execution logic into a standalone class
2. Wrap it in an MCP server with the appropriate Tool definition
3. Replace your custom function-calling code with an MCP client connection
4. Delete the old integration code

For most tools, this is a day's work. For a large system with many tools, a week. The payoff is proportional to how many clients and models you eventually want to support.

A Standard Is Not a Constraint, It's a Superpower​

I want to end with a mindset shift.

Standards feel like constraints when you first encounter them. You have to learn the protocol. You have to implement a server. You can't just hack a function call directly.

But standards are how ecosystems are built. HTTP felt like overhead until the entire web was built on it. USB-C felt like a forced migration until you stopped carrying five chargers.

MCP is the point where AI tool integration stops being a proprietary, application-specific concern and becomes a shared, ecosystem-level capability. Every server you build contributes to that ecosystem. Every server someone else builds is a server you might not need to build.

Build MCP servers. Not because it's easier today, it might not be. Because it's the only thing that doesn't become technical debt tomorrow.

Ready to start? The Java SDK course takes you from "what even is an MCP server" to production-grade deployment. The MCP Fundamentals course gives you the theory first, if you prefer to understand before you build.

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.

The Three Laws​

Law 1 (Tools): The AI may act, but only through declared, validated interfaces.

Law 2 (Resources): The AI may observe, but only read, never modify.

Law 3 (Prompts): Humans may invoke structured workflows; the AI executes but does not initiate.

Simple rules. Complex implications.

Law 1: Tools (The AI Acts)​

A Tool is the mechanism through which an AI model takes action in the world. Call an API. Write a file. Insert a database record. Send a message.

The crucial design principle here is model-invoked. When you define a Tool, you're telling the AI: "When you judge that this action is appropriate, you may perform it." The model decides. You define the action and its parameters.

This is both powerful and slightly terrifying if you think about it too long.

The validation part of Law 1 matters enormously. Tools have JSON Schema-defined parameters. The SDK validates incoming tool calls against the schema before your handler runs. But JSON Schema validates structure, not semantics. A run_sql tool that validates that query is a string doesn't prevent the model from running DROP TABLE users. That's why:

• Tool scope should be as narrow as possible
• High-risk tools should have the risk encoded in their names
• Your handler must perform semantic validation the schema can't express
• Destructive tools should ideally require host-level user confirmation

When I see a manage_everything MCP tool that accepts raw SQL, I see a liability. When I see search_orders, update_order_status, and cancel_order, I see three safe, auditable tools.

The counterintuitive guidance: More, smaller tools are better than fewer, broader ones. The AI can reason about specific tools more accurately than Swiss-army-knife tools.

Law 2: Resources (The AI Observes)​

A Resource is data the AI can read. Files. Database records. API responses. Log streams. The AI doesn't modify Resources, it consumes them as context.

The safety property is clear: if the AI can only read a Resource, it cannot corrupt your data by accident. A hallucinating model with access to a filesystem Resource can read the wrong file. A hallucinating model with a filesystem write Tool can delete it.

The design principle that most developers miss: Resources shouldn't just be "the read-only version of a Tool." They should be identified by stable URIs that the application (not the model) can decide to attach to context.

This is a subtle but important difference. A Tool is called when the model thinks it's a good idea. A Resource can be pre-fetched by the host application before the conversation even starts. Claude Desktop can attach a resource to every conversation in a project. A Cursor workspace can always have the relevant codebase resources available.

This means Resources enable ambient context, the AI always knows about certain data, not just when it explicitly decides to look.

The test for Resources vs. Tools: "Does this operation have side effects?" If yes → Tool. If no → Resource. It's almost always that simple.

Corollary: if you find yourself building a get_user Tool, it should probably be a users://{userId} Resource. Save the Tools for update_user.

Law 3: Prompts (Humans Invoke, AI Executes)​

Prompts are the most frequently misunderstood primitive. They're not instructions the AI sends to itself. They're instruction templates that humans explicitly invoke from the host UI.

Think of them as slash commands with arguments:

• /code-review language=java focus=security
• /standup-summary team=backend
• /explain-error log-level=error component=payment-service

The human chooses to invoke a Prompt. The Prompt expands into a carefully crafted conversation structure, system messages, context, initial user message, designed to produce high-quality, consistent AI output for that specific task.

Why this matters: Without Prompts, every developer on your team writes their code review instruction differently. "Review this code" produces mediocre results. "You are an expert Java security engineer. Review the following code for SQL injection vulnerabilities, insecure deserialization, missing input validation, and authentication gaps. For each issue, cite the CWE, provide a severity rating, and show the corrected code." produces good results. But who writes that every time?

Prompts let you write the expert instruction once and distribute it to everyone through their AI tool.

The Asimov parallel: Law 3 is the one about human control. Tools can run autonomously. Resources can be ambient. But Prompts are explicitly human-initiated. The AI doesn't invoke a Prompt, humans do. This preserves human agency for high-level workflow initiation while letting the AI operate autonomously at the execution level.

When the Laws Conflict​

Asimov's genius was in the conflicts between his laws. The MCP primitives have their own tensions:

"Should I make this a Tool or a Resource?"

The primary question is side effects. But there's a secondary question: control. If you want the model to autonomously decide when to fetch data, you need a Tool (the model decides). If you want the host application to control what data is available to the model, you want a Resource (the application decides).

"Is this a Resource or a Prompt?"

Resources provide data. Prompts provide instructions. A resource with product documentation is data. A prompt that says "review this product documentation for inconsistencies and suggest improvements" is an instruction template. Often you use both together: the Prompt includes an embedded Resource reference.

"Do I need a Tool if I already have a Prompt for this?"

Yes. A Prompt for "search for customers" that the user invokes is different from a Tool for search_customers that the AI invokes autonomously mid-conversation. They serve different use cases and you might want both.

The Framework in Practice​

Here's how I think through a new capability when building an MCP server:

1. Does it write, modify, or have side effects? → Tool (with careful scope definition)
2. Does it read stable, addressable data? → Resource (with a meaningful URI)
3. Is it a recurring, high-quality workflow? → Prompt (that wraps Tools and Resources)
4. Could it be both a Tool and a Resource? → Yes, and that's fine. Implement both.

The laws give you a framework. They don't make every decision for you. But they prevent the most common mistakes: read-only operations implemented as Tools (losing the composability benefit of Resources), and write operations implemented as Resources (breaking the safety contract).

The Philosophical Point​

I started with Asimov because the analogy runs deeper than it seems.

Asimov's laws were about the relationship between robots and humans, about who has agency and who has authority. Law 1 (don't harm humans) prioritises human safety. Law 2 (obey humans) prioritises human authority. Law 3 (protect yourself) enables robot agency within those bounds.

MCP's three primitives encode a similar relationship between AI and the systems it operates in:

• Tools encode that the AI can act, but only through declared, safe interfaces
• Resources encode that the AI can know, but only through read-only access to data
• Prompts encode that humans can direct, and the AI will follow high-quality structured guidance

These aren't just implementation details. They're a philosophy of how AI should be integrated into production systems: capable but bounded, powerful but controlled, autonomous but within declared limits.

Asimov's laws failed in the stories because real situations are too complex for simple rules. MCP's three primitives work because they're not about ethics, they're about a clean architectural separation of concerns. And that, as we've known for decades, is where software elegance lives.

Want to build servers that implement these three primitives correctly?

Start with MCP Fundamentals for the theory, or jump straight to Building MCP Servers in Java if you learn better by doing.

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.

The Cable Bag Problem​

Before I explain MCP, let me describe what it's replacing.

If you've built any kind of AI-powered application in the last two years, you've built some version of this:

1. You identified a capability the AI needed: search the database, read a file, call an API.
2. You wrote the integration: a function definition in the model's API format, a handler that executes the function, a result-formatting step that feeds the output back.
3. You moved to the next capability and did it again.
4. Three months later, you want to use a different AI model. The function definition format is different. You rewrite everything.
5. Six months later, you want to use the same capabilities in a different application. You copy-paste the code, adapt it, and maintain two versions forever.

Every integration is a custom cable. And custom cables don't interoperate.

This isn't an exotic problem. Ask any developer who's built an AI-powered product in the last two years. They've all got the cable bag.

What a Standard Actually Does​

A standard is a shared contract. Both sides agree to implement it, and interoperability follows automatically.

USB-C's contract: these are the pin layouts, these are the signal specifications, this is the power delivery protocol. Every manufacturer who implements the spec creates a device that works with every other USB-C cable and device.

MCP's contract: this is how a client discovers an AI server's capabilities. This is how a tool call is structured. This is how results are returned. Every client that implements MCP can talk to every server that implements MCP.

The underlying technology didn't change. Databases still query the same way. APIs still return JSON. Files still sit on filesystems. What changed is that there's now a single, agreed-upon way to connect an AI to all of it.

The Three Plugs​

USB-C replaced the mess with one port. MCP replaces the mess with three concepts:

Tools, the AI does things. Creates records. Calls APIs. Sends messages. Writes files. Tools are model-invoked: the AI decides autonomously when to call a tool based on the conversation context.

Resources, the AI reads things. Database records. File contents. API responses. Live metrics. Resources are application-invoked: the host decides what context to provide to the AI, or the user explicitly attaches resources to a conversation.

Prompts, the AI follows templates. Predefined, parameterised instruction recipes that appear in the client UI as slash commands or workflow options.

Tools, Resources, and Prompts. You could argue this is overly elegant, why not just "functions"? But the three-way distinction encodes something important: not everything the AI can access should be treated as something the AI can modify. Resources are read-only by design. That's a safety property, not just a naming convention.

Adoption: The Real Test of a Standard​

A specification document is a proposal. Adoption is the proof.

Within months of Anthropic publishing MCP (November 2024), it was integrated into:

• Cursor, the AI-native code editor
• GitHub Copilot, Microsoft's AI coding assistant embedded in VS Code
• Zed, the editor built for AI-assisted development
• Continue, the open-source AI coding assistant
• Claude Desktop, Anthropic's own application
• Windsurf, Cline, LibreChat, and a growing list of agentic tools

By late 2025 the community had published a wide range of MCP servers on GitHub, covering Git providers, databases, communication tools, filesystem access, browser automation, and more. In December 2025 MCP became a founding project of the Agentic AI Foundation (AAIF), a Linux Foundation directed fund whose technical projects include MCP, goose, and AGENTS.md, formalising MCP as a vendor-neutral industry project.

This is what successful standards look like. Not a committee. Not a consortium. A specification that solved a real problem, published openly, adopted rapidly because developers were tired of the alternative.

What This Means for You​

If you're building AI applications, you have a choice:

Option A: Continue building custom integrations. Each one is tailored to your specific application and model. Each one is maintained separately. When you want to use a different AI host, you rewrite the integration layer.

Option B: Build MCP servers. Each server works with any MCP-compatible AI client. You write it once. It composes with other servers. When Cursor adds a new feature that leverages MCP, your server benefits automatically.

Option A is the cable bag. Option B is USB-C.

The economic case is clear: every hour you spend building a custom AI integration is an hour you could spend building the thing your application actually does. MCP doesn't just solve a technical problem, it saves engineering time at scale.

Not Every Cable Is USB-C Yet​

A few honest caveats:

MCP is still young. The spec is evolving. Some authentication patterns are still being standardised. Some client implementations are more complete than others. The Java ecosystem is behind TypeScript and Python in terms of community servers, though the official SDK is solid.

And USB-C took years to fully displace its predecessors. Some devices still ship with Micro-USB. Some cables are USB-C in shape but not in capability. Standards win gradually, then suddenly.

MCP is in the "gradually" phase. But the trajectory is clear.

Get Started​

If you want to understand MCP before you implement it, the MCP Fundamentals course covers the theory from first principles, no code required.

If you want to build in Java, the Java SDK course takes you from environment setup to a production-ready HTTP server.

One standard. All the tools. No more cable bags.

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.

The Brilliant Prisoner Problem​

Imagine the world's most knowledgeable professor. She's read every book, every research paper, every technical document ever written. Her recall is perfect. Her reasoning is exceptional. She can synthesise ideas across disciplines in seconds.

Now lock her in a room.

She gets messages slipped under the door. She writes responses and slips them back. The advice is brilliant. The analysis is excellent. But ask her to check something on your company's internal dashboard, and she stares at the ceiling. She doesn't have internet access. She doesn't have access to your systems. She doesn't have access to anything that happened after the last time someone updated her training data.

That's a large language model. GPT-4, Claude, Gemini, it doesn't matter which one. They all share this fundamental limitation: they know a staggering amount about the world as it was when they were trained, but the real world is a live, dynamic system they cannot directly observe.

The Brute-Force Solutions​

Developers are creative people. We don't wait for elegant solutions when we need something to work today. So before MCP, we built work-arounds:

Prompt stuffing. Copy the relevant data, paste it into the prompt. Need the AI to analyse your latest sales figures? Paste the CSV. Need it to review a database record? Copy the row. This works until the data is too large, too dynamic, or too sensitive to paste.

Custom tool calls. OpenAI's function-calling feature (2023) let you define functions the model could invoke. The model would produce a function call; your code would execute it; you'd feed the result back. Brilliant. Except: every application reinvented this from scratch, for every model, every tool, every use case. There was no standard. The integration you built for GPT-4 didn't work with Claude. The tool you wrote for your chatbot didn't work in your code assistant.

RAG without standards. Retrieval-Augmented Generation let models fetch relevant documents from a vector database at query time. Excellent for static knowledge. Not great for "what's currently in the order queue" or "what does this API endpoint return right now."

None of these are wrong. They're all useful. But they're all reinventing the wheel.

MCP: A Standard for the Integration Layer​

In November 2024, Anthropic open-sourced the Model Context Protocol, a specification for how AI applications should connect to external tools and data sources.

The elegant insight behind MCP is that the integration layer was the problem, not the tools themselves. Everyone was building database connectors, filesystem tools, and API bridges. The tools worked. But there was no standard for how an AI application was supposed to talk to them.

MCP provides that standard:

• Define a Tool once: the AI can call it to take actions
• Define a Resource once: the AI can read it for context
• Define a Prompt once: users can invoke structured workflows

Build your database MCP server once. It works with Claude Desktop. It works with Cursor. It works with GitHub Copilot. It works with your custom agent. Stop writing the same integration four times.

What "Flying Blind" Actually Means​

Here's a concrete example of what changes.

Before MCP: You're debugging a production issue. You paste the last 50 lines of the log into Claude. You paste the relevant code. You describe what you think the problem might be. You wait. Claude gives you a plausible but potentially wrong answer because it's working from a snapshot you curated, not from the live system.

With MCP: Your AI assistant has a filesystem MCP server and a database MCP server connected. You say "why is the payment service erroring?" The assistant reads the live logs directly (via a Resource). It queries the relevant database tables to check transaction state (via a Tool). It examines the actual service code (via the filesystem Resource). It gives you an answer grounded in what's actually happening, not what you remembered to paste.

The AI isn't flying blind anymore. It can see.

Why It's Different This Time​

"AI + tools" sounds like a solved problem. We had plugins. We had function calling. We had RAG. What makes MCP different?

Standards. USB-A worked. USB-B worked. MicroUSB worked. But nobody was happy about carrying four cables. USB-C isn't a new technology; it's a standard that ended the fragmentation. MCP isn't new technology; it's the standard the AI tool ecosystem has needed.

Adoption velocity. The sign that a standard is working isn't the spec document, it's adoption. Within months of publication MCP was integrated into Cursor, GitHub Copilot, Zed, and dozens of other tools. By late 2025 the community had published a wide range of MCP servers on GitHub, and in December 2025 MCP became a founding project of the Agentic AI Foundation (AAIF), a Linux Foundation directed fund whose technical projects include MCP, goose, and AGENTS.md. Vendor-neutral governance was the official seal on what adoption had already proved. When a standard solves a real problem, adoption is fast.

Open ecosystem. MCP is not Anthropic-proprietary. The spec is open. Any model, any client, any server can implement it. That's the difference between a standard and a vendor feature.

Where to Go From Here​

If this sparked something, you're in the right place. TheMCPGuy is built to be the definitive learning resource for MCP, from theory to production Java implementation.

Start with MCP Fundamentals, eight modules covering everything from the architecture to the security model, without writing a single line of code. Understand the protocol before you implement it.

Then, when you're ready to build, the Java SDK course takes you from zero to a production-grade MCP server in Java.

Your AI has been flying blind long enough.