mcp: local `execute` tool cannot work on Windows (three stacked failures, plus a misleading error message)

[charlycrates]

Summary

The execute tool of dodopayments-mcp (stdio server, local Deno execution mode) cannot work on Windows at all. Every call returns:

Deno is required for code execution but was not found. Install it from https://deno.land or run: npm install deno

even with Deno correctly installed and on PATH. We followed both instructions in the error message; neither can fix it, because the failure is three layers deep. Below is the full root cause with file references (package dodopayments-mcp@2.44.0), a repro, and suggested fixes per layer. search_docs works fine; only local code execution is affected.

Environment

• Windows 10 (10.0.19045), Node 22.17.0
• dodopayments-mcp@2.44.0 launched via npx -y dodopayments-mcp (stdio, MCP client: Claude Code)
• Deno 2.9.4 installed (deno --version works in the same environment) and present on PATH

Layer 1: Deno detection is POSIX-only, so PATH detection can never succeed on Windows

code-tool.js (around line 140):

execSync('command -v deno', { stdio: 'ignore' });

command is a POSIX shell builtin. On Windows, execSync runs under cmd.exe, where 'command' is not recognized, so this check throws every time, regardless of whether Deno is installed. Installing Deno (per the error message) cannot help.

Suggested fix: a cross-platform probe, e.g. spawnSync('deno', ['--version']) (CreateProcess resolves deno.exe from PATH), or branch on process.platform === 'win32' and use where deno.

Layer 2: the node_modules fallback spawns a .cjs file as a binary

When PATH detection fails, the fallback resolves node_modules/deno/bin.cjs (the deno npm package's JS launcher) and hands that path to @valtown/deno-http-worker, which spawns it directly. On Windows, spawning a .cjs file fails with spawn EFTYPE: a JS file needs the node interpreter. So npm install deno (the error message's second instruction) cannot help either.

Two details worth checking here:

• The fallback path resolution looks unintended: packageRoot = path.resolve(path.dirname(workerPath), '..') lands on the node_modules directory itself (workerPath is at the package root), so the code actually probes node_modules/node_modules/deno/bin.cjs.
• Suggested fix: spawn it as process.execPath + [binCjsPath, ...args], or resolve the real platform binary that the deno npm package downloads, instead of the launcher script.

Layer 3 (the hard one): the worker transport is a Unix domain socket

@valtown/deno-http-worker communicates with the Deno process over a Unix socket (os.tmpdir()/<uuid>-deno-http.sock). Deno does not support Unix sockets on Windows:

> deno eval "Deno.listen({ transport: 'unix', path: 'C:/tmp/x.sock' })"
error: Operation `"op_net_listen_unix"` not supported on non-unix platforms.

(Verified with Deno 2.9.4.) So even with layers 1 and 2 patched (we tried, placing a real deno.exe where the fallback looks), the worker exits before ready: local execution is structurally unix-only today.

Suggested options:

• Short term: detect win32 and return an honest, platform-aware error ("local code execution requires macOS/Linux; use the hosted MCP server"), instead of the current message that sends users to install things that cannot fix it. Also document the Deno/OS requirement in the README (currently it does not mention Deno at all).
• Longer term: a TCP-loopback or named-pipe transport on Windows, or routing Windows users to the Cloudflare-hosted execute path that already exists (feat(mcp): self-host execute tool via Cloudflare Worker Loader #275).

Repro

1. On Windows, install Deno (any method; confirm deno --version works).
2. Configure the MCP server: npx -y dodopayments-mcp with DODO_PAYMENTS_API_KEY and DODO_PAYMENTS_ENVIRONMENT=test_mode.
3. Call the execute tool with any code.
4. Observe Deno is required for code execution but was not found... (layers 1 and 2). If you place a real deno.exe at the fallback path, observe Deno exited before being ready (layer 3).

Impact

Any Windows user of the stdio MCP server silently loses code execution, and the error message actively misleads (we spent a full debugging session following its instructions). Our workaround was to call the REST API directly, which works great. But the MCP tool advertises a capability that one OS can never use, without documentation saying so.

Happy to provide more detail. Thanks: the REST API itself and search_docs have been solid.