Claude Code Now Lets Slow MCP Tools Run in the Background

Every team I train hits the same wall with MCP eventually. The first connector is a joy: Claude reads a Notion page, answers in two seconds, everyone nods. Then someone wires up a tool that does real work. A report export, a data sync, a build that takes four minutes. Claude calls it, and the whole session just sits there. Nothing else happens until the tool answers, or until it times out and you get an error for a job that was actually still running.

That is the problem MCP tasks are meant to solve, and as of this week Claude Code's terminal client supports them.

What shipped

The Claude Code changelog for version 2.1.319 (November 6) says: when an MCP server runs a tool call as a task, Claude Code moves it to the background right away and tells Claude the result when it finishes.

Two details from the same entry matter. Tasks now work in the terminal without feature-flag fetching, so they work on Bedrock, Vertex, Foundry, LLM gateways, and with DISABLE_TELEMETRY set. And there are two switches:

• CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND makes Claude Code wait for a task inside its tool call instead of backgrounding it.
• CLAUDE_CODE_DISABLE_MCP_TASKS=1 turns the whole thing off.

The idea in one picture

The underlying concept comes from the MCP spec's tasks proposal, SEP-1686. Its description of the old workaround is the clearest explanation I've seen: a server author who wanted a long-running tool had to split it into three tools. One to start the work and return a job ID, one to check status, one to fetch the result. Then they had to hope the model remembered to come back and poll.

Tasks make that pattern a first-class part of the protocol: call now, fetch later.

Where this earns its keep

I have not rebuilt any client workflows around this yet, so take what follows as the cases where I expect it to matter, not a field report.

Slow exports and syncs. Any connector that kicks off a job on someone else's system. If your MCP server wraps a data warehouse query or a document render, the call used to hold up everything. Now Claude can carry on with the part of the work that does not depend on it.

Parallel prep. Say Claude needs a long report and also needs to fix a failing test. The report call goes to the background, the test fix proceeds, and the result arrives when it arrives.

Fewer timeout ghosts. The worst version of the old behavior was a timeout on a job that kept running. Claude would report failure and retry, and now you had two jobs. A task has an identity, so the client is tracking the work instead of guessing.

What it won't do

Two caveats, because the framing around features like this tends to run ahead of the facts.

First, the server has to opt in. The changelog says this applies "when an MCP server runs a tool call as a task." A server that never speaks the tasks protocol behaves exactly as before. If you run a custom connector, the work is on your side of the fence: your server has to return a task instead of blocking.

Second, the spec itself is still moving. The SEP page says tasks shipped as experimental in the 2025-11-25 revision, and that the draft spec moves them into an extension. I covered that revision when it landed, in the MCP 2026 spec update post. If you built against the experimental version, check the official spec before assuming your server matches what clients now expect. I'd treat anything I say about the wire format as secondhand and read the SEP.

What I'd do this week

1. Update Claude Code and confirm you are on 2.1.319 or later.
2. List your slow connectors. Which of your MCP tools routinely take more than ten seconds? Those are the candidates.
3. If you build servers, test one. Pick the slowest tool, return it as a task, and watch whether the session stays usable while it runs.
4. If a background result surprises you, you now have a switch. CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND restores the wait-inside-the-call behavior while you work out what you want.

The small related item

While you are in the changelog: fast mode for Opus 4.8 was deprecated on October 30 and will be removed on November 30. After that, fast-mode requests on Opus 4.8 return an error rather than falling back to standard speed. The changelog's advice is to migrate to Opus 5.5 to keep the speedup. If you pinned a model in a script or a CLAUDE.md, search for it now, not on the 30th.

Why I care

The pattern I keep seeing in training is that people hit the ceiling of "Claude can read my tools" and then discover that real tools are slow, flaky, and long. A client that can hand off slow work and keep going is a quiet upgrade, and it moves Claude Code a step closer to how you'd actually delegate to a person: you don't stand over their shoulder while the export runs.

If you want to build your first custom connector, or wire Claude into the slow systems your team already depends on, that is the kind of hands-on work I do in private team training and 1:1 coaching. Book a 15-min call and bring the tool that keeps timing out.