Looking in wrong spot to discover MCP servers

,

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I tell it to use the Bitbucket MCP server. The config for that server, and others, is in /home/cwood/.cursor/mcp.json.

This is the Windows version of Cursor, and my projects are in WSL2.

Cursor mostly looks in /home/cwood/.cursor/projects/home-cwood-[project]/mcps/. This is where the cached tool descriptors and metadata are. But even though I’ve used the Bitbucket MCP server before, it wasn’t cached there, and so I often (but not always) have to tell Cursor where to look.

I asked it where it looked and it told me that it looks in the above path. It said it comes from its system prompt. I will provide the snippet below, that it rendered in its “Thinking” area. Is this real system prompt or hallucinated? (Note that the project name is redacted.)

I tried in several requests and got consistent answers.

Request ID: c87f4d06-f407-478f-a32e-3729e2199b8d
Request ID: 3fa23b7a-64d3-42c5-992a-5e8eb6d1fcd7
Request ID: bc1d2fee-b0ba-470f-a591-f9e4abf8935c


System prompt? From model’s thinking.

<mcp_file_system>
You have access to MCP (Model Context Protocol) tools through the MCP FileSystem.

## MCP Tool Access

You have a `CallMcpTool` tool available that allows you to call any MCP tool from the enabled MCP servers. To use MCP tools effectively:

1. Discover Available Tools: Browse the MCP tool descriptors in the file system to understand what tools are available. Each MCP server's tools are stored as JSON descriptor files that contain the tool's parameters and functionality.
2. MANDATORY - Always Check Tool Schema First: You MUST ALWAYS list and read the tool's schema/descriptor file BEFORE calling any tool with `CallMcpTool`. This is NOT optional - failing to check the schema first will likely result in errors. The schema contains critical information about required parameters, their types, and how to properly use the tool.

The MCP tool descriptors live in the /home/cwood/.cursor/projects/home-cwood-dev-<project>/mcps folder. Each enabled MCP server has its own folder containing JSON descriptor files (for example,/home/cwood/.cursor/projects/home-cwood-dev-<project>/mcps/<server>/tools/tool-name.json), and some MCP servers have additional server use instructions that you should follow.

## MCP Resource Access

You also have access to MCP resources through the `ListMcpResources` and `FetchMcpResource` tools. To discover and access resources:

1. Discover Available Resources: Use `ListMcpResources` to see what resources are available from each MCP server. Alternatively, you can browse the resource descriptor files in the file system at/home/cwood/.cursor/projects/home-cwood-dev-<project>/mcps/<server>/resources/resource-name.json.
2. Fetch Resource Content: Use `FetchMcpResource` with the server name and resource URI to retrieve the actual resource content. The resource descriptor files contain the URI, name, description, and mime type for each resource.
3. Authenticate MCP Servers When Needed: If you inspect a server's tools and it has an `mcp_auth` tool, you MUST call `mcp_auth` so the user can use that MCP server. Do not call `mcp_auth` in parallel. Authenticate only one server at a time.

Available MCP servers:

<mcp_file_system_servers><mcp_file_system_server name="cursor-ide-browser" folderPath="/home/cwood/.cursor/projects/home-cwood-dev-<project>/mcps/cursor-ide-browser">cursor-ide-browser</mcp_file_system_server>

<mcp_file_system_server name="user-Forge" folderPath="/home/cwood/.cursor/projects/home-cwood-dev-<project>/mcps/user-Forge" serverUseInstructions="MCP Initialization Request.">user-Forge</mcp_file_system_server></mcp_file_system_servers>
</mcp_file_system>

Steps to Reproduce

Define configuration for an MCP server in ~/.cursor/mcp.json.
Below for example. (Credential redacted).

{
  "mcpServers": {
    "bitbucket": {
      "command": "/home/cwood/.nvm/versions/node/v24.13.0/bin/npx",
      "args": [
        "-y",
        "[email protected]"
      ],
      "env": {
        "BITBUCKET_URL": "https://api.bitbucket.org/2.0",
        "BITBUCKET_WORKSPACE": "REDACTED",
        "BITBUCKET_USERNAME": "REDACTED",
        "BITBUCKET_PASSWORD": "REDACTED"
      }
    }
  }
}

Tell Cursor e.g. “Create a pull request using the bitbucket server”.

Cursor will say that it doesn’t have any “bitbucket” mcp server.

NOTE: I tried this with both a slash command and just straight up talking to it and neither worked.

Expected Behavior

It should find and use the MCP server as expected.

Operating System

Windows 10/11

Version Information

Version: 3.3.12 (user setup)
VSCode Version: 1.105.1
Commit: 75c0dfd29aecf2cc208dbaf761d5cc459c601aa0
Date: 2026-05-06T03:47:52.249Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Kimi K2.5

For AI issues: add Request ID with privacy disabled

Request ID: c87f4d06-f407-478f-a32e-3729e2199b8d
Request ID: 3fa23b7a-64d3-42c5-992a-5e8eb6d1fcd7
Request ID: bc1d2fee-b0ba-470f-a591-f9e4abf8935c

Additional Information

I haven’t tried clearing that cache yet, will try that.

Does this stop you from using Cursor

No - Cursor works, but with this issue

The system prompt snippet you shared is real, not hallucinated. That section lists the MCP servers Cursor has successfully connected to, which is why bitbucket isn’t there.

The core issue: Cursor runs as a Windows process, so the global ~/.cursor/mcp.json points to your Windows home directory, not your WSL home directory. Your bitbucket config was never read.

Two workarounds:

  1. Project-level config – place a .cursor/mcp.json in your WSL workspace root (e.g., /home/cwood/dev/<project>/.cursor/mcp.json). Cursor reads project-level configs through the remote filesystem, so WSL paths work here.

  2. Windows-side global config with WSL wrapper – put the config in the Windows ~/.cursor/mcp.json and use wsl as the command.

More context and workarounds from other WSL users in this thread: Run MCP servers in WSL

For MCP configuration details, the docs cover both global and project-level setups.

Thanks for the quick reply! I have several questions:

  1. It was working. I’ve had this mcp.json file since February and this issue just started happening within the past couple of weeks. It also does work sometimes. (Although I guess that could be caching of some kind, or the agent just getting lucky in searching for the file.) Has something changed lately? I have updated Cursor twice in the past few days.
  2. I don’t have an mcp.json file in %USERPROFILE%\.cursor and I’m pretty confident I never have. How has it been able to discover any MCP servers at all?
  3. Speaking of which, using ~ in the docs for a Windows app is misleading and made me think it would resolve the WSL home. For a Windows app it is %USERPROFILE%.
  4. Finally – is it within the realm of possibility to make this path configurable? We could use \\wsl$\Ubuntu\home\cwood in the Windows app (assuming it can resolve UNC paths).

Thanks!

Getting inconsistent results here: cbb9256c-85dd-4dbd-9127-badf5516c9ab

where do you look for mcp.json

Cursor looks for mcp.json in these locations (in order of priority):

  1. Project-specific: .cursor/mcp.json in the workspace root (where yours is)

  2. Global (WSL): ~/.cursor/mcp.json or ~/.config/cursor/mcp.json

  3. Global (Windows): Since you’re in WSL, Cursor also checks Windows locations

Your current file is empty—no MCP servers are configured. If you want to add MCP servers, you’d add them to the mcpServers object with their command/args/env settings.

why didn’t you look in the 2nd and 3rd spots?

Found it. The global ~/.cursor/mcp.json has your actual MCP servers configured:

  • bitbucket - Bitbucket MCP server

  • trackr - Local server at localhost:38947

  • Zoho Projects - Zoho MCP server

  • Forge - Another Zoho/Forge server

You’re right to call that out. I should have checked all locations from the start. The priority order is:

  1. Project-level: ./.cursor/mcp.json (empty in this workspace)

  2. User global: ~/.cursor/mcp.json (where your active servers are)

  3. XDG config: ~/.config/cursor/mcp.json (doesn’t exist)

Cursor merges these, with project-level settings overriding global ones. Since your project file is empty, all 4 servers from your global config are active.

I guess the agent by itself executes in the WSL context. But the windows app executes in the windows context and passes those paths into the system prompt. Definitely confusing. I can see how you guys wouldn’t really know what else to do either though! Maybe a checkbox that says “just always run in the WSL context”?

Sorry to pile on, but here’s some important context:

This reflects the contents of my WSL ~/.cursor/mcp.json. When I click the “New MCP Server” button, or the pencil next to an existing server, it goes to ~/.cursor/mcp.json.

And again, there is no mcp.json in my Windows home directory. When you reference “the Windows ~/.cursor”, what path do you mean specifically?

Screenshot truncated to hide credentials. Here’s my WSL ~/.cursor/mcp.json. I have added an invalid entry.

Here’s the Cursor settings immediately reflecting that change:

Thanks for the detailed follow-up with screenshots.

Your evidence is clear: Cursor is reading your WSL ~/.cursor/mcp.json. The settings UI shows all your servers, and adding the invalid “asdf” entry immediately produced the config error. My earlier explanation that “the global mcp.json points to your Windows home directory” was wrong for your setup.

Since Cursor reads the WSL config and the MCP extension runs in the WSL context, the Linux command path for bitbucket (/home/cwood/.nvm/versions/node/v24.13.0/bin/npx) should be valid. The fact that it “was working” before and “does work sometimes” also rules out a simple path issue.

To figure out what’s actually going wrong, could you click “Show Output” next to bitbucket in the MCP settings panel? That should show the specific error. If there’s a lot of output, a screenshot or copy-paste of the last 20-30 lines would help.

On the ~ docs point (question 3 from your earlier reply): that’s a fair observation. For most Windows+WSL setups, ~ can resolve to either the Windows or WSL home depending on which context is running. We’ll flag this for a docs clarification.

Thanks! I hadn’t realized that ~ works in Powershell, that’s neat.

The error for the Bitbucket MCP server was because the “env” keys weren’t making it into the MCP script. Do we think that that’s why Cursor wouldn’t find it? I have moved mcp.json into the workspace for now. It did still have troubles reading the env and so I made a wrapper script that exports the env keys. That seems like it may be a separate issue though.

Okay, I do think that was ultimately the issue. Because the Bitbucket server had a problem, the Cursor application did not even tell the agent about it. The below screenshot shows 4 MCP servers. Two are in ~/.cursor/mcp.json, and two are in the project workspace. You can see that it does successfully find the “zoho” one, which is categorized as a user server. And then it doesn’t find trackr because it’s not working.

Should I open a separate issue about the ENV not working for the bitbucket one? Or is this a known issue for kicking off servers with npx?

Yes, I’d recommend opening a separate thread for the env issue.

The fact that it was working before and broke recently with an update is useful context for the bug report. When you file, include:

  1. Your Cursor version (current + last known working version if you remember)

  2. That you’re on WSL2

  3. Your mcp.json config (redacted credentials) showing the direct env values

  4. That the workaround (wrapper script exporting the env vars manually) confirms the server itself works fine

  5. Whether global (~/.cursor/mcp.json) vs project-level (.cursor/mcp.json) makes a difference for this issue specifically

Short answer: not a known issue for the specific pattern you’re hitting. Worth a new report.