Summary

Problem: Claude Desktop has a hard-coded 4-minute timeout that causes long conda operations (installing ML frameworks, resolving dependencies) to fail, even though the operation continues in the background.

Solution: Implement MCP Tasks feature (native to MCP spec) to support long-running operations with progress tracking.

Impact: Currently blocks Claude Desktop usage for realistic data science workflows.

Context

I'm developing demos for anaconda-mcp targeting different audiences:

• Claude Code: Developers/data scientists (primary)
• Claude Desktop: Non-technical users, students, educators (secondary)

Why Claude Desktop matters: It significantly expands the potential user base by providing a GUI-based approach for users who aren't comfortable with terminal tools. This is particularly valuable for onboarding, education, and demonstrations.

However, Claude Desktop's 4-minute timeout makes it unsuitable for realistic conda operations.

Description

Problem

When creating large conda environments through Claude Desktop using anaconda-mcp, operations frequently time out. When this happens, Claude receives no response and falls back to providing manual instructions instead of completing the environment creation.

Real example: https://claude.ai/share/10ba626f-467c-40ff-8829-7c1669cbabfc

This creates a confusing user experience where:

• Small environments work perfectly
• Large environments appear to "fail" silently
• Users don't understand why the AI can't complete the task
• The actual conda create command may still be running in the background

Steps to Reproduce

Confirmed reproduction steps from actual usage:

1. Set up Claude Desktop with anaconda-mcp via conda install
2. Ask Claude: "List my conda environments" → ✅ Works (< 1 second)
3. Ask Claude: "Create an environment with pytorch, polars, and jupyterlab" → ✅ Works (2min 35sec)
4. Ask Claude: "Add transformers to the torch-polars environment" → ❌ Timeout after exactly 4 minutes

Result: Claude returns: "The request timed out" with manual instructions

Root Cause

There are TWO timeout layers:

Layer 1: Claude Desktop → anaconda-mcp (THE ACTUAL PROBLEM)

• Timeout: 4 minutes (hard-coded in Claude Desktop)
• NOT configurable by users or anaconda-mcp
• This is what fails in the reproduction steps above

Layer 2: anaconda-mcp → environments-mcp-server

• Timeout: 30 seconds (configurable in mcp_compose.toml)
• File location: /opt/anaconda3/envs/[ENV_NAME]/lib/python3.13/site-packages/anaconda_mcp/mcp_compose.toml.template

[[servers.proxied.streamable-http]]
name = "conda"
url = "http://localhost:4041/mcp"
timeout = 30  # <-- Server-to-server timeout

From actual log analysis:

• Request 6 started at 15:48:04
• Claude Desktop cancelled it at 15:52:04 (exactly 4 minutes later)
• Error: "McpError: MCP error -32001: Request timed out"
• The environments-mcp-server was still processing (no server error)
• Increasing the Layer 2 timeout to 600s didn't help because Layer 1 hit first

Expected vs Actual Behavior

Expected:

• Large conda operations complete successfully (even if they take 5-15 minutes)
• User receives confirmation when operation is complete
• Or: Progress updates during long operations

Actual:

• Operations timeout after exactly 4 minutes (Claude Desktop's limit)
• Error message: "Request timed out" with manual fallback instructions
• The conda operation may still be running in the background (no way to check)
• No indication of progress or remaining time
• Inconsistent behavior: some operations succeed (< 4 min) while others fail (> 4 min)

Observed timings:

• List environments: < 1 second → ✅ Success
• Create environment (pytorch, polars, jupyterlab): 2min 35sec → ✅ Success
• Install transformers: > 4 minutes → ❌ Timeout

Impact

This significantly reduces the value proposition of anaconda-mcp for real-world use cases:

• Demo scenarios with small/fast environments: ✅ Works great
• Production use with realistic package sets: ❌ Frequent timeouts
• User trust: Confusing when AI "gives up" without explanation
• Unpredictable behavior: Same package may succeed or timeout depending on network/cache
• Resource waste: Operations continue running in background after timeout

Real-world operations that commonly take > 4 minutes:

• Installing ML frameworks (tensorflow, pytorch, transformers, scikit-learn)
• Adding packages to existing environments (complex dependency resolution)
• First-time package downloads on slower networks
• Creating large data science stacks
• Installing packages with native dependencies (opencv, scipy)

Environment

• anaconda-mcp version: 1.0.1 (via conda install -c anaconda anaconda-mcp)
• environments-mcp-server version: 1.0.0
• Claude Desktop: Claude 1.569.0 (49894a)
• OS: macOS Sequoia 15.7.1
• Conda: 26.1.1
• Python: 3.13

Current Workaround

Option 1: Switch to Claude Code (CLI)
Claude Code does not appear to have the same aggressive timeout as Claude Desktop.

Pros ✅:

• Works for long-running operations
• Better suited for developer workflows

Cons ❌:

• Requires terminal comfort
• Not accessible to non-technical users
• Eliminates the approachability benefit of Claude Desktop
• Limits audience reach for demos and education

Option 2: Use Claude Desktop with manual fallback

1. Try the operation via Claude Desktop
2. Wait for inevitable timeout (4 minutes)
3. Copy the manual command Claude provides
4. Run it in terminal themselves
5. Wait 5-15 minutes for completion
6. Come back to Claude Desktop

Why this is problematic:

• Defeats the purpose of AI automation
• Confusing user experience
• Users don't know when to expect timeouts
• Requires terminal access anyway (negating Desktop's advantage)

Suggested Solutions

Option 1: Use MCP Tasks Feature (RECOMMENDED)

MCP has native support for long-running operations through the Tasks feature (MCP spec v2025-11-25). This is what the specification was designed for.

Why this is the right solution:

• ✅ Native MCP feature - Not a custom workaround
• ✅ Standardized - All MCP clients will support it
• ✅ No timeout limits - Operations can run indefinitely
• ✅ Better UX - Built-in progress notifications
• ✅ Works for both Claude Desktop and Claude Code
• ✅ Handles cancellation - Users can cancel long operations
• ✅ Automatic cleanup - TTL-based resource management

How MCP Tasks Work:

1. Mark long-running tools with task support:

{
  "name": "conda_create_environment",
  "description": "Create conda environment (5-15 minutes)",
  "execution": {
    "taskSupport": "optional"
  }
}

2. Tool returns immediately when called with task parameter:

// Request
{
  "method": "tools/call",
  "params": {
    "name": "conda_install_packages",
    "arguments": { "environment": "torch-polars", "packages": ["transformers"] },
    "task": { "ttl": 3600000 }
  }
}

// Immediate response
{
  "result": {
    "task": {
      "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
      "status": "working",
      "ttl": 3600000,
      "pollInterval": 5000
    }
  }
}

3. Client polls automatically using native MCP operations:

   • tasks/get - Check current status
   • tasks/result - Retrieve final result after completion
   • tasks/cancel - Cancel operation if needed

4. Server sends status notifications (optional):

   {
     "method": "notifications/tasks/status",
     "params": {
       "taskId": "786512e2...",
       "status": "working"
     }
   }

Example user experience:

User: "Install transformers in torch-polars"

[Claude calls conda_install_packages with task augmentation]
Response: {"taskId": "786512e2...", "status": "working", "pollInterval": 5000}

Claude: "Started installing transformers. This usually takes 5-10 minutes..."

[Claude automatically polls tasks/get every 5 seconds]
[Server can send status notifications]

[After 6 minutes]
[Claude calls tasks/result]
Response: {"content": [{"type": "text", "text": "Successfully installed transformers"}]}

Claude: "✓ Done! Transformers is now installed in torch-polars environment"

Implementation Steps:

1. Declare task support in server capabilities:

{
  "capabilities": {
    "tasks": {
      "list": {},
      "cancel": {},
      "requests": {
        "tools": { "call": {} }
      }
    }
  }
}

2. Update long-running tools (conda_create_environment, conda_install_packages, etc.):

   • Add execution.taskSupport: "optional" to tool schema
   • When request includes task parameter → return immediately with CreateTaskResult
   • Launch conda operation in background thread/process
   • Track task state and manage TTL

3. Implement task endpoints:

   • tasks/get - Return current task status
   • tasks/result - Return final result once completed
   • tasks/cancel - Cancel running conda operation
   • tasks/list - List active tasks (optional)

4. Resource management:

   • Enforce reasonable TTL limits (e.g., 1 hour max)
   • Limit concurrent tasks per session
   • Clean up expired tasks automatically
   • Store task state (in-memory or simple DB)

Reference Documentation:

• MCP Tasks Spec: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks
• Server Tools Reference: https://modelcontextprotocol.io/specification/2025-11-25/server/tools

Option 2: Add Warning/Guidance in Tool Descriptions

Update tool descriptions to warn users about expected duration:

• "⚠️ Large environments may take 5+ minutes. For operations longer than 4 minutes, Claude Desktop will timeout. Consider using Claude Code for complex installations."

Document in README/docs:

• Expected timeout behavior
• When to expect timeouts (environment size/complexity)
• Workarounds for large environments

Pros: Quick, helps set expectations
Cons: Doesn't solve the problem, limits Claude Desktop usefulness, poor UX

Related Code References

• Config file: src/anaconda_mcp/mcp_compose.toml (line 47)
• Test timeout: tests/qa/mcp_tools/common/constants/config.py (line 24)
• Documentation: docs/CONFIGURATION_GUIDE.md (shows timeout = 30 as example)

Questions for Maintainers

1. Is Claude Desktop support a priority, or should it be documented as "best-effort"?
2. Are there technical/architectural constraints that would prevent implementing MCP Tasks?
3. Should we add runtime warnings when operations are likely to exceed 4 minutes?
4. Does Claude Code have different timeout behavior? (Testing suggests it's more lenient)