# Cursor CLI can see my MCP servers, but Agent sessions still can't use them **URL:** \ **Category:** Bug Reports\ **Tags:** cli, mcp\ **Created:** [September 15, 2026, 3:22am UTC](https://forum.cursor.com/t/cursor-cli-can-see-my-mcp-servers-but-agent-sessions-still-cant-use-them/171696 "2026-09-15T03:22:44Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Aland](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/aland/32/121011_2.png) [@Aland](https://forum.cursor.com/u/Aland)\ **Post date:** [September 15, 2026, 3:22am UTC](https://forum.cursor.com/t/cursor-cli-can-see-my-mcp-servers-but-agent-sessions-still-cant-use-them/171696/1 "2026-09-15T03:22:45Z")
### 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`. ```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", "/dbhub.toml" ] } } } ``` 1. Run: 2. Run: 3. Run: 4. Run: 5. Start an interactive session: 6. Open: 7. Both `dbhub` and `idea_mcp` show: 8. Exit and test headless mode: 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 ![Cursor Desktop successfully connecting to both MCP servers](https://us1.discourse-cdn.com/cursor1/original/3X/3/e/3e1eb94a5f5098417f7063d524fd76029e6b35dd.png) ![CLI management commands seeing both MCP servers and their tools](https://us1.discourse-cdn.com/cursor1/original/3X/8/b/8b67705c82264d88104e1d1d4a9d884703fc6063.png) ![interactive `/mcp` showing error / 0 tools](https://us1.discourse-cdn.com/cursor1/original/3X/7/4/7463bff90eafa04645bf1930f803af089a7613cf.png) ### 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 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 15, 2026, 8:07am UTC](https://forum.cursor.com/t/cursor-cli-can-see-my-mcp-servers-but-agent-sessions-still-cant-use-them/171696/5 "2026-09-15T08:07:54Z")
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. ---
**Author:** ![Aland](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/aland/32/121011_2.png) [@Aland](https://forum.cursor.com/u/Aland)\ **Post date:** [September 15, 2026, 8:30am UTC](https://forum.cursor.com/t/cursor-cli-can-see-my-mcp-servers-but-agent-sessions-still-cant-use-them/171696/7 "2026-09-15T08:30:44Z")
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. ![image](https://us1.discourse-cdn.com/cursor1/original/3X/d/e/de171997626f562b2e8169a7b6794c34f9d33d04.png) Once the MCP servers have been approved, shouldn’t subsequent sessions work without needing `--approve-mcps` again? ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 15, 2026, 12:25pm UTC](https://forum.cursor.com/t/cursor-cli-can-see-my-mcp-servers-but-agent-sessions-still-cant-use-them/171696/11 "2026-09-15T12:25:38Z")
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.