Feature Request: Support MCP Task Mode (SEP-1686) for Background Tool Execution
Feature Request: Support MCP Task Mode (SEP-1686) for Background Tool Execution
Summary
Add client-side support for SEP-1686 Tasks, enabling MCP tools to run in background mode similar to how Bash commands support run_in_background.
Problem
Currently, MCP tool calls in Claude Code are synchronous and blocking. When Claude calls a long-running MCP tool (e.g., executing a Jupyter notebook cell that trains a model for 10 minutes), the entire conversation blocks until completion.
This is inconsistent with how Bash commands work - they support run_in_background: true which returns immediately and notifies when complete. MCP tools have no equivalent mechanism, even though the protocol now supports it.
Use Case: Research Workflows with Jupyter/IPython
I use an MCP server (scribe-notebook) that provides Jupyter kernel execution. Common workflow:
- Claude executes a cell that runs an experiment (5-30 minutes)
- Currently: Claude is blocked, I wait, context is wasted
- Desired: Claude continues working on other tasks, gets notified when cell completes
This pattern applies to any MCP server wrapping long-running operations:
- ML training/inference
- CI/CD pipelines
- Database migrations
- Browser automation
- External API workflows
Solution: Implement SEP-1686 Client Support
SEP-1686 ("Tasks") is an accepted MCP specification that adds:
- Task-augmented mode: Client requests a task ID instead of blocking
- Progress notifications: Server streams status updates
- Result retrieval: Client fetches results when ready
FastMCP 2.14+ already implements server-side support via @mcp.tool(task=True):
@mcp.tool(task=True)
async def execute_code(session_id: str, code: str, progress: Progress = Progress()):
await progress.set_message("Executing cell...")
result = await run_cell(session_id, code)
await progress.set_message("Done")
return resultThe server is ready - Claude Code just needs to:
- Send
progressTokenin tool requests to opt into task mode - Handle task IDs returned instead of blocking
- Display progress notifications (like Bash background tasks do)
- Allow continuing conversation while task runs
Proposed UX
Similar to Bash background commands:
Claude: I'll execute this training cell in the background.
[MCP tool running in background with ID: abc123]
Claude: While that runs, let me review your test file...
[Task notification: abc123 completed]
Claude: The training finished. Let me check the results...Why This Matters
- Consistency: Bash has
run_in_background, MCP tools should too - Efficiency: Don't waste context window on blocking waits
- Protocol alignment: SEP-1686 is accepted, servers are implementing it
- Research workflows: Long-running experiments are common in ML/research
Related Issues
- #1478 - MCP Notification-Driven Auto-Resume (closed as not planned, but predates SEP-1686)
- #1759 - Implementing background tasks via MCP servers
- #8712 - Background execution of MCP tools
9 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Any input here?
Tasksare a great feature of MCP and claude code should stick as close to being a reference client as possible, right?We would love to see this too. Tasks are perfect for a great User Experience during long running tasks, like running local data pipelines with sensitive data, or whatever takes longer than 30 seconds to run.
Analyzed what's needed — the MCP TypeScript SDK bundled into cli.js already has full SEP-1686 support (
callToolStream(),getTask(),getTaskResult(), polling loop, all schemas). The application layer just never calls it. Implementation analysis with scope assessment and UX proposal modeled on the existingrun_in_backgroundpattern: https://gist.github.com/phas02/53c4c7f355916f880d2b26a2df661bfcWorth noting there's a much simpler approach that could work alongside SEP-1686 — and it wouldn't require any protocol or server changes.
The Bash tool already has
run_in_background. Claude Code intercepts that param before execution, backgrounds the command, and notifies when it's done. The shell never sees the parameter. The same pattern could be applied to MCP tools:run_in_backgroundinto MCP tool schemastrue, Claude Code strips it from the input before forwarding to the MCP serverThis would work with every existing MCP server without any changes. I hit this building a Splunk MCP server where queries scan hundreds of millions of events and take 5-10 min. Right now the workarounds are all bad — async job/poll patterns in the server, background agents that can't get permissions, or just shelling out with curl.
SEP-1686 is the better long-term solution since it enables progress streaming from the server, but client-side backgrounding could ship now and cover the common case
Surprises me that Claude Code does not support this since I always considered Claude Code to be the reference MCP client implementation
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
🤌🤌🤌🤌
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.