Proxmox VE MCP server for VMs, LXCs, snapshots, backups, storage, and cluster operations.
Proxmox VE MCP server for VMs, LXCs, snapshots, backups, storage, and cluster operations. Provides a Model Context Protocol (MCP) server to manage virtualization tasks and related workflows.
🛠️ Key Features
Manages VMs and LXCs via MCP
Supports snapshots, backups, and storage operations
Cluster-level operations for Proxmox environments
Topics include ai-agent, automation, openapi, and model-context-protocol
🚀 Use Cases
Integrating Proxmox with AI agents for automated VM lifecycle management
Orchestrating backups, snapshots, and storage tasks
Leveraging MCP for model-driven decision making in homelab setups
⚡ Developer Benefits
Open API and MCP compatibility for automation workflows
Clear focus on virtualization, QEMU, and Proxmox
Facilitates model-context-based interactions in cloud-native environments
⚠️ Limitations
Data model specifics not enumerated beyond general Proxmox scope
Requires Proxmox VE environment for full functionality
Operate Proxmox VE from MCP clients, AI agents, and OpenAPI tooling through one security-conscious control plane for VMs, LXCs, snapshots, backups, ISOs, container commands, and persistent long-running jobs.
ProxmoxMCP-Plus sits between AI clients and Proxmox VE so operators do not have to stitch together raw API calls, one-off shell scripts, and custom job polling for every workflow.
It exposes the same operational surface in two ways:
MCP for Claude Desktop, Cursor, VS Code, Open WebUI, Codex, and other MCP-capable agents
OpenAPI for HTTP automation, dashboards, internal tools, and no-code workflows
What you get:
VM and LXC lifecycle actions
snapshot create, rollback, and delete
backup and restore workflows
ISO download and cleanup
node, storage, and cluster inspection
SSH-backed container command execution with guardrails
persistent job tracking for async Proxmox tasks
What Makes It Different
Priority
How the project handles it
Dual access paths
Native MCP for agent workflows and OpenAPI for standard HTTP automation
Proxmox-oriented workflows
Day-2 VM, LXC, snapshot, backup, ISO, storage, and cluster operations
Long-running operations
Stable job_ids, Proxmox UPID tracking, polling, retry, cancel, and audit history
Safer execution
Proxmox API tokens, OpenAPI bearer auth, command policy, approval tokens, TLS validation, and MCP HTTP Host/Origin controls
Real validation
Unit, integration, Docker/OpenAPI, and live Proxmox e2e entry points are documented in the repo
Quick Start
1. Prepare Proxmox Credentials
Create a Proxmox API token with only the permissions your workflows need. Then create the local config file:
Then edit proxmox-config/config.json with your environment. At minimum, it needs:
proxmox.host
proxmox.port
auth.user
auth.token_name
auth.token_value
Add an ssh section as well if you want container command execution.
Add a jobs section if you want job state persisted somewhere other than the default local SQLite file.
For real live verification, use a separate proxmox-config/config.live.json created from proxmox-config/config.live.example.json.
Do not point live e2e at a placeholder or local-only config.json unless you intentionally run a local API tunnel there.
Optional job persistence config:
json
{"jobs":{"sqlite_path":"proxmox-jobs.sqlite3"}}
Optional tool exposure filtering can reduce the schemas sent to MCP clients. It is
disabled by default, so existing configurations continue to expose every available
tool. Configure exactly one mode under mcp:
Alternatively, use tool_denylist, or the comma-separated environment variables
MCP_TOOL_ALLOWLIST and MCP_TOOL_DENYLIST. Do not configure both modes. Environment
selection replaces the file-level filtering mode. An empty allowlist exposes no tools;
an empty denylist hides none. Exact lowercase tool names are required, and unknown names
fail startup so a typo cannot silently widen access. Restart or reconnect the MCP server
after changing the filter.
2. Choose One Runtime Path
Path
Best for
Start command
Verify
MCP stdio from PyPI
Claude Desktop, Cursor, VS Code, Codex, local agents
uvx proxmox-mcp-plus
client lists get_nodes, get_vms, and job tools
Native MCP HTTP from Docker
remote MCP clients that support Streamable HTTP
docker compose --profile mcp-http up -d proxmox-mcp-http
connect to http://localhost:8000/mcp
OpenAPI bridge from Docker
HTTP clients, dashboards, scripts, no-code tools
docker compose up -d
curl -f http://localhost:8811/livez
MCP stdio with PyPI
bash
uvx proxmox-mcp-plus
Or install it first:
bash
pip install proxmox-mcp-plus
proxmox-mcp-plus
Use this path when the MCP client launches a local stdio server.
Native MCP HTTP with Docker
Use this path when a remote MCP client supports Streamable HTTP:
Send Authorization: Bearer <MCP_API_KEY> with every MCP HTTP request. MCP_API_KEY
is deliberately separate from the OpenAPI-only PROXMOX_API_KEY, so the two surfaces
can be rotated independently. If MCP_API_KEY is unset, Streamable HTTP remains
unauthenticated for backward compatibility and logs a security warning at startup.
When serving MCP HTTP behind a reverse proxy, keep DNS rebinding protection enabled and allow only the hostnames you expect:
Client-specific examples for Claude Desktop, Cursor, VS Code, Codex, OpenCode, Open WebUI, Streamable HTTP, and OpenAPI are in the Client Setup Guide and Integrations Guide.
Demo
This demo is a direct terminal recording of qwen/qwen3.6-plus driving a live MCP session in English against a local Proxmox lab. It shows natural-language control flowing through MCP tools to create and start an LXC, execute a container command, and confirm the authenticated HTTP /health surface.
ProxmoxMCP-Plus is an access layer, not a replacement for Proxmox RBAC, network controls, or client-side MCP approval prompts.
The project gives operators several control points:
Proxmox API tokens decide what the backend can do.
PROXMOX_API_KEY protects the OpenAPI bridge by default.
MCP_API_KEY optionally protects the native Streamable HTTP /mcp endpoint with Bearer authentication.
TLS verification is enforced unless development mode is explicitly enabled.
command_policy controls command execution and high-risk operations.
approval_token can gate command execution and high-risk mutating actions.
MCP Streamable HTTP deployments can use DNS rebinding protection plus Host and Origin allowlists.
Optional MCP tool allowlists or denylists reduce the runtime tool surface; they do not replace Proxmox RBAC.
Logs are designed to avoid exposing command and credential material.
Read the Security Guide before exposing the server outside a trusted local environment.
Core Platform Capabilities
ProxmoxMCP-Plus provides a unified control surface for the operational tasks most teams actually need in Proxmox VE. The same server can expose these workflows to MCP clients for LLM and AI-agent use cases, and to HTTP consumers through the OpenAPI bridge.
Supported workflow areas:
Capability Area
Availability
VM create / start / stop / delete
Available
VM snapshot create / rollback / delete
Available
Backup create / restore
Available
ISO download / delete
Available
LXC create / start / stop / delete
Available
Container SSH-backed command execution
Available
Container authorized_keys update
Available
Persistent job store for long tasks
Available
MCP job control tools (list_jobs, get_job, poll_job, cancel_job, retry_job)
Available
OpenAPI /jobs endpoints with explicit status codes
Available
Local OpenAPI /livez, /readyz, /health, and schema
Available
Docker native MCP Streamable HTTP at /mcp
Available
Docker image build and /livez
Available
Validation and contract entry points in this repository:
tests/scripts/run_real_e2e.py now prefers proxmox-config/config.live.json or PROXMOX_MCP_E2E_CONFIG.
This avoids accidentally running live checks against a machine-specific default config.json.
Long-Running Jobs
Many Proxmox mutations are asynchronous. ProxmoxMCP-Plus now wraps those tasks in a persistent job layer so MCP and OpenAPI clients can track them through a stable Job ID.
Long-running tools such as VM create/start/stop, container create/start/stop, snapshot changes, backup/restore, and ISO download/delete now return both:
task_id: the raw Proxmox UPID
job_id: the stable server-side job record
The job record stores:
current status and progress
retry count and prior UPIDs
latest result payload or failure reason
audit history for create, poll, retry, and cancel actions
By default the job store persists to proxmox-jobs.sqlite3, so restart does not lose in-flight or completed job metadata.
MCP Job Tools
list_jobs
get_job
poll_job
cancel_job
retry_job
OpenAPI Job Routes
When the OpenAPI proxy is enabled and a local JobStore is available, these routes are exposed directly:
Path
Method
Purpose
Success Codes
/jobs
GET
list persisted jobs
200
/jobs/{job_id}
GET
fetch one job, optional refresh=true
200
/jobs/{job_id}/poll
POST
refresh status from Proxmox
200
/jobs/{job_id}/cancel
POST
request cancellation
202
/jobs/{job_id}/retry
POST
replay a stored retry recipe
202
Common error codes:
404: unknown job_id
409: the job exists but that operation is not valid now
503: the OpenAPI proxy was started without a local JobStore
tests/scripts/run_real_e2e.py now prefers proxmox-config/config.live.json or PROXMOX_MCP_E2E_CONFIG.
This avoids accidentally running live checks against a machine-specific default config.json.
These are written for both human operators and LLM-driven usage.
Documentation
The README is intentionally optimized for fast GitHub comprehension. Longer operational docs live in docs/wiki/ and can also be published to the GitHub Wiki.