Cursor CLI can see my MCP servers, but Agent sessions still can't use them

,

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I’m seeing inconsistent MCP behavior in Cursor CLI.

My MCP servers are configured correctly and they work fine in the Cursor desktop app. The CLI management commands also see them normally:

  • agent mcp list shows both servers as ready
  • agent mcp list-tools dbhub returns 2 tools
  • agent mcp list-tools idea_mcp returns 66 tools
  • agent mcp enable dbhub says it is already enabled and approved

But inside actual Agent sessions, the MCP tools are not available.

In interactive agent mode, /mcp shows both MCP servers as error with 0 tools, and says the MCP server is not connected.

In agent -p mode, the Agent also says the dbhub MCP namespace / execute_sql tool is not available in the current session.

So the strange part is:

  • Cursor Desktop can use these MCP servers
  • agent mcp list / agent mcp list-tools can also see them
  • but real Agent sessions in Cursor CLI cannot use them

This affects both of my MCP servers:

  • dbhub (stdio MCP)
  • idea_mcp (HTTP MCP)

So it does not look like a problem with only one server or one transport type.

Steps to Reproduce

  1. Configure MCP servers in project .cursor/mcp.json.
{
  "mcpServers": {
    "idea_mcp": {
      "type": "http",
      "url": "http://127.0.0.1:65453/stream",
      "headers": {}
    },
    "dbhub": {
      "command": "npx",
      "args": [
        "-y",
        "@bytebase/dbhub@latest",
        "--transport",
        "stdio",
        "--config",
        "<project dir>/dbhub.toml"
      ]
    }
  }
}

  1. Run:

    agent mcp list

    Both MCP servers are shown as ready.

  2. Run:

    agent mcp list-tools dbhub

    It returns 2 tools.

  3. Run:

    agent mcp list-tools idea_mcp

    It returns 66 tools.

  4. Run:

    agent mcp enable dbhub

    It says the server is already enabled and approved.

  5. Start an interactive session:

    agent

  6. Open:

    /mcp

  7. Both dbhub and idea_mcp show:

    • Status: error
    • 0 tools
    • Error loading MCP, unable to list tools
    • MCP ‘’ is not connected
  8. Exit and test headless mode:

    agent -p “You must use dbhub’s execute_sql tool to execute SELECT 1. Do not use shell.”

  9. The Agent responds that the current session does not have the dbhub MCP namespace or the execute_sql tool.

Expected Behavior

If agent mcp list shows an MCP server as ready, and agent mcp list-tools can successfully list its tools, then those same MCP tools should also be available inside real Agent sessions.

In other words, I expect the behavior to be consistent between:

  • Cursor Desktop
  • agent mcp list / agent mcp list-tools
  • interactive agent
  • agent -p

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

CLI Version: 2026.09.10-fd3934a

Additional Information

I also ran the CLI in debug mode.

The logs show that both MCP configurations are discovered, and both MCP providers are initialized, including:

  • idea_mcp with http://127.0.0.1:65453/stream
  • dbhub

The logs also show:

  • mcp_deferred=true
  • mcp_init_ms=-1

So from what I can tell, Cursor CLI is discovering the MCP configuration, but the actual Agent session is not exposing those MCP tools.

This seems more like a CLI Agent runtime issue than an MCP server configuration issue, especially because:

  • the same MCP servers work in Cursor Desktop
  • agent mcp list works
  • agent mcp list-tools works
  • this affects both a stdio MCP server and an HTTP MCP server

It may be related to deferred/lazy MCP initialization in recent CLI versions.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @Aland, thanks for the detailed report, and for including the debug log details.

The mcp_deferred=true / mcp_init_ms=-1 lines are expected in interactive mode (MCP loading is moved off the first paint), so they are not the cause. What I suspect is that the agent session is treating your two project-level servers as not yet approved and quietly skipping them, even though agent mcp enable says they are approved. On Windows the session and the agent mcp ... commands can end up computing the approval record differently for the same project folder.

Could you try this to confirm?

  1. Open PowerShell in D:\Programming\ZKGJ_Work\SIS (the same folder where agent mcp list works).
  2. Run: agent --approve-mcps
  3. Once the prompt appears, type /mcp and press Enter.
  4. Check whether dbhub and idea_mcp now show as ready with their tool counts (2 and 66).
  5. Press Esc, then run the headless check: agent -p --approve-mcps "Use dbhub's execute_sql tool to run SELECT 1. Do not use shell."

If both work with --approve-mcps, that confirms it, and you can use that flag as a workaround for now. Another workaround that avoids the approval step entirely is to move the two servers from the project .cursor\mcp.json into your global config at %USERPROFILE%\.cursor\mcp.json (global servers do not need per-project approval).

If it still fails with the flag, please run agent, type /logs to get the log file path, and paste any lines containing “Failed to load MCP server” from that file. That line carries the actual connection error.

Thanks! --approve-mcps works for me .

After launching the CLI with it, both project-level MCP servers are available and usable in the agent session.

Once the MCP servers have been approved, shouldn’t subsequent sessions work without needing --approve-mcps again?

Hey @Aland, glad that worked, and thanks for confirming.

To answer your question: no, that flag does not save anything. It only tells that one session to skip the approval check, so the next session started without it goes back to the same state.

Normally the approval you give with agent mcp enable (or the prompt on first launch) is remembered per project and later sessions pick it up automatically. On Windows the agent session is currently looking that approval up under a slightly different project identity than the one agent mcp enable saves, so it never finds it. I’ve flagged this to the team.

Until that is fixed you have two options:

  1. Keep using agent --approve-mcps (and agent -p --approve-mcps "..." for headless runs).
  2. Move the two servers into your global config at %USERPROFILE%\.cursor\mcp.json. Global servers do not go through per-project approval, so they will be available in every session without the flag.