Power your agent
The publisher's own command. Not a PlugMCP endpoint.
Host a copy with our keys and logs.
npx -y [email protected]Claude Code has no install link for a local command. Copy the command below and run it in a terminal.
NANDI_PROXMOX_CONFIG=<value> claude mcp add io.github.nandi-services-nandi-proxmox-mcp -- npx -y nandi-proxmox-mcp@0.4.1Run in a terminal.
{ "mcpServers": { "io.github.nandi-services-nandi-proxmox-mcp": { "command": "npx", "args": [ "-y", "[email protected]" ], "env": { "NANDI_PROXMOX_CONFIG": "<value>" } } }}claude_desktop_config.json
Remote URL or a command on your machine? How the two installs differ
Run on PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
LaunchFrom the publisher
Turn your Proxmox cluster into an AI-driven platform with 140+ tools for automation, monitoring, and controlled execution.
Open source MCP server for Proxmox VE, powered by NANDI Services.
nandi-proxmox-mcp exposes Proxmox inventory, lifecycle, storage, backup, networking, firewall, access, monitoring, SSH diagnostics, and guarded remote/container operations without removing the safety rails needed for production clusters.
MCP server for Proxmox VE management (VM, LXC, nodes)
read-only, read-execute, full.PVE_MODULE_MODE=core|advanced.PVE_CATEGORIES, PVE_TOOL_BLACKLIST, PVE_TOOL_WHITELIST.confirm=true.listNodes, getVMStatus, startVM, stopContainer.stdio transport for MCP clients and Streamable HTTP transport for controlled remote deployments.The server needs two trust channels and both are preserved intentionally:
pct exec, batch SSH diagnostics, and container-level Docker inspection tools.pct and SSH-based diagnostics.More detail: docs/PERMISSIONS.md
Operations marked destructive do not execute unless the caller sends confirm=true.
Examples:
pve_exec_in_containerThe server returns a structured CONFIRMATION_REQUIRED error when confirmation is missing. This behavior is unchanged and reinforced.
confirm=true is supplied by the agent, not by you. A model that reads the rejection can simply
retry with the flag set, so on its own that check guards against an accident rather than against a
confident agent — and it never asks you anything.
So the 47 tools that require confirmation are also announced to the client as needing a person:
"_meta": { "anthropic/requiresUserInteraction": true }
In Claude Code 2.1.199 and later, a tool marked this way prompts on every call — including in
auto and bypassPermissions modes — and cannot be pre-approved by an allow rule or by a
PreToolUse hook returning allow. Under --permission-prompt-tool an automated approval is
converted to a denial, and Remote Control withholds one-tap approval and sends you to the full
prompt. The operator who answered is the one who authorised the operation.
One caveat, measured on 2.1.229 rather than taken from the documentation: the prompt still offers
"Yes, and don't ask again", even though the documentation says a flagged tool has no such option.
Choosing it writes an allow rule that does not retire the gate — the next call prompts again.
So the behaviour is right and only the button is misleading. Do not read its absence as the signal
that the guard is on; verify by calling a gated tool twice.
Starting and resuming a guest are deliberately left out: they change state without destroying anything, and a guard people resent is a guard people route around.
setup additionally writes matching permissions.ask rules into .claude/settings.json, which
cover Claude Code versions that predate the annotation. Rules are evaluated deny, then ask, then
allow — first match wins — so an ask rule survives both bypassPermissions and a later
"yes, don't ask again". For an install that was configured by hand rather than through setup:
nandi-proxmox-mcp harden # every configured instance
nandi-proxmox-mcp harden --name lab # just one
Both mechanisms are Claude Code specific. In any other client the guards are confirm=true and the
access tier, so choose the tier deliberately there.
read-only
read-execute
full
PVE_MODULE_MODE=core hides advanced tools without renaming or removing canonical tool IDs from the codebase.
Required:
PROXMOX_HOSTPROXMOX_USERPROXMOX_REALMPROXMOX_TOKEN_NAMEPROXMOX_TOKEN_SECRETPROXMOX_SSH_HOSTPROXMOX_SSH_USERPROXMOX_SSH_KEY_PATHOptional:
PROXMOX_PORT default 8006PROXMOX_SSH_PORT default 22PROXMOX_ALLOW_INSECURE_TLS default falsePVE_ACCESS_TIER=read-only|read-execute|fullPVE_MODULE_MODE=core|advancedPVE_CATEGORIESPVE_TOOL_BLACKLISTPVE_TOOL_WHITELISTHTTP transport:
MCP_TRANSPORT=stdio|httpMCP_HOST default 0.0.0.0MCP_PORT default 3000MCP_ALLOWED_HOSTSMCP_ALLOWED_ORIGINSMCP_RATE_LIMIT_WINDOW_MSMCP_RATE_LIMIT_MAXMCP_MAX_BODY_SIZE_BYTESMCP_HEADERS_TIMEOUT_MSMCP_REQUEST_TIMEOUT_MSMCP_KEEPALIVE_TIMEOUT_MSMCP_MAX_HEADERS_COUNTSetup writes one credentials file per configured Proxmox,
.nandi-proxmox-mcp/<instance>.json, plus a registration entry in each client
config it was asked for — .mcp.json for Claude Code and .vscode/mcp.json for
VS Code, by default both.
The credentials file is the only one holding the token, and it is gitignored.
When NANDI_PROXMOX_CONFIG is not set, the server discovers it: a single
configured instance is used automatically, and more than one is an error naming
them rather than a guess.
The config loader now rejects:
Never used an MCP before? Start with docs/EMPEZAR.md — a step-by-step guide (in Spanish) that assumes no prior MCP knowledge and covers creating the Proxmox token, which is the part that trips most people up.
You need an API token from your own Proxmox first. This prints the commands that create one, ready to paste into the Proxmox shell — it connects to nothing:
npx nandi-proxmox-mcp bootstrap --tier read-only
Then guided setup. By default this writes config for Claude Code
(.mcp.json) and VS Code (.vscode/mcp.json), merging into either file if
it already exists:
npx nandi-proxmox-mcp setup --access-tier read-only
npx nandi-proxmox-mcp doctor --check mcp-config,nodes,vms,cts,node-status,remote-op
Start with --access-tier read-only. The server's built-in default is full,
which exposes every destructive tool including arbitrary command execution;
passing the flag writes the tier explicitly into the client config so the
choice is visible rather than implicit. Raise it once you trust the setup.
Pick specific clients, or print a block for any other MCP client:
npx nandi-proxmox-mcp setup --clients claude-code
npx nandi-proxmox-mcp setup --print-config # writes nothing, safe to pipe
.mcp.json holds only a config path and policy settings, so it is safe to
commit and share. Your API token stays in .nandi-proxmox-mcp/config.json,
which is gitignored.
Direct run with environment variables:
$env:PROXMOX_HOST="pve.local"
$env:PROXMOX_PORT="8006"
$env:PROXMOX_USER="svc_mcp"
$env:PROXMOX_REALM="pve"
$env:PROXMOX_TOKEN_NAME="nandi-mcp"
$env:PROXMOX_TOKEN_SECRET="<SECRET>"
$env:PROXMOX_SSH_HOST="pve.local"
$env:PROXMOX_SSH_USER="root"
$env:PROXMOX_SSH_KEY_PATH="$env:USERPROFILE\.ssh\id_ed25519"
npx nandi-proxmox-mcp run
This MCP server operates real Proxmox infrastructure and is not a sandboxed environment.
The following risks are inherent to the system design:
Privileged Operations
Full access tier and container execution capabilities can perform destructive or system-level actions.
SSH Execution Boundary
Remote command execution relies on SSH and inherits the security posture of the target system.
Optional Insecure TLS Mode
When enabled (PROXMOX_ALLOW_INSECURE_TLS=true), TLS certificate validation is bypassed and may expose connections to MITM attacks. Intended for lab use only.
External Dependency Synchronization
Package distribution and listing visibility depend on npm, MCP Registry, and marketplace propagation timing.
Users are responsible for:
The HTTP transport performs no authentication. There is no bearer token, API key, or client-certificate check on
POST /mcp; the controls below are network-level only.MCP_HOSTalso defaults to0.0.0.0, and the host allowlist includes your configured Proxmox and SSH hosts. Anyone who can reach the port and send a matchingHostheader gets the full registered tool surface — which, with the defaultPVE_ACCESS_TIER=full, includes destructive tools and arbitrary command execution.Only enable
MCP_TRANSPORT=httpon a trusted network, behind an authenticating reverse proxy, or bound to127.0.0.1viaMCP_HOST. The default stdio transport is not affected: it has no network surface.
When MCP_TRANSPORT=http is enabled, the server applies:
Origin header413 responses/mcpX-Content-Type-Options: nosniffCache-Control: no-storeHealth/readiness endpoints:
GET /healthGET /readyPOST /mcpFunctionality is unchanged, but the execution path is stricter:
spawn(..., { shell: false })BatchMode, IdentitiesOnly, public-key auth, and explicit connection liveness controlsdockerLogsInContainer now validates and shell-escapes container names instead of interpolating raw user inputpve_exec_in_container flow with confirmation requiredMitigations in the repo:
overrides for critical transitive packagesnpm pack --dry-run, and auditThreat model and residual risks: docs/THREAT_MODEL.md
Releases are automatic. A push to main runs auto-release.yml, which reads the bump level
from the conventional-commit subjects since the last v* tag, writes the new version into every
file that carries one, commits chore(release): vX.Y.Z, and pushes the tag. The tag is what
starts release.yml and the publish below.
A push with nothing releasable finishes green and lists the commits it skipped. Run the workflow
by hand with dry_run: true to see the version and the diff without publishing.
The version lives in eight places — manifests, both registry descriptors, the marketplace plugin,
two docs examples and two TypeScript literals. scripts/set-version.mjs writes all of them and
scripts/validate-package-metadata.mjs gates all of them. Adding a ninth means editing both:
a writer that touches a file the validator ignores is how 0.3.1 shipped announcing itself as
0.2.4.
Release order, once the tag exists, is strict:
npm run lintnpm run typechecknpm run buildnpm testnpm audit --include=dev --audit-level=moderatenpm ls expressnpm ls path-to-regexpnpm pack --dry-runnpm packnpm whoaminpm publish --access publicnpm view nandi-proxmox-mcp versionmcp-publisher validate .mcp/server.jsonmcp-publisher publish .mcp/server.jsonThe tag-based release.yml now publishes npm first and only then publishes the MCP Registry descriptor, preventing npm/registry drift on the same version.
If a release dies halfway, re-run it — gh workflow run release.yml --ref vX.Y.Z — rather than
finishing it by hand. Every publishing step asks its destination first and skips what is already
there, so the re-run completes only the parts that did not happen. The job refuses any ref that is
not a tag, and any tag that disagrees with the version in package.json.
Manual fallback and troubleshooting: docs/RELEASE.md
npm ci
npm run lint
npm run typecheck
npm run build
npm test
npm run validate:release
npm pack --dry-run
This repository follows a documentation sync policy, enforced in review rather than by a git hook.
There is no pre-commit hook. The one gate that is automated is in CI (
.github/workflows/ci.yml): it regeneratesdocs/TOOLS.mdand fails the build on any drift. Note also that a repo-local.git/hooks/pre-commitwould not run on a machine wherecore.hooksPathis redirected, which is common.
change, fix, or refactor, evaluate whether README.md, AGENTS.md, and CONTRIBUTING.md must be updated.no-doc-change justification is required.https://www.npmjs.com/package/nandi-proxmox-mcphttps://registry.modelcontextprotocol.io/https://mcp-marketplace.io/server/io-github-nandi-services-nandi-proxmox-mcpMIT. See LICENSE.
© 2026 MCP Directory.
MCP server for Proxmox VE management (VM, LXC, nodes)
{ "mcpServers": { "io.github.nandi-services-nandi-proxmox-mcp": { "command": "npx", "args": [ "-y", "[email protected]" ], "env": { "NANDI_PROXMOX_CONFIG": "<value>" } } }}Tools
No tool list yet. Remote servers get one after the first health check.
FAQ
Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
The publisher lists these environment variables: NANDI_PROXMOX_CONFIG.
Nandi Proxmox runs locally over stdio.
Last checked 2026-11-09. MCP server for Proxmox VE management (VM, LXC, nodes)