uvx is the default on Windows, same as everywhere else. There is one Windows-specific thing that can push you off it:
Smart App Control blocks uvx → switch to pip (Step 1b). This is by far the most common Windows breakage, and it usually shows up abruptly right after a Windows update.
If PyPI itself is unreachable — a corporate network that blocks the package index — neither path can fetch anything. Ask IT to allowlist pypi.org and files.pythonhosted.org, or to mirror the package on an internal index you can point at with pip install --index-url.
uvx stops working with no useful error. The MCP client reports the server failed to start, or PowerShell reports the program was blocked by your administrator / by system policy. Nothing in your config changed. Very often this starts right after a Windows update, which makes it look like the server broke rather than the launcher.
Smart App Control (SAC) is a Windows 11 feature that only lets signed or otherwise known-good executables run. uvx doesn’t run a permanently installed program — on every single run it unpacks a fresh, unsigned temporary executable and launches it. That is precisely the shape SAC exists to stop, so SAC blocks it every time. No amount of retrying or reinstalling uv changes it: the file is new and unsigned on each run by design.
SAC ships in evaluation mode on new Windows 11 machines and can flip itself to on later, on its own. That’s why this appears out of nowhere on a machine where uvx had been working for months.
To check: Windows Security → App & browser control → Smart App Control settings.
Do not turn Smart App Control off to fix this. Turning it off is a one-way switch — once disabled, Windows will not let you turn it back on again. Getting it back requires reinstalling Windows. It is not worth trading a permanent OS security downgrade for a package launcher. Use pip instead; it solves the problem completely and leaves SAC on.
pip installs the server as ordinary Python files run by a signed Python interpreter, so SAC has nothing to object to.
Install Python 3.10 or newer from the python.org installer — that build is signed and passes SAC as-is. (Python from the Microsoft Store works too.) Tick “Add python.exe to PATH” during install. Then:
Install Chromium up front, as shown. Deferring it to the first tool call means a ~150 MB download racing your MCP client’s handshake deadline, which surfaces as connection closed.
Always launch it as a module, never the console script
pip also drops a servicenow-mcp.exe shim into your Scripts folder. That shim is an unsigned .exe that pip generates on your machine, so SAC blocks it exactly like it blocked uvx. Bypass it entirely by calling the module:
For Codex’s TOML, the equivalent is command = "python" / args = ["-m", "servicenow_mcp"].
If python isn’t found by your MCP client, give the absolute path instead (e.g. C:/Users/you/AppData/Local/Programs/Python/Python312/python.exe). MCP clients don’t always inherit the PATH your shell has.
Copy the configuration for your MCP client below.
Replace your-instance with your actual ServiceNow instance address.
These examples use the default uvx install. On the pip path (Step 1b), replace command with python and args with ["-m", "servicenow_mcp"] — keeping any --instance-url / --auth-type flags that follow, and leaving the env block exactly as written.
Skills are AI execution blueprints — verified pipelines with safety gates that turn raw MCP tools into reliable workflows. 4 skills across 3 categories.
Terminal window
# Claude Code
servicenow-mcp-skills claude
# OpenAI Codex
servicenow-mcp-skills codex
# OpenCode
servicenow-mcp-skills opencode
# Or with uvx (no install needed)
uvx --from mfa-servicenow-mcp servicenow-mcp-skills claude
On the pip path (Step 1b), call the module instead — servicenow-mcp-skills is the same kind of unsigned pip-generated .exe shim that Smart App Control blocks:
Update: Re-run the same install command to replace all existing skill files.
Remove skills only: delete the skill directory manually (for example Remove-Item -Recurse .claude\commands\servicenow\).
→ This is Smart App Control, not a broken install. uvx unpacks an unsigned temporary executable on every run and SAC refuses to run it. Switch to the pip path in Step 1b. Don’t disable SAC — that’s a one-way switch you can only undo by reinstalling Windows.
The pip install worked, but servicenow-mcp still won’t launch
→ You’re hitting the pip-generated servicenow-mcp.exe shim, which is unsigned and blocked by SAC just like uvx was. Call the module instead: python -m servicenow_mcp. Update your MCP client config to "command": "python", "args": ["-m", "servicenow_mcp"] too.
→ On the uvx path, uv automatically downloads Python 3.11+ — no manual install needed. If there’s a conflict with system Python, uninstall and reinstall uv.
→ On the pip path you supply Python yourself: install 3.10+ from the python.org installer (signed, so it passes Smart App Control) and tick “Add python.exe to PATH”. Microsoft Store Python works as well.
TOML: brackets, quotes, commas
→ Verify instance-url starts with https://.
→ Claude Desktop requires a full quit and restart after config changes (close tray icon too).
uvx reuses the last cached version it downloaded. It does not automatically refresh to a newer release on every run. To pull the latest published version into cache:
