What Tasks and MCP Apps Actually Change for Agent Infrastructure

Everyone is talking about the stateless core — no session IDs, request/response model, serverless-compatible. That's important infrastructure. But statelessness is a wiring change. Once you've absorbed it, you still need capabilities. And that's what the two official extensions — Tasks and MCP Apps — are meant to provide.

They didn't arrive on July 28 as beta experiments. They arrived as ratified extensions, part of the same specification that removed Mcp-Session-Id and the init handshake. This matters because it signals that the protocol authors don't see MCP as a finished wire format. They see it as a platform — and extensions are how new capabilities get added without everyone having to adopt them at once.

Tasks are what happens when tools take too long

Earlier MCP versions treated tool calls as a blocking request. The model sends tools/call, the server does the work, and the response comes back. For a file read or a simple API call, that's fine. It breaks down for anything long-running: compiling a codebase, running a test suite, deploying infrastructure, training a small model.

Those operations span minutes, not milliseconds. An agent waiting for a blocking response wastes tokens, ties up the model, and gives the user nothing useful to look at.

Tasks solves this with polling. The flow works like this:

1. The server returns a task handle instead of a final result. The handle has a unique taskId and a status field.
2. The client polls tasks/get with that taskId whenever it needs an update.
3. The task can be in one of five states: working, input_required (the server needs more data and can prompt the client), completed, failed, or cancelled.
4. The client can also call tasks/update mid-flight to supply data if the task requested it.

This matters because it moves the server from a synchronous helper to a job runner. The model submits work, disconnects, and checks back at intervals that make sense for the task. The server owns the lifecycle. This is how long-running agent tools are supposed to work.

There are sharp edges — the spec removed tasks/list from the earlier experimental API, so the client must track task IDs itself. A server can also return a task handle unsolicited, meaning it can create a task as a side effect of any request, not just within a dedicated task method. This gives implementers flexibility but requires clients to handle task references anywhere in the response.

As of August 2026, client support is still early. The Claude desktop app renders task progress inline in conversations, but Claude Code is still in uptake. For developers writing MCP servers today, the practical advice is:

• Wrap long operations in task IDs now, even if only for future-proofing.
• Return status and completion estimates so the client can display meaningful progress instead of a spinner.
• Don't remove your synchronous path yet — many clients haven't implemented the polling loop. Ship both.

2. MCP Apps: the UI that lives inside the agent conversation

Every integration that currently sends plain text could send an HTML page instead — graphs, forms, dashboards, diff views, previews. That's MCP Apps, formally SEP-1865, and it's the most significant user-facing change since MCP launched.

Here's how it works:

A server declares UI templates in its tool metadata. When the model calls a tool, the host renders the declared HTML in a sandboxed iframe. The rendered UI communicates back to the host over the same JSON-RPC protocol — and everything passes through the same consent layer as a direct tool call.

This is not a chat bubble. This is a real DOM inside the agent conversation. A fraud-detection MCP server could render a highlighted transaction timeline. An analytics server could render an interactive chart with date range sliders. A deployment server could render a step-by-step pipeline viewer with live log streaming.

Two design details that matter:

• Templates are declared ahead of time. The server lists its HTML templates in its tool definitions, so the host can prefetch, cache, and security-review them before a user ever triggers a tool call. This prevents the server from injecting arbitrary HTML at runtime.
• Graceful degradation is built in. If the host doesn't support MCP Apps, the server falls back to returning plain text or structured data. You don't need to guess whether the client has a rendering engine.

Both the desktop app and the web Claude interface already support MCP Apps on Claude's side. For server developers, this means: you can now ship a visual experience alongside your tool logic, and it reaches users through the same MCP serve that was previously limited to text.

3. Why this changes how developers should think about MCP servers

Before 2026-07-28, "making an MCP server" meant publishing a tool list: here are my functions, call them with JSON, I'll reply with JSON. A server was an API that spoke MCP instead of REST or gRPC.

With Tasks and Apps, the mental model shifts:

• A server becomes a service — it owns not just tool execution but the lifecycle of long-running work and the user interface for interacting with it.
• A tool call becomes a session — the client polls, the server reports, and the human sees interactive progress, not just a spinner.
• A response becomes a UI surface — charts, forms, and interactive components replace raw JSON in the conversation.

While this is all optional — no one is forced to implement Tasks or Apps — the signal is clear: the protocol team expects MCP to function as an agent runtime, not just a pipe for structured data. The extensions are the first proof that this vision is being shipped, not just announced.

What's next and what's still missing

Two gaps are still open as of August 2, 2026:

1. Client adoption is uneven. Tasks works on Claude (app, managed agents) and Azure Functions, but many community-hosted clients and edge deployments are still catching up. MCP Apps is currently Claude-only on the host side.
2. Tooling for server developers is nascent. There's no canonical debugger for polling-based tasks, no standard dashboard for viewing/app/task states, and no agreed-upon method for testing MCP Apps across different host implementations.

But the direction is right. A protocol that can handle long-running async work and interactive UI is a protocol that can serve professional agent workloads — not just hobby projects. The extensions are the signal that MCP is building for that.

The stateless core made MCP deployable. Tasks and MCP Apps make it functional.

Everything the lab builds in public stays in public. The source is on GitHub, and the current build is a live AI quoting engine for home service contractors.