Skip to content

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

@rccyx

Description

@rccyx

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions