Cursor-agent CLI: MCP tool calls silently stopped working in 2026.04.17

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

MCP tool calls (mcpToolCall events) work in cursor-agent 2026.04.14-ee4b43a and silently fail in 2026.04.17-479fd04.

The agent sees MCP tool descriptors (verified via cursor-agent mcp list showing the server as “ready”), but when it tries to use a tool, zero mcpToolCall events are emitted. Instead the agent falls back to read-only listMcpResources/readMcpResource probes, then gives up or tries shell workarounds.

This is a regression — the same workspace, config, and prompts work on 2026.04.14 and fail on 2026.04.17.

Steps to Reproduce

  1. Create a workspace with .cursor/mcp.json defining a tools-only MCP server (one that exposes tools but no resources)
  2. Verify the server is ready: cursor-agent mcp list shows it as “ready”
  3. Run with the working version:
~/.local/share/cursor-agent/versions/2026.04.14-ee4b43a/cursor-agent \
  -p "Call the hoover MCP server's recall tool with query 'test'" \
  --workspace /path/to/workspace \
  --model claude-4-sonnet \
  --output-format stream-json \
  --approve-mcps \
  --trust \
  --force
  1. Observe mcpToolCall events in the stream-json output
  2. Run the same command with the broken version:
~/.local/share/cursor-agent/versions/2026.04.17-479fd04/cursor-agent \
  -p "Call the hoover MCP server's recall tool with query 'test'" \
  --workspace /path/to/workspace \
  --model claude-4-sonnet \
  --output-format stream-json \
  --approve-mcps \
  --trust \
  --force
  1. Observe zero mcpToolCall events — only listMcpResourcesToolCall and readMcpResourceToolCall

Expected Behavior

Agent emits mcpToolCall event when invoking an MCP tool:

{
  "type": "mcpToolCall",
  "providerIdentifier": "hoover",
  "toolName": "recall",
  "arguments": { "query": "test" }
}

This is what happens on 2026.04.14-ee4b43a.

ACTUAL BEHAVIOR

Agent emits only:

  • listMcpResourcesToolCall (finds no resources — server is tools-only)
  • readMcpResourceToolCall (fails — no resources to read)
  • Falls back to shell commands or gives up

Zero mcpToolCall events appear in the stream-json output.

Operating System

MacOS

Version Information

Working:
CLI Version 2026.04.14-ee4b43a

Broken:
CLI Version 2026.04.17-479fd04

For AI issues: which model did you use?

claude-4-sonnet (also reproduced with composer-2-fast and gpt-5.3-codex-fast — same behavior)

Additional Information

Impact:

  • Any MCP server that exposes tools but no resources is effectively unusable from cursor-agent CLI on 2026.04.17
  • The Cursor IDE is unaffected — CallMcpTool works there
  • Test harnesses that drive cursor-agent for automated MCP validation break silently

Workaround:
Pin to 2026.04.14-ee4b43a:

export CURSOR_AGENT_BIN="$HOME/.local/share/cursor-agent/versions/2026.04.14-ee4b43a/cursor-agent"

Evidence:

  • Ran identical test scenarios against both versions with same workspace, .cursor/mcp.json, model, and MCP approval state
  • Working version: 3 mcpToolCall events (full pipeline fired)
  • Broken version: 0 mcpToolCall events (agent used listMcpResources, then shell)

Related:

  • A separate test harness (project-nav) confirmed MCP tool calls working on 2026-04-14 (25/28 runs had mcpToolCall events)
  • This regression was initially misdiagnosed as “cursor-agent CLI doesn’t support MCP tool calls” — it does, but only on older versions

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

I can confirm the above is reproducible and thank you for reporting it! I was very frustrated thinking it was my MCP server that was at fault; however, the moment I downgraded the CLI to the verified working version specified in the post, everything started working again as expected.

The most frustrating part is that on my local machine (MacOS arm64) I’ve managed to got it working by adjusting my Docker image that spawns it from Python as a subprocess.

But the same exact image built for Ubuntu amd64 never worked.

The moment I’ve pinned the version, both builds started to work again!

6

Hey there @kevglynn

Thanks for the report! I believe this is quite a recent regression! We have an open bug ticket tracking reports of this, along with a few other forum threads.

We’ll update these threads when a fix is available.