Nandi Proxmox MCP server

NANDI Proxmox MCP

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.

What stays enabled

• 140+ tools across nodes, cluster, QEMU, LXC, storage, backup, tasks, network, firewall, pools, access, templates, monitoring, and remote operations.
• Access tiers: read-only, read-execute, full.
• Module split: PVEMODULEMODE=core|advanced.
• Tool filters: PVECATEGORIES, PVETOOLBLACKLIST, PVETOOL_WHITELIST.
• Destructive guardrails via confirm=true.
• Backward-compatible aliases such as listNodes, getVMStatus, startVM, stopContainer.
• stdio transport for MCP clients and Streamable HTTP transport for controlled remote deployments.

Required permissions

The server needs two trust channels and both are preserved intentionally:

• Proxmox API token
• Used for inventory, lifecycle, configuration, and management endpoints.
• Keep ACLs minimal: only grant the roles needed for the tools you actually enable.
• SSH batch access to the Proxmox host
• Required for pct exec, batch SSH diagnostics, and container-level Docker inspection tools.
• This is still necessary because Proxmox API coverage does not replace host-side pct and SSH-based diagnostics.

More detail: docs/PERMISSIONS.md

Destructive confirmations

Operations marked destructive do not execute unless the caller sends confirm=true.

Examples:

• VM/container stop, shutdown, reboot, suspend, delete, migrate, snapshot rollback
• storage/network/firewall/access writes that can alter cluster state
• advanced remote execution such as pveexecin_container

The server returns a structured CONFIRMATION_REQUIRED error when confirmation is missing. This behavior is unchanged and reinforced.

Human approval

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.

Shortened. The full README is on GitHub.