Azure plugin .mcp.json hard-codes command:npx, fails silently on machines without Node.js on PATH

[nikduvall]

Summary

The Azure plugin's MCP server fails to launch on machines where npx is not on PATH. The Cursor UI just shows error with no actionable message; the underlying failure is 'npx' is not recognized and is only visible by digging into Cursor's MCP log files. The README does mention installing Node.js as a prerequisite, but the failure mode is undiscoverable for non-developer users and could be made resilient at the plugin layer.

Repro

1. Windows machine without Node.js installed system-wide (Cursor's bundled internal node helper does not expose npx to child processes).
2. Install the azure plugin from the Cursor marketplace (microsoft/azure-skills 1.1.43).
3. Enable the Azure MCP server in Cursor Settings → MCP.

Observed

• UI shows the Azure server in error state with no actionable message.
• %APPDATA%\Cursor\logs\<session>\window1_wb0\exthost\anysphere.cursor-mcp\MCP plugin-azure-azure.<...>.log:

[V2] Handling CreateClient action
[V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
[error] 'npx' is not recognized as an internal or external command,
operable program or batch file.
 undefined
[warning] Connection failed: MCP error -32000: Connection closed
[warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown
[info] CreateClient completed, connected: false, statusType: error

• Retries indefinitely; never connects.

Current source (verified on main)

.github/plugins/azure-skills/.mcp.json:

{
  "mcpServers": {
    "azure": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"]
    }
  }
}

Expected / suggested fixes (in rough order of how nice they'd be)

1. Ship a native or dnx-style invocation — @azure/mcp has a self-contained .NET build (Azure.Mcp.Server); shipping that as the launch command would eliminate the Node/npm dependency entirely.
2. Add a preflight check — emit a clearer error if npx isn't resolvable, ideally surfaced via the MCP error payload rather than buried in logs.
3. Document the prereq more prominently — README does say "Install Node.js 18+", but a user who installs the plugin from the marketplace and toggles it on has no in-product hint that they need a separate Node.js install.
4. Allow opting into corporate-CA trust — on corporate networks doing TLS interception, even with Node.js installed, the first launch fails with UNABLE_TO_GET_ISSUER_CERT_LOCALLY because Node uses its bundled CA list. Setting NODE_OPTIONS=--use-system-ca in the plugin's per-server env block would prevent this for many enterprise users.

Working workaround (for users hitting this today)

Edit the cached plugin's .mcp.json to use an absolute path + the corporate-CA env var. On Windows where Node was installed via winget (OpenJS.NodeJS.LTS):

{
  "mcpServers": {
    "azure": {
      "command": "C:\\Users\\<user>\\AppData\\Local\\Microsoft\\WinGet\\Packages\\OpenJS.NodeJS.LTS_Microsoft.Winget.Source_8wekyb3d8bbwe\\node-vXX.XX.X-win-x64\\npx.cmd",
      "args": ["-y", "@azure/mcp@latest", "server", "start"],
      "env": {
        "NODE_OPTIONS": "--use-system-ca"
      }
    }
  }
}

This is fragile because the cache directory is hash-versioned and the edit is lost on plugin update.

Environment

• Cursor on Windows 11 (corporate-managed, TLS-intercepting network)
• microsoft/azure-skills 1.1.43 (cache hash 9d86ae4a15bcbc82bd49d908c050638d99d02e38)
• @azure/mcp 3.0.0-beta.10 (verified launches correctly when invoked with an absolute-path npx)
• Once the workaround is applied, the Azure MCP server connects successfully and Azure CLI auth (az login) functions normally.

Related observation (out of scope but maybe relevant)

The same 'npx' is not recognized failure mode hits any other MCP plugin that ships with "command": "npx" (e.g. a Teams MCP server in the same Cursor install). A note in Cursor's plugin authoring docs about not relying on a process-inherited PATH would help plugin authors avoid this class of bug.

[EHESPO]

{
"mcpServers": {
"azure": {
"command": "node",
"args": ["-e", "const {spawnSync} = require('child_process'); const npx = process.platform === 'win32' ? 'npx.cmd' : 'npx'; const result = spawnSync(npx, ['-y', '@azure/mcp@latest', 'server', 'start'], {stdio: 'inherit', env: {...process.env, NODE_OPTIONS: '--use-system-ca'}}); process.exit(result.status);"]
}
}
}

[EHESPO]

Summary

The Azure plugin's MCP server fails to launch on machines where npx is not on PATH. The Cursor UI just shows error with no actionable message; the underlying failure is 'npx' is not recognized and is only visible by digging into Cursor's MCP log files. The README does mention installing Node.js as a prerequisite, but the failure mode is undiscoverable for non-developer users and could be made resilient at the plugin layer.

Repro

1. Windows machine without Node.js installed system-wide (Cursor's bundled internal node helper does not expose npx to child processes).
2. Install the azure plugin from the Cursor marketplace (microsoft/azure-skills 1.1.43).
3. Enable the Azure MCP server in Cursor Settings → MCP.

Observed

• UI shows the Azure server in error state with no actionable message.
• %APPDATA%\Cursor\logs\<session>\window1_wb0\exthost\anysphere.cursor-mcp\MCP plugin-azure-azure.<...>.log:

[V2] Handling CreateClient action
[V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
[error] 'npx' is not recognized as an internal or external command,
operable program or batch file.
 undefined
[warning] Connection failed: MCP error -32000: Connection closed
[warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown
[info] CreateClient completed, connected: false, statusType: error

• Retries indefinitely; never connects.

Current source (verified on main)

.github/plugins/azure-skills/.mcp.json:

{
"mcpServers": {
"azure": {
"command": "npx",
"args": ["-y", "@azure/mcp@latest", "server", "start"]
}
}
}

Expected / suggested fixes (in rough order of how nice they'd be)

1. Ship a native or dnx-style invocation — @azure/mcp has a self-contained .NET build (Azure.Mcp.Server); shipping that as the launch command would eliminate the Node/npm dependency entirely.
2. Add a preflight check — emit a clearer error if npx isn't resolvable, ideally surfaced via the MCP error payload rather than buried in logs.
3. Document the prereq more prominently — README does say "Install Node.js 18+", but a user who installs the plugin from the marketplace and toggles it on has no in-product hint that they need a separate Node.js install.
4. Allow opting into corporate-CA trust — on corporate networks doing TLS interception, even with Node.js installed, the first launch fails with UNABLE_TO_GET_ISSUER_CERT_LOCALLY because Node uses its bundled CA list. Setting NODE_OPTIONS=--use-system-ca in the plugin's per-server env block would prevent this for many enterprise users.

Working workaround (for users hitting this today)

Edit the cached plugin's .mcp.json to use an absolute path + the corporate-CA env var. On Windows where Node was installed via winget (OpenJS.NodeJS.LTS):

{
"mcpServers": {
"azure": {
"command": "C:\Users\\AppData\Local\Microsoft\WinGet\Packages\OpenJS.NodeJS.LTS_Microsoft.Winget.Source_8wekyb3d8bbwe\node-vXX.XX.X-win-x64\npx.cmd",
"args": ["-y", "@azure/mcp@latest", "server", "start"],
"env": {
"NODE_OPTIONS": "--use-system-ca"
}
}
}
}
This is fragile because the cache directory is hash-versioned and the edit is lost on plugin update.

Environment

• Cursor on Windows 11 (corporate-managed, TLS-intercepting network)
• microsoft/azure-skills 1.1.43 (cache hash 9d86ae4a15bcbc82bd49d908c050638d99d02e38)
• @azure/mcp 3.0.0-beta.10 (verified launches correctly when invoked with an absolute-path npx)
• Once the workaround is applied, the Azure MCP server connects successfully and Azure CLI auth (az login) functions normally.

Related observation (out of scope but maybe relevant)

The same 'npx' is not recognized failure mode hits any other MCP plugin that ships with "command": "npx" (e.g. a Teams MCP server in the same Cursor install). A note in Cursor's plugin authoring docs about not relying on a process-inherited PATH would help plugin authors avoid this class of bug.

[saikoumudi]

Nik DuVall (@nikduvall) Thanks for the detailed report and thorough investigation — the repro steps, and workaround were all very helpful.

We’ll review this with our team and also check whether Cursor provides a way for marketplace installs to make the Node.js prerequisite more obvious during installation or setup, so users aren’t left with a generic error.

Appreciate your feedback here!

[diberry]