🚨 CRITICAL BUG: cursor-agent CLI MCP STDIO Transport Failure

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

:police_car_light: CRITICAL BUG: cursor-agent CLI MCP STDIO Transport Failure

:clipboard: Summary

cursor-agent CLI completely fails to handle structured MCP responses over STDIO transport that work perfectly in Cursor IDE, causing indefinite hangs for any production MCP server that returns content arrays.

:bullseye: Impact

  • CRITICAL: CLI MCP unusable for any real-world MCP server
  • BLOCKS: Production CLI agent workflows and automation
  • INCONSISTENT: Same MCP server works in IDE but fails in CLI
  • SILENT FAILURE: CLI hangs indefinitely with no error messages

:microscope: Root Cause

The CLI and IDE use different MCP STDIO transport implementations. CLI cannot process structured MCP responses ({"result": {"content": [...]}}) over STDIO that are standard in the MCP specification and work perfectly in IDE.

:bar_chart: Evidence

:white_check_mark: MCP Server Response (Standard Format)

Any MCP server returning structured content causes this bug:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "This is a standard MCP response that works in IDE"
      },
      {
        "type": "resource", 
        "resource": {
          "uri": "example:data",
          "text": "Additional structured data"
        }
      }
    ]
  }
}

:white_check_mark: IDE Behavior (Working)

  • Discovers MCP server correctly
  • Calls tools successfully
  • Renders structured content arrays perfectly
  • Shows formatted text, handles resources, supports full MCP spec

:cross_mark: CLI Behavior (Broken)

  • Discovers MCP server correctly :white_check_mark:
  • Calls tools successfully :white_check_mark:
  • Hangs indefinitely on structured responses :cross_mark:
  • No error messages, no timeout, requires manual kill
  • Same response that works in IDE causes complete failure

:magnifying_glass_tilted_left: Technical Analysis

STDIO Transport Layer Mismatch

  1. IDE MCP STDIO Client: Handles full MCP specification including content arrays over STDIO
  2. CLI MCP STDIO Client: Expects plain text responses over STDIO, cannot process structured content
  3. Server STDIO Response: Valid MCP JSON-RPC with content arrays sent via STDIO (per spec)
  4. CLI STDIO Processing: Fails silently, waits indefinitely for different format over STDIO

Key Evidence Points

  • Same server, same response: Works in IDE, fails in CLI
  • Standard MCP format: Response follows MCP specification exactly
  • No error handling: CLI provides no feedback about processing failure
  • Infinite hang: No timeout mechanism, requires manual termination

:bullseye: Required Fix

Immediate (Critical)

  1. Add timeout: Prevent infinite hangs (30s default)
  2. Extract text content: Basic fallback for structured responses
    • Parse response.result.content array
    • Extract text field from items with type: "text"
    • Display concatenated text content to user
    • Ignore other content types (resources, images) for now

Complete (Long-term)

  1. Unified MCP STDIO client: Use same STDIO transport layer as IDE
  2. Full content array support: Handle text, resources, images per MCP spec over STDIO
  3. Error reporting: Show meaningful errors instead of silent hangs on STDIO

:wrench: Workaround

Currently, the only workaround is to use Cursor IDE instead of CLI for any MCP functionality.

:clipboard: Validation

After fix, this should work without hanging:

  • cursor-agent --print "use any MCP tool that returns structured content"
  • Should output: rendered text from content arrays
  • Should NOT: hang indefinitely

:bullseye: Success Criteria

  • CLI doesn’t hang on structured MCP responses
  • CLI renders text content from MCP content arrays
  • CLI shows errors instead of silent failures
  • CLI has reasonable timeout for MCP operations
  • CLI achieves feature parity with IDE MCP handling

This is a STDIO transport layer bug affecting all production MCP servers. The MCP specification requires structured content arrays over STDIO, but CLI cannot process them while IDE handles them perfectly.

:telephone_receiver: Reporter

  • Environment: macOS, Node.js v23.6.0, Latest Cursor
  • Reproduction: 100% reproducible with any MCP server returning content arrays
  • Urgency: High - blocks CLI adoption for MCP workflows

Steps to Reproduce

:test_tube: Reproduction Steps

The Bug Pattern

  1. Create any MCP server that returns structured content arrays in the standard MCP format
  2. Configure it in ~/.cursor/mcp.json with STDIO transport (standard setup)
  3. Test in Cursor IDE: Works perfectly - renders content arrays correctly
  4. Test in cursor-agent CLI: Hangs indefinitely on the same structured responses

Observable Behavior

  • IDE Success: Same MCP server and responses work flawlessly in Cursor IDE chat
  • CLI Failure: cursor-agent --print "any MCP command" hangs forever
  • STDIO Transport: Both IDE and CLI use STDIO to communicate with MCP server
  • Response Format: Server returns valid {"result": {"content": [...]}} JSON-RPC
  • CLI Processing: CLI receives response but cannot process structured content arrays

Expected Behavior

Expected vs Actual Behavior

Component Expected Actual
MCP Server Returns structured content :white_check_mark: Works correctly
IDE Agent Renders content arrays :white_check_mark: Works correctly
CLI Agent Renders content arrays :cross_mark: Hangs indefinitely

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.44 (Universal)
VSCode Version: 1.99.3
Commit: 9d178a4■■■89981b62546448bb32920a8219a5d0
Date: 2025-10-10T15:43:37.500Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

reading this bug reports takes longer than actually fixing the problem. so much duplicate information.
you could have written a short well described report, instead you use ai to generate slop, now the team gotta use ai to deslopify it. amazing
still just my opinion though

2 Likes

Hey, thanks for the report. The team is already aware of this, we’ll fix it.

Haaaa. Plot twist…..Your comment complaining about my long bug report is longer than the actual fix would be. We’ve achieved peak inefficiency! :people_hugging: :laughing:

Perfect, thanks for the quick response! Glad to hear it’s already on the radar. Looking forward to the fix :saluting_face:

Well your comment didn’t age very well here, did it? :roll_eyes:

TBPH, I would rather have too much information than not enough, when it comes to a bug report. As you so…nicely…stated, you can use AI to process this, meaning you could extract or distill details with ease, IF that was what you wanted to do…

*SMH*

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.