You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.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:
{"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 initialize handshake.
I wrote a script that starts the MCP process and sends the following JSON over stdin:
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:
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.
The text was updated successfully, but these errors were encountered:
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 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.
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 saysClient closed
orNo 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:
mcp.json
file under~/.cursor
correctly. The commands point to valid tools. For Brave, I’m using a Docker container that expects aBRAVE_API_KEY
environment variable. For Figma, I’m using thefigma-developer-mcp
package with a valid Figma API key. Here’s an example of what my config looks like:For Brave:
This starts and outputs:
For Figma:
This outputs:
initialize
handshake.I wrote a script that starts the MCP process and sends the following JSON over stdin:
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:
But never anything about actual tools being loaded. Same for Figma. There’s no indication Cursor ever receives or accepts the tool registration.
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:
~/.cursor/mcp
and reinitializing.stdbuf
to flush stdout.-it
in Docker.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.
The text was updated successfully, but these errors were encountered: