Skip to content

MCP tools not registering in Cursor 0.48 on Linux despite correct configs, handshake, and working processes #2999

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ashgw opened this issue Apr 9, 2025 · 5 comments

Comments

@ashgw
Copy link

ashgw commented Apr 9, 2025

Hey, first off, thank you guys for the great product!

But I ran into a problem today, I’m running Linux with Cursor version 0.48.0. I updated today specifically for the new MCP support. I’ve been trying to integrate two MCP servers, Brave Search and Framelink Figma, and Cursor consistently fails to register the tools. It says Client closed or No tools available, despite the processes working completely fine when launched manually. I’ve spent some time debugging this, testing both CLI behavior and Cursor’s internal logs, and it’s clear the issue is inside Cursor, not the MCPs.

Image

Here’s what I did in detail:

  1. I configured my mcp.json file under ~/.cursor correctly. The commands point to valid tools. For Brave, I’m using a Docker container that expects a BRAVE_API_KEY environment variable. For Figma, I’m using the figma-developer-mcp package with a valid Figma API key. Here’s an example of what my config looks like:
{
  "mcpServers": {
    "brave-search": {
      "command": "docker",
      "args": [
        "run",
        "-it",
        "--rm",
        "mcp/brave-search"
      ],
      "env": {
        "BRAVE_API_KEY": "hiuahzduhazudhauzhduh-my-actual-key"
      }
    },
    "Framelink Figma MCP": {
      "command": "npx",
      "args": [
        "-y",
        "figma-developer-mcp",
        "--figma-api-key=hiuahzduhazudhauzhduh-my-actual-key-2",
        "--stdio"
      ]
    }
  }
}
  1. I ran both processes manually in the terminal. They both work.

For Brave:

docker run -it --rm -e BRAVE_API_KEY=... mcp/brave-search

This starts and outputs:

Brave Search MCP Server running on stdio

For Figma:

npx -y figma-developer-mcp --figma-api-key=... --stdio

This outputs:

{"method":"notifications/message","params":{"level":"info","data":["Server connected and ready to process requests"]},"jsonrpc":"2.0"}
  1. At this point Cursor still wasn’t detecting any tools, even though the processes were clearly running and outputting. So I assumed the problem was missing JSON-RPC initialization. Based on standard LSP/MCP behavior, I created a wrapper to inject an initialize handshake.

I wrote a script that starts the MCP process and sends the following JSON over stdin:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "1.0",
    "capabilities": {},
    "clientInfo": {
      "name": "cursor",
      "version": "dev"
    }
  }
}

Image

This script was confirmed working. I wrapped both Brave and Figma MCPs with it. Both processes stayed alive, printed confirmation messages, and in the case of Figma, even responded with error messages stating the fields were invalid until I fixed the payload:

Image

Which means the handshake was going through and the MCP was behaving correctly.

However, even after injecting the correct initialization handshake, Cursor still refuses to show any tools. I verified the MCPs are responding, alive, and emitting logs. Still nothing appears in the UI. Cursor logs show:

[MCPServerItem] Refreshing tools for server user-brave-search (docker run ...)
[MCPServerItem] Refreshed server user-brave-search

But never anything about actual tools being loaded. Same for Figma. There’s no indication Cursor ever receives or accepts the tool registration.

  1. To eliminate all variables, I built a minimal mock MCP script that just echoes the tool registration JSON immediately and stays open:
#!/bin/bash
echo '{"jsonrpc":"2.0","method":"tool/registration","params":{"tools":[{"name":"echo","description":"Echo text","parameters":{"type":"object","properties":{"text":{"type":"string"}},"required":["text"]}}]}}'
cat

Even with this dummy MCP that registers instantly and keeps stdin open, Cursor still doesn’t show the tool. Which confirms that the problem is 100% inside Cursor, not with my tools, wrappers, or configs.

I’ve also tried:

  • Removing all MCP servers and restarting from scratch.
  • Wiping ~/.cursor/mcp and reinitializing.
  • Killing all MCP-related processes and restarting Cursor fully (not just reloading the window).
  • Manually inspecting the tool registration output to confirm it's valid JSON.
  • Using stdbuf to flush stdout.
  • Forcing pseudo-TTYs with -it in Docker.
  • Monitoring Cursor’s console logs in dev tools.

Nothing worked. MCP tools are being registered and emitted correctly from my side, but Cursor never picks them up. This is a bug or missing logic inside Cursor’s tool registration pipeline, most likely in its stdin parser or process supervisor.

The fact that even a minimal dummy tool that does nothing but print a registration payload doesn’t work confirms this is not a config or environment issue. I’m on Linux, all commands run perfectly in the terminal, and Cursor just fails silently.

@ashgw
Copy link
Author

ashgw commented Apr 9, 2025

Downgraded to v0.45 and it works on this version

@GLips
Copy link

GLips commented Apr 11, 2025

FWIW I've gotten a lot of reports about this issue on the Framelink Figma repo GH. The MCP logs in Cursor don't really provide enough detail to figure out what might be going on. Subscribing to this thread to keep tabs. LMK if I can help at all.

@ashgw
Copy link
Author

ashgw commented Apr 12, 2025

Downgraded to v0.45 and it works on this version

-> Now tried 0.47.9 & MCP works on this version too.

Btw, @GLips Framelink is the only one bugging rn:

Image

@GLips
Copy link

GLips commented Apr 15, 2025

@ashgw Just pushed another update, 0.1.16, which might possibly fix the issue. Super hard to diagnose when Cursor swallows every error or log the MCP tries to emit. Let me know if the new version works for you, otherwise I'll keep changing things and trying to figure it out.

@ashgw
Copy link
Author

ashgw commented Apr 15, 2025

@GLips yes it works now

Image

Image

Thanks a bunch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants