-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
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.
Here’s what I did in detail:
- I configured my
mcp.jsonfile under~/.cursorcorrectly. The commands point to valid tools. For Brave, I’m using a Docker container that expects aBRAVE_API_KEYenvironment variable. For Figma, I’m using thefigma-developer-mcppackage 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"
]
}
}
}- I ran both processes manually in the terminal. They both work.
For Brave:
docker run -it --rm -e BRAVE_API_KEY=... mcp/brave-searchThis starts and outputs:
Brave Search MCP Server running on stdio
For Figma:
npx -y figma-developer-mcp --figma-api-key=... --stdioThis outputs:
{"method":"notifications/message","params":{"level":"info","data":["Server connected and ready to process requests"]},"jsonrpc":"2.0"}
- 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
initializehandshake.
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"
}
}
}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:
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.
- 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"]}}]}}'
catEven 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/mcpand 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
stdbufto flush stdout. - Forcing pseudo-TTYs with
-itin 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.


