Cursor-agent `-p` mode does not inject MCP server tools into agent context

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When running cursor-agent -p (headless agent mode), server-specific MCP tools (e.g. my_search_records, my_create_item) are never injected into the agent’s callable tool set — even though the MCP server is fully connected, authenticated, and cursor-agent mcp list-tools lists all tools correctly.

The agent reports these tools as unavailable and falls back to generic proxy tools only (mcp_task, list_mcp_resources, fetch_mcp_resource).

Steps to Reproduce

  1. Configure MCP server in ~/.cursor/mcp.json using stdio/supergateway bridge:
{
  "mcpServers": {
    "my-mcp-server": {
      "command": "npx",
      "args": ["-y", "supergateway", "--sse", "http://localhost:PORT/sse"]
    }
  }
}
  1. Verify MCP is connected and tools are listed:
cursor-agent mcp list
# Output: my-mcp-server: ready

cursor-agent mcp list-tools my-mcp-server
# Output: many tools listed (my_search_records, my_create_item, my_execute_action, etc.)
  1. Run agent in -p mode asking for custom tools:
cursor-agent -p --force --trust \
  --workspace /path/to/project \
  --model composer-1.5 \
  "List all tools available to you whose names start with 'my_'. Output them as a newline-separated list. If no my_ tools are available, say NONE."

  1. Agent responds: NONE

  2. Ask agent to list ALL available tools — only generic tools present:

codebase_search, run_terminal_cmd, grep, delete_file, web_search,
mcp_task, list_mcp_resources, fetch_mcp_resource

No custom tools appear despite many being listed by cursor-agent mcp list-tools.

Expected Behavior

Server-specific MCP tools listed by cursor-agent mcp list-tools should be injected into the agent’s callable tool set in -p mode — consistent with how Cursor IDE (non-headless Composer) behaves.

In Cursor IDE Composer, the identical MCP configuration correctly exposes all custom server tools as first-class callable tools. The -p CLI agent should behave the same way.

Operating System

MacOS

Version Information

CLI Version: 2026.03.18-f6873f7
OS: darwin (arm64)
Node.js: v25.7.0

For AI issues: which model did you use?

composer-1.5

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, great bug report, thanks for the detailed steps.

The first thing that stands out is that your command is missing the --approve-mcps flag. Without it, the CLI might not inject MCP tools into the agent context, even if the server is connected and mcp list-tools shows everything correctly. Try this:

cursor-agent -p --force --trust --approve-mcps \
    --workspace /path/to/project \
    --model composer-1.5 \
    "List all tools available to you whose names start with 'odoo_'. Output them as a newline-separated list. If no odoo_ tools are available, say NONE."

Second point, 592 tools is a lot. If --approve-mcps doesn’t help, it’s worth checking if it’s related to the tool count. For a quick test, connect an MCP server with a small number of tools and see if they show up in the agent context.

Let me know how it goes with --approve-mcps.

5

Hi Dean, thanks for the quick response.

Tested with --approve-mcps — unfortunately it doesn’t fix the issue. Running cursor-agent mcp enable my-mcp-server beforehand confirmed the server was already enabled and approved, so the flag had no effect. The agent still reports only the generic proxy tools (mcp_task, list_mcp_resources, fetch_mcp_resource) and none of the server-specific tools.

On the tool count point: the server has many tools, so I can’t rule that out as a contributing factor. I’ll test with a minimal server (a handful of tools) and report back.

For now it looks like a deeper injection gap rather than an approval issue — but happy to keep investigating if you have other suggestions.

6

Thanks for testing that. It confirms this isn’t an approval issue.

This looks like a real bug in how -p mode handles MCP tool injection. The tools load and show up in the list, but the headless flow doesn’t correctly pass them into the agent’s context. That’s why you only see the generic proxy tools mcp_task, list_mcp_resources, fetch_mcp_resource, and not the individual server tools. The IDE path doesn’t have this gap, which explains the different behavior you’re seeing.

I’ve flagged this with the team.

In the meantime, testing with a small MCP server would still help. If individual tools show up with 5 to 10 tools but not with 592, that points to a different code path like serialization or a size limit. If they still don’t show up at all, then it’s likely the injection gap. Either way, it’s useful data for the fix.

I’ll update this thread if there’s news. Let me know how the small server test goes.

9

Hi Dean, we’ve tested with a very light test MCP server exposing only 7 tools and the problem is the same. I look forward to hearing updates from your side.

10

Thanks for running the test. This confirms the issue isn’t related to the number of tools, it’s specifically the injection gap in headless mode. Good data.

I’ll update the thread when I have news.

11

Possibly related:

I have a local api and an mcp I (or well.. cursor) built configured for this, if I start the agent manually from the command line with --trust --approve-mcps -p "whatever"It can use the MCP just fine.

If I instead, from a dotnet worker application start an agent process with the same arguments using cmd.exe through System.Diagnostics.Process, it will fail reporting that “User rejected” or similar for the MCP. I verified the cmd process is running under my user.
After adding -–forcethe agent started by the dotnet worker works fine and can use the MCP server. Seems the -–approve-mcpsflag is not working properly, or at least the description is somewhat misleading.

1 Like
12

Hey, thanks for the extra context.

This does look related, but it’s different from the main bug in this thread. It seems like --approve-mcps depends on whether the process has a TTY or an interactive context. When you run the agent via System.Diagnostics.Process, stdin is probably not attached to a terminal, so the flag doesn’t work as expected, which leads to “User rejected”.

In this case, --force is the right option for programmatic runs because it skips all interactive checks. But I agree the --approve-mcps behavior here is not obvious. It should auto-approve MCP servers regardless of how it’s launched.

I’ve logged this. If you can, please share the exact “User rejected” error text and the CLI version. That’ll help with the investigation.

13

Yeah, keep in mind this is the output from the agent (the report it mentions adds nothing more, its just repeating this in more words):

Manager Instruction Status: Cannot mark as FAILED via MCP (tool call also rejected)

Attempted MCP Call:

Tool: test-update_manager_instruction_status
Board ID: b17b3c8f-1663-44be-95f1-1849e82830eb
Instruction ID: 20dc2bad-9f70-40e6-a9fb-c28241a47224
Intended Status: Failed
Intended Reason: "MCP server not accessible - see MCP_INTEGRATION_ERROR_REPORT.md"
Result: Tool rejected: User rejected MCP: test-update_manager_instruction_status
Host Process Handling: The ManagerWorker host process should detect the failure via CLI exit code and mark the instruction accordingly.

Action Required: Human intervention needed to start the test stack and/or approve MCP server in Cursor before manager operations can proceed.

Edit: For clarification - If I add --forceor --yoloto the command params, the MCP interaction works fine.

1 Like
14

Tested with –force and –yolo and both flags work allow the cursor-agent to work with the MCP. Thanks a lot for your assistance.

1 Like