MCP server tools not exposed to AI agent despite successful connection

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

MCP servers configured with command-based transport (command + args using npx) successfully connect and register tools, but those tools are never exposed to the AI agent in Agent mode. Both command-based (taskmaster-ai via npx) and URL-based (context7 via HTTPS URL) MCP servers show as connected with tools enabled in the MCP settings panel, but neither exposes tools to the AI agent.

Steps to Reproduce

  1. Configure a command-based MCP server in ~/.cursor/mcp.json:
{
  "mcpServers": {
    "taskmaster-ai": {
      "command": "npx",
      "args": ["-y", "task-master-ai"],
      "env": {
        "TASK_MASTER_TOOLS": "all",
        "ANTHROPIC_API_KEY": "..."
      }
    }
  }
}
  1. Restart Cursor completely
  2. Open MCP settings - server shows green status with “44 tools enabled”
  3. MCP logs show successful connection:
[info] Successfully connected to stdio server
[info] listOfferings: Found 44 tools
[info] Found 44 tools, 0 prompts, and 0 resources
  1. Tools are cached correctly in ~/.cursor/projects//mcps/user-taskmaster-ai/tools/ (44 .json files)
  2. Switch to Agent mode and ask the agent to use taskmaster tools
  3. Agent does not have access to any MCP tools

Expected Behavior

The 44 registered and cached tools should be available to the AI agent in Agent mode.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Cursor Version: 2.3.41
OS: macOS Darwin 25.2.0
MCP Server: task-master-ai (latest via npx)

For AI issues: which model did you use?

Sonnet 4.5, Opus 4.5, GPT-5.2

Additional Information

Actual Behavior:
Tools are discovered, registered, and cached, but never exposed to the AI agent. The agent cannot see or invoke any MCP tools from command-based servers.

Evidence:
taskmaster-ai: 44 tools enabled (green) - not accessible to agent
context7: 2 tools enabled (green) - not accessible to agent

Does this stop you from using Cursor

No - Cursor works, but with this issue

2 Likes

This actually stop me from using Cursor as MCP tools are critical to my workflow. Looking for a promptly fix!!!

1 Like

I’m running into this as well.

Cursor 2.3.41
Windows 11 / WSL
JIRA & Notion MCP Servers

Same issue

Hey, thanks for the detailed report. This is a known issue and the team is already working on a fix. The bug showed up in version 2.3.41 and affects all MCP users.

What’s happening is that the tools are being registered and cached correctly (as your logs show, 44 tools were found), but the agent can’t discover them.

Temporary workaround:

  • Open a new chat
  • Ask the agent: “list all MCP tools you have access to”
  • After that, the agent should be able to see the tools within that session

For the engineering team, we need the Request ID from the broken chat (three dots in the top right of the chat > Copy Request ID). Can you paste it here?

Related thread with the same issue: Agent chat "No MCP resources available" when trying to use MCP

I can confirm the work around partially worked. I tried with 2.3.41 and this did not seem to fix anything (still failing). I then tried re-installing 2.3.40, and 2.3.39 and both did not work. However, I tried 2.3.35 and the work around seemed to work. I used a new chat to ask for available tools, and then my other chat suddenly had access again. Maybe this info will help others that are blocked.

1 Like

I was having this same issue.
I found that changing the Settings > Network > HTTP Compatibility Mode = http/1.1 allowed cursor to see my mcp tools. (Also hard restart of Cursor, and new chat session)
Not sure if this is going to have other unintended consequences elsewhere, but so far so good.
However, it the “real” fix is released, I will def be changing back to http/2

your workaround doesn’t work. This is terrible, I can’t work without it.

Unfortunately this workaround does not work for me. Have tried many times and many variations. Any ETA on when a fix for this will arrive?

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