AutomateLab

MCP config generator for Claude Code

Pick your transport and environment, fill in the server details, and get a working claude mcp add command plus the equivalent JSON block. Windows (native) gets the cmd /c wrapper automatically - the fix for the spawn npx ENOENT error that hits most stdio servers on Windows.

Used as the key in mcpServers and the CLI argument.
Windows = native Claude Code install, not running inside WSL.
User writes to ~/.claude.json. Project writes to .mcp.json (can be committed).
Space-separated. Flags like -y are handled correctly.
One KEY=value per line. Optional.

How the fixes are applied

The Windows spawn npx ENOENT fix

On Windows, npx is actually npx.cmd, a batch shim. Node's child_process.spawn - which Claude Code uses to launch stdio MCP servers - cannot resolve .cmd files without shell: true, so the bare command fails with spawn npx ENOENT. Every official Claude Code plugin that shells out to bare npx (context7, chrome-devtools-mcp, azure, mongodb, desktop-commander, playwright) hits this on a fresh Windows install. The fix is to run the command through cmd /c instead: cmd /c npx -y @scope/package-name. This generator applies that wrapper automatically whenever you select Windows and stdio transport - it does not apply it for WSL or macOS/Linux, where the bare command resolves correctly.

User vs project scope

User scope writes to ~/.claude.json at the home root (%USERPROFILE%\.claude.json on native Windows) - shared across every project on that machine. This is not the same file as ~/.claude/settings.json, which controls editor behavior (theme, auto-compact) but never loads MCP servers. Project scope writes to .mcp.json in the repo root, which you can commit to git so the whole team gets the same servers.

WSL keeps a separate config from native Windows

A Claude Code install running inside WSL writes to the Linux home directory (~/.claude.json inside the WSL filesystem) - a different file from a native Windows install's %USERPROFILE%\.claude.json, even on the same machine. Adding a server in one does not make it show up in the other. Pick WSL above if you run claude from a WSL terminal.

stdio vs HTTP

stdio servers are local: Claude Code spawns the command as a child process and talks to it over stdin/stdout. HTTP (and SSE) servers are remote: Claude Code opens a connection to a URL instead, and authentication goes in request headers rather than environment variables. Pick HTTP if the server you are connecting to is a hosted endpoint rather than an npm/uv package you run locally.

What this does not cover

FAQ

Why does my MCP server fail with spawn npx ENOENT on Windows?

npx is npx.cmd on Windows, and Node's bare spawn call cannot resolve .cmd shims. Wrapping the command as cmd /c npx fixes it - this generator does that automatically for Windows + stdio.

Do I need the cmd /c wrapper inside WSL too?

No. Inside WSL, Claude Code runs as a Linux process and npx resolves normally. The wrapper is only for a native Windows install.

Where does claude mcp add actually write the config?

User scope writes to ~/.claude.json (%USERPROFILE%\.claude.json on native Windows) - not ~/.claude/settings.json. Project scope writes to .mcp.json in the repo root. A WSL install and a native Windows install keep separate ~/.claude.json files.

What is the difference between stdio and HTTP transport?

stdio spawns a local process and talks over stdin/stdout. HTTP connects to a remote URL and sends auth via headers instead of environment variables.

Does this tool send my config anywhere?

No. It runs entirely in your browser. Nothing you type is sent to AutomateLab or anywhere else.

Need an MCP server built, not just configured?

We build and ship MCP servers for internal tools and customer-facing agents - AutomateLab's own n8n MCP server is public on npm.

Tell us what you need