If godot-mcp won't connect in Cursor on WSL, the real culprit is almost always that Cursor is a Windows app trying to launch a Linux Node binary it can't see. The fix is to set wsl.exe as the command in mcp.json and pass node plus the absolute Linux path as arguments. Two smaller gotchas usually compound the problem along the way: tildes (~) don't expand inside JSON, and JSON config files don't allow // comments.

This post walks through all three issues in the order I hit them, with the working mcp.json config at the end.

TL;DR

  • Symptom: Cursor logs show Server not yet created, returning empty offerings and the MCP server never connects.
  • Root cause: Cursor runs on Windows; your node lives in WSL. Cursor can't see it.
  • Fix: Use "command": "wsl.exe" and put node plus the absolute path in "args".
  • Two side bugs: ~ doesn't expand in JSON values, and // comments break JSON parsing silently.
  • Final step: Fully restart Cursor (not just reload), then open Godot before invoking godot-mcp tools.

The Setup

I wanted to use the godot-mcp package to let Cursor's AI interact directly with Godot — launching the editor, querying project info, managing scenes, all that good stuff. I downloaded it, built it, added it to Cursor's mcp.json, and got this in the logs:

2026-03-07 10:55:11.578 [info] Server not yet created, returning empty offerings

Not helpful.

Three Things Were Wrong

1. Tilde doesn't expand in JSON

My first config looked like this:

"args": ["~/game_dev/godot-mcp/build/index.js"]

Cursor launches MCP servers directly without a shell, so ~ never gets expanded. It's looking for a file literally named ~. Use the full absolute path:

"args": ["/home/yourname/game_dev/godot-mcp/build/index.js"]

2. JSON doesn't support comments

I had copied the example config which included:

"env": {
  "DEBUG": "true"   // Optional: Enable detailed logging
}

That // comment is invalid JSON and will silently break parsing. Remove it.

3. Cursor is a Windows app — it can't see your WSL Node

This was the real one. Even after fixing the path and the comment, the server still wouldn't start. The reason: Cursor runs on Windows. When it tries to execute node, it's looking for a Windows binary — not the one you installed inside WSL.

My WSL Node worked fine in the terminal. Cursor had no idea it existed.

Worth noting: if you're using nvm inside WSL, this compounds the problem. Cursor doesn't run your shell init files, so even if nvm is configured in your .bashrc or .zshrc, Cursor won't pick it up. You can't just point at node and expect it to resolve.

The Fix

Use wsl.exe as the command, and pass your WSL path as an argument. Windows knows how to find wsl.exe, and it bridges the call into your Linux environment:

"godot": {
  "command": "wsl.exe",
  "args": ["node", "/home/yourname/game_dev/godot-mcp/build/index.js"],
  "env": {
    "DEBUG": "true"
  },
  "disabled": false,
  "autoApprove": [
    "launch_editor",
    "run_project",
    "get_debug_output",
    "stop_project",
    "get_godot_version",
    "list_projects",
    "get_project_info",
    "create_scene",
    "add_node",
    "load_sprite",
    "export_mesh_library",
    "save_scene",
    "get_uid",
    "update_project_uids"
  ]
}

After a full Cursor restart (not just reload), the MCP server showed as connected.

One More Thing

Most of the useful godot-mcp tools require Godot's editor to be open with your project loaded. The MCP connects to a running editor instance — it's not fully standalone. So once Cursor shows the server as connected, open Godot before you start using tools like get_project_info or launch_editor.

FAQ

Why does wsl.exe work when node doesn't?

Windows knows where wsl.exe is via PATH, and wsl.exe knows how to invoke programs inside your WSL distribution. So wsl.exe node /home/.../index.js is really "Windows runs wsl.exe, which runs Linux node, which runs your script." The Linux Node binary stays inside WSL where it belongs.

Do I need to do anything special for nvm?

If node is managed by nvm inside WSL, the first command in args should be node — wsl.exe will resolve it through your default WSL shell PATH for non-interactive invocations. If that fails, replace "node" with the absolute path to the active nvm node binary (e.g. /home/you/.nvm/versions/node/v20.11.0/bin/node).

Why a full Cursor restart instead of a reload?

MCP servers are launched as child processes of Cursor at startup. A reload reuses the parent process and may keep stale state. A full quit + relaunch forces Cursor to reread mcp.json and respawn the servers cleanly.

Does this same approach work for other MCP servers on WSL?

Yes. Any MCP server that's installed inside WSL and run via node (or python, etc.) hits the same problem and uses the same fix — "command": "wsl.exe" with the interpreter and absolute Linux path as args. Servers installed as native Windows binaries don't need this.

Why does my JSON look fine but Cursor still ignores it?

The two silent killers are // line comments (invalid JSON, parsers reject the whole file) and trailing commas (also invalid JSON in strict parsers). If Cursor isn't picking up your config at all, paste the file into a JSON validator first.