ProxmoxMCP-Plus

io.github.RekklesNAPublished by GitHub account RekklesNAv0.6.9Updated Nov 4, 2026

Proxmox VE MCP server for VMs, LXCs, snapshots, backups, storage, and cluster operations.

VerifiedSTDIODesktop onlyCloud & InfrastructureDeveloper Tools

Overview

AI-generated overview

MCP server that lets an assistant inspect and operate a Proxmox VE cluster: nodes, storage, VMs, LXC containers, snapshots, backups and long-running jobs.

What you can do
  • Inspect cluster, node, storage and network state, plus node time and diagnostics
  • List, create, clone, configure, start, stop, reset and delete QEMU VMs, including migration preflight and offline migration
  • List, create, start, stop, restart and resize LXC containers, and run commands inside guests via the QEMU guest agent or SSH
  • Track asynchronous Proxmox tasks as jobs: list, get, poll, cancel, retry and reconcile
  • Filter which tools are exposed through an allowlist or denylist
When to use it
Useful when you want an AI client to answer questions about a Proxmox VE environment or carry out day-2 operations such as creating, starting, stopping or deleting VMs and containers, taking snapshots and backups, or following long-running tasks, without writing raw API calls or scripts.
Requirements
Runs locally over stdio, typically via uvx from PyPI. Needs a reachable Proxmox VE API endpoint and an API token: PROXMOX_HOST, PROXMOX_USER, PROXMOX_TOKEN_NAME and the secret PROXMOX_TOKEN_VALUE, optionally PROXMOX_PORT, PROXMOX_SERVICE and PROXMOX_VERIFY_SSL, or a JSON config file via PROXMOX_MCP_CONFIG. Guest command execution needs the QEMU guest agent or an SSH section in the config.
Before you install
The token's Proxmox permissions decide what the assistant can do, and tools can start, stop, reset, reconfigure and permanently delete VMs and containers, so scope the token narrowly. Destructive and high-risk actions such as delete_vm, migration, image import and serial console changes warrant approval tokens and command policy. The token secret is stored in client config or a config file. Disabling TLS verification requires development mode. Cancelling or failing a job does not roll back…

Installation

In SourceWeft

  1. Open ProxmoxMCP-Plus in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

ProxmoxMCP-Plus

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.

[PyPI] [GitHub Release] [CI] [GHCR] [License]

Quick Start | Client Install | Demo | Tools | Safety | Scenarios | Docs | Wiki

[Architecture: MCP and OpenAPI entry points, guarded target-aware tools, Proxmox VE, and persistent jobs]

MCP and OpenAPI are alternative entry points into the same workflows and may run in separate processes. Solid arrows show requests and execution; dashed arrows show persisted job and audit state. Approval gates, SSH execution and MCP HTTP OAuth depend on configuration. Select the diagram to view it at full size.

Why ProxmoxMCP-Plus

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
  • opt-in guarded Proxmox node SSH commands
  • persistent job tracking for async Proxmox tasks

What Makes It Different

PriorityHow the project handles it
Dual access pathsNative MCP for agent workflows and OpenAPI for standard HTTP automation
Proxmox-oriented workflowsDay-2 VM, LXC, snapshot, backup, ISO, storage, and cluster operations
Long-running operationsStable job_ids, Proxmox UPID tracking, polling, retry, cancel, and audit history
Safer executionProxmox API tokens, OpenAPI bearer auth, command policy, approval tokens, TLS validation, and MCP HTTP Host/Origin controls
Real validationUnit, 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:

bash
cp proxmox-config/config.example.json proxmox-config/config.json

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:

json
{  "mcp": {    "tool_allowlist": ["get_nodes", "get_vms", "get_containers", "get_storage"]  }}

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

PathBest forStart commandVerify
MCP stdio from PyPIClaude Desktop, Cursor, VS Code, Codex, local agentsuvx proxmox-mcp-plusclient lists get_nodes, get_vms, and job tools
Native MCP HTTP from Dockerremote MCP clients that support Streamable HTTPdocker compose --profile mcp-http up -d proxmox-mcp-httpconnect to http://localhost:8000/mcp
OpenAPI bridge from DockerHTTP clients, dashboards, scripts, no-code toolsdocker compose --profile openapi up -d proxmox-mcp-apicurl -f http://localhost:8811/livez

Docker examples publish host ports on 127.0.0.1 by default; Compose modes are opt-in. Set only the selected mode's key: MCP_API_KEY for native HTTP or PROXMOX_API_KEY for OpenAPI. See Compose deployment and upgrade notes for reverse proxies, tunnels, explicit LAN bindings and container recreation.

MCP stdio with PyPI
bash
uvx proxmox-mcp-plus

Or install it first:

bash
pip install proxmox-mcp-plusproxmox-mcp-plus

Use this path when the MCP client launches a local stdio server.

Code Mode (opt-in)

Code Mode is disabled by default to preserve the legacy full tool catalog. Enable it with mcp.code_mode: true in the config file or MCP_CODE_MODE=true. When enabled, MCP exposes three tools instead: proxmox_code_search, proxmox_code_get_schema, and proxmox_code_execute. Code execution runs in an isolated sandbox and reaches domain tools through the existing validation, policy, and approval path. Discovery uses the filtered runtime catalog, so it also works in installed wheels. For example:

python
await call_tool("get_nodes", {"target": "default"})

The final expression is returned as data.result; tool results use MCP JSON content blocks (and structured content where supplied). Use proxmox_code_get_schema for arguments, including target and approval tokens. Scripts have no filesystem or network access except registered tool calls. Limits: 64,000 source characters, 100 MB sandbox memory, 25 tool calls, 16 KB final JSON, and two concurrent executions. Execution has a 30-second budget; cancelling or failing a script does not roll back tool side effects. Do not automatically retry a failed mutation script.

Optional worker reuse: set mcp.code_mode_pool_reuse: true or MCP_CODE_MODE_POOL_REUSE=true. The default remains one fresh worker per execution. Reuse keeps up to two workers for the server lifetime, recycles each after 100 checkouts, and starts a new sandbox session per request. Globals, approvals, output collectors and call limits are not shared between requests. HTTP clients share the server-owned pool; disconnecting a client does not close it. Run python scripts/benchmark_code_mode.py to measure local startup overhead; this is a microbenchmark, not an estimate of Proxmox operation latency.

Native MCP HTTP with Docker

Use this path when a remote MCP client supports Streamable HTTP:

bash
export MCP_API_KEY="$(openssl rand -hex 32)"docker run --rm -p 127.0.0.1:8000:8000 \  -e PROXMOX_MCP_MODE=mcp-http \  -e MCP_HOST=0.0.0.0 \  -e MCP_PORT=8000 \  -e MCP_TRANSPORT=STREAMABLE_HTTP \  -e MCP_API_KEY="$MCP_API_KEY" \  -v "$(pwd)/proxmox-config/config.json:/app/proxmox-config/config.json:ro" \  ghcr.io/rekklesna/proxmoxmcp-plus:latest

Point MCP clients at:

text
http://127.0.0.1:8000/mcp

For remote clients, use the configured proxy/tunnel URL or explicitly widen the host binding as described in Docker deployment.

Send Authorization: Bearer <MCP_API_KEY> with every native MCP HTTP request. The key is independent of Proxmox credentials. Native Streamable HTTP and SSE require a key by default. For an endpoint protected by an external access-control layer such as Tailscale ACLs, explicitly set MCP_ALLOW_UNAUTHENTICATED_HTTP=true or mcp.allow_unauthenticated_http: true in JSON configuration. This allows keyless startup and logs a warning; it does not configure or verify the external access controls. A configured MCP_API_KEY is always enforced, even with opt-out. This setting does not change OpenAPI authentication or DNS rebinding protection.

OAuth browser gate for MCP clients

Native MCP HTTP can optionally expose an OAuth authorization-code flow with PKCE while keeping MCP_API_KEY as the only human credential an operator has to manage. OAuth protocol handling is delegated to the MCP Python SDK (mcp>=1.30.0,<2), while ProxmoxMCP-Plus provides the API-key consent policy and persistent OAuth state.

OAuth state is stored in PostgreSQL. This allows multiple MCP server instances or hosts, when deployed explicitly, to share registered clients, authorization codes, access tokens, refresh tokens, refresh-token replay protection, and login-rate-limit state without relying on a local filesystem.

The client starts at the SDK /authorize endpoint. After the SDK validates the client, redirect URI, scope, PKCE request, and resource, the browser is redirected to /oauth/consent on the same MCP origin. The user reviews the client name, redirect origin, and requested scopes, then enters MCP_API_KEY. The API key is never placed in a URL and is never returned to the OAuth client.

Required OAuth settings:

bash
export MCP_API_KEY="$(openssl rand -hex 32)"# Replace <password> with the database user's password.export MCP_OAUTH_DATABASE_URL='postgresql://proxmox_oauth:<password>@postgres.example:5432/proxmox_oauth'

Example server:

bash
docker run --rm -p 127.0.0.1:8000:8000 \  -e PROXMOX_MCP_MODE=mcp-http \  -e MCP_HOST=0.0.0.0 \  -e MCP_PORT=8000 \  -e MCP_TRANSPORT=STREAMABLE_HTTP \  -e MCP_API_KEY="$MCP_API_KEY" \  -e MCP_OAUTH_ENABLED=true \  -e MCP_OAUTH_ISSUER=https://mcp.example.com \  -e MCP_OAUTH_DATABASE_URL="$MCP_OAUTH_DATABASE_URL" \  -e MCP_ALLOWED_HOSTS=mcp.example.com:*,localhost:* \  -e MCP_ALLOWED_ORIGINS=https://mcp.example.com \  -v "$(pwd)/proxmox-config/config.json:/app/proxmox-config/config.json:ro" \  ghcr.io/rekklesna/proxmoxmcp-plus:latest

Then connect the OAuth-capable client to:

text
https://mcp.example.com/mcp

OAuth mode exposes these endpoints on the same public origin:

  • /.well-known/oauth-protected-resource/mcp - RFC 9728 protected-resource metadata
  • /.well-known/oauth-authorization-server - SDK authorization-server metadata
  • /register - SDK dynamic client registration (DCR)
  • /authorize - SDK authorization endpoint
  • /token - SDK authorization-code/refresh-token exchange
  • /oauth/consent - ProxmoxMCP-Plus API-key consent page

The SDK requires PKCE S256 and protects the MCP resource with issued OAuth access tokens. Browser consent transactions are short-lived, HMAC-signed, and stateless. All durable OAuth state is stored in PostgreSQL.

Authorization-code consumption and refresh-token rotation use PostgreSQL transactions. A code or refresh token is deleted and its replacement tokens are inserted atomically, so concurrent server instances cannot successfully replay the same credential. Dynamic client registration capacity is also serialized with a PostgreSQL transaction-scoped advisory lock; inactive registrations are pruned before the configured limit is exceeded.

MCP_API_KEY is the sole source of truth for the browser consent credential. This runtime does not persist the key or its verifier in PostgreSQL. The server process validates consent directly against the value supplied in its environment. If the service is explicitly deployed as multiple containers or instances, configure the same secret for each instance. Stop all instances before changing the key, then restart/recreate all of them with the new value before routing traffic again. Existing OAuth clients and issued tokens are independent of the browser-gate key and remain valid until they expire or are revoked.

Required when OAuth is enabled:

VariablePurpose
MCP_API_KEYHuman credential entered only on the consent page
MCP_OAUTH_ISSUERPublic HTTPS origin of this MCP authorization server
MCP_OAUTH_DATABASE_URLPostgreSQL DSN used for OAuth state

Optional OAuth environment variables:

VariableDefaultPurpose
MCP_OAUTH_RESOURCE<issuer>/mcpPublic MCP resource identifier; must use the issuer origin
MCP_OAUTH_SCOPESmcpComma-separated required scopes
MCP_OAUTH_ACCESS_TOKEN_TTL_SECONDS3600Access-token lifetime
MCP_OAUTH_REFRESH_TOKEN_TTL_SECONDS2592000Refresh-token lifetime (30 days)
MCP_OAUTH_MAX_REGISTERED_CLIENTS4096Maximum persisted DCR clients before inactive-client pruning
MCP_OAUTH_DB_POOL_MIN_SIZE1Minimum asyncpg connections per MCP process
MCP_OAUTH_DB_POOL_MAX_SIZE10Maximum asyncpg connections per MCP process
MCP_OAUTH_DB_COMMAND_TIMEOUT_SECONDS10PostgreSQL command timeout used by the OAuth store
MCP_OAUTH_CLIENT_IP_HEADERunsetTrusted reverse-proxy header used only for login rate limiting

To rotate the browser-gate credential, stop every MCP instance using this issuer, update MCP_API_KEY in the deployment environment, and restart/recreate all instances with the same new key. The environment is read when the provider starts; editing a running container's environment does not reload its key. No OAuth database metadata or key-version update is required. Pending consent transactions created with the previous key will no longer validate after every instance has restarted; already issued OAuth tokens remain governed by their normal lifetime and revocation rules. A rolling key change leaves old instances accepting the old key and causes consent requests routed between different-key instances to fail. There is no database guard to detect or disable a stale instance. Changing the browser-gate key does not revoke existing access tokens, refresh tokens, or authorization codes; use explicit revocation for compromised OAuth credentials.

When upgrading from an OAuth build that used MCP_OAUTH_KEY_VERSION, startup ignores the old variable and leaves proxmox_mcp_oauth_metadata untouched. Fresh databases do not create that table. Registered clients and issued OAuth credentials are preserved; no manual SQL migration is required. Keeping legacy metadata avoids breaking old workers' queries and permits rollback with the same API key and legacy key version. Back up the database before upgrading and stop all old instances before rotating the key. After a key change, the legacy metadata still describes the old key: rollback requires restoring the old configuration or following the old version's rotation procedure, which invalidates OAuth state. Only remove the legacy table manually once all old instances are retired and a rollback is no longer needed; it can still contain the previous key's verifier.

The database role must be able to create and modify the proxmox_mcp_oauth_* tables in its database. The tables contain OAuth client metadata, including issued client secrets, plus authorization codes and active tokens, so the PostgreSQL database and backups must be protected as credential storage.

If several MCP instances use the same MCP_OAUTH_DATABASE_URL, OAuth state and one-time-token enforcement are shared across them. Size the database capacity with the total number of MCP processes in mind because the configured pool limits apply per process.

If the server is behind a trusted reverse proxy and per-user login rate limiting must use the original client address, set MCP_OAUTH_CLIENT_IP_HEADER to a header that the proxy overwrites (for example CF-Connecting-IP). Leave it unset unless the proxy prevents clients from spoofing that header.

When MCP_OAUTH_ENABLED=true, a raw Authorization: Bearer <MCP_API_KEY> request to /mcp is intentionally rejected. The API key is accepted only by the consent page; MCP requests must use an issued OAuth access token.

When serving MCP HTTP behind a reverse proxy, keep DNS rebinding protection enabled and allow only the hostnames you expect.

OpenAPI bridge with Docker

OpenAPI mode is the default Docker runtime and requires an API key:

bash
export PROXMOX_API_KEY="$(openssl rand -hex 32)"docker run --rm -p 127.0.0.1:8811:8811 \  -e PROXMOX_API_KEY="$PROXMOX_API_KEY" \  -v "$(pwd)/proxmox-config/config.json:/app/proxmox-config/config.json:ro" \  ghcr.io/rekklesna/proxmoxmcp-plus:latest

Verify the OpenAPI surface:

bash
curl -f http://localhost:8811/livezcurl -f -H "Authorization: Bearer $PROXMOX_API_KEY" http://localhost:8811/healthcurl -H "Authorization: Bearer $PROXMOX_API_KEY" http://localhost:8811/openapi.json

For local unauthenticated development only, set PROXMOX_ALLOW_NO_AUTH=true.

Source checkout
bash
git clone https://github.com/RekklesNA/ProxmoxMCP-Plus.gitcd ProxmoxMCP-Plusuv venvuv pip install -e ".[dev]"python main.py

The 8811 service is the OpenAPI/REST bridge. The 8000 service is the native MCP HTTP endpoint.

Client Install

Use the one-click buttons when your client supports MCP install deeplinks, or copy the JSON config below.

[Install in VS Code] [Install in Cursor]

Recommended stdio config:

json
{  "mcpServers": {    "proxmox-mcp-plus": {      "command": "uvx",      "args": ["proxmox-mcp-plus"],      "env": {        "PROXMOX_HOST": "your-proxmox-host",        "PROXMOX_USER": "root@pam",        "PROXMOX_TOKEN_NAME": "mcp-token",        "PROXMOX_TOKEN_VALUE": "your-token-secret",        "PROXMOX_PORT": "8006",        "PROXMOX_VERIFY_SSL": "true"      }    }  }}

Use a local config file if you prefer not to keep credentials in the client config:

json
{  "mcpServers": {    "proxmox-mcp-plus": {      "command": "uvx",      "args": ["proxmox-mcp-plus"],      "env": {        "PROXMOX_MCP_CONFIG": "/path/to/ProxmoxMCP-Plus/proxmox-config/config.json"      }    }  }}

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.

[Recorded demo gif]

Watch the MP4 version

Choose The Right Tool

Start with read-only discovery, then move to mutating tools only after the target node, storage, VMID, and permissions are clear.

Operator goalStart withThen useNotes
Inspect the clusterget_nodes, get_cluster_statusget_storage, get_vms, get_containersBest first health check after client install
Create or manage a VMget_nodes, get_storagecreate_vm, start_vm, stop_vm, delete_vmLong-running mutations return job_id and Proxmox task_id
Manage LXCsget_containers, get_storagecreate_container, start_container, stop_container, delete_containerSSH-backed command tools require the optional ssh config
Roll back risky changeslist_snapshots with vm_type=qemu or vm_type=lxccreate_snapshot, rollback_snapshot, delete_snapshotCreate a snapshot before destructive workflow tests
Run commands inside guestsVM or container status toolsexecute_vm_command, execute_container_commandVM path needs QEMU Guest Agent; LXC path needs SSH to the Proxmox node
Track async workmutation response with job_idpoll_job, get_job, list_jobs, retry_job, cancel_jobUse job_id for agent/user conversations and task_id for raw Proxmox traceability
Inspect logsget_node_syslog, get_cluster_logget_task_log, get_node_firewall_log, get_guest_firewall_logAll log tools are read-only; get_task_log accepts any Proxmox UPID
Automate from HTTP tools/openapi.json/jobs, /health, generated tool routesUse bearer auth and keep CORS restricted outside local development

For the full tool map, see the Tool Selection Guide and API & Tool Reference.

Safety Model

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 protects native Streamable HTTP and SSE with Bearer authentication; it is required unless MCP_ALLOW_UNAUTHENTICATED_HTTP=true explicitly delegates access control.
  • 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 AreaAvailability
VM create / start / stop / deleteAvailable
VM snapshot create / rollback / deleteAvailable
Backup create / restoreAvailable
ISO download / deleteAvailable
LXC create / start / stop / deleteAvailable
Container SSH-backed command executionAvailable
Container authorized_keys updateAvailable
Persistent job store for long tasksAvailable
MCP job control tools (list_jobs, get_job, poll_job, cancel_job, retry_job)Available
OpenAPI /jobs endpoints with explicit status codesAvailable
Local OpenAPI /livez, /readyz, /health, and schemaAvailable
Docker native MCP Streamable HTTP at /mcpAvailable
Docker image build and /livezAvailable

Validation and contract entry points in this repository:

  • python -m pytest -q (see Contributing for the full CI coverage gate)
  • ruff check .
  • mypy src --ignore-missing-imports
  • python -m pip_audit -r requirements/runtime.lock --require-hashes --disable-pip --strict
  • tests/integration/test_real_contract.py
  • tests/scripts/run_real_e2e.py

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.

Audit events are appended to a separate SQLite table. Existing history is migrated on startup and the API's audit_log format stays unchanged. Retention is unlimited by default; set jobs.audit_retention_days to a positive number in JSON config to prune expired events at startup and when each job is updated. This never deletes the job itself. Stop all workers sharing the database and back it up before this upgrade. Do not run old and new versions against the same database; restore the pre-upgrade backup if downgrading and retaining audit history is required.

A cancellation request is not completion. Poll until the task is failed/cancelled before calling retry_job; pending cancellation cannot be retried.

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:

PathMethodPurposeSuccess Codes
/jobsGETlist persisted jobs200
/jobs/{job_id}GETfetch one job, optional refresh=true200
/jobs/{job_id}/pollPOSTrefresh status from Proxmox200
/jobs/{job_id}/cancelPOSTrequest cancellation202
/jobs/{job_id}/retryPOSTreplay a stored retry recipe202

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.

Positioning Against Common Approaches

CapabilityOfficial Proxmox APIOne-off scriptsProxmoxMCP-Plus
MCP for LLM and AI agent workflowsNoNoYes
OpenAPI surface for standard HTTP toolingNoUsually noYes
VM and LXC operations in one interfaceLow-level onlyDependsYes
Snapshot, backup, and restore workflowsLow-level onlyDependsYes
Persistent async job tracking and retryNoRareYes
Container command execution with policy controlsNoCustom onlyYes
Docker distribution pathNoRareYes
Repository-level live-environment verificationN/ARareYes

Scenario Templates

Ready-to-copy examples live in docs/examples/:

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.

If you need to...Start here
Understand the project and deployment flowWiki Home
Configure and run against a Proxmox environmentOperator Guide
Connect Claude Desktop, Cursor, VS Code, Codex, Open WebUI, or HTTP clientsClient Setup Guide
Choose the right tool for a workflowTool Selection Guide
Review docs quality goals, media plan, and publishing checklistDocumentation Quality Plan
Review integration patterns and transport detailsIntegrations Guide
Install from MCP-aware IDEs and agentsAgent Installation
Enable LXC command execution over SSHContainer Command Execution
Review security and command policySecurity Guide
Inspect tool parameters, prerequisites, and behaviorAPI & Tool Reference
Debug startup, auth, or health issuesTroubleshooting
Work on the codebase or release itDeveloper Guide
Review release and upgrade notesRelease & Upgrade Notes

Published wiki:

Repo Layout

  • src/proxmox_mcp/: MCP server, config loading, security, OpenAPI bridge
  • main.py: MCP entrypoint for local and client-driven usage
  • docker-compose.yml: HTTP/OpenAPI runtime
  • requirements/: auxiliary dependency sources and runtime install lists
  • scripts/: helper startup scripts for local workflows
  • tests/scripts/run_real_e2e.py: live Proxmox and Docker/OpenAPI path
  • tests/: unit and integration coverage
  • docs/examples/: scenario-driven prompts and HTTP examples
  • docs/wiki/: longer-form operator, integration, and reference docs

Development Checks

See Contributing for environment setup, test prerequisites, and pull request guidance.

bash
python -m pytest -qruff check .mypy src --ignore-missing-importspython -m pip_audit -r requirements/runtime.lock --require-hashes --disable-pip --strictpython -m build

CI also runs PostgreSQL-backed tests and enforces full runtime statement coverage and full branch coverage for critical modules. See Contributing for the exact coverage commands and Dependency updates for the reviewed runtime lock workflow.

Community

License

MIT

ISO installation and LXC network configuration

Use list_isos to find an existing ISO volume (or download_iso to obtain one). create_vm accepts iso_volume="local:iso/debian.iso", mounts it on ide3 by default and boots CD-ROM before disk. update_vm_config can mount or change that ISO, eject with iso_volume="none", set boot_order="scsi0;ide3", or change network_bridge on net0 while retaining MAC/VLAN/firewall settings. Choose a free cdrom_device; existing data disks and cloud-init drives are never replaced. Media and bridge edits read current configuration and therefore need VM.Audit as well as the relevant configuration privileges. Existing sizing/cloud-init-only updates still do not require a preliminary read.

LXC uses OS templates, not installer ISOs. create_container retains DHCP by default and now accepts network_bridge, ip="192.168.1.50/24", gw="192.168.1.1", ip6 and gw6. update_container_network edits those fields on an existing interface (default net0, selectable through net31) and preserves all unspecified options. Use an empty gateway string to remove it; changing to DHCP/manual removes the old gateway for that address family. Network changes can interrupt guest connectivity. Both edit tools follow named-target, read-only and high-risk approval policies. Add update_container_network to custom high-risk lists and desired tool allowlists. See v0.5.19 release notes for upgrade details.

Source: README.md at commit ab1fcf7

Tools

65

list_targets

List configured Proxmox targets without exposing credentials. A target name is required for other tools when multiple targets are configured.

Parametersapproval_token

get_nodes

List all nodes in the Proxmox cluster with their status, CPU, memory, and role information. Example: {"node": "pve1", "status": "online", "cpu_usage": 0.15, "memory": {"used": "8GB", "total": "32GB"}}

Parameterstargetapproval_token

get_node_status

Get detailed status information for a specific Proxmox node. Parameters: node* - Name/ID of node to query (e.g. 'pve1') Example: {"cpu": {"usage": 0.15}, "memory": {"used": "8GB", "total": "32GB"}}

Parametersnoderequiredtargetapproval_token

get_node_time

Read node epoch time, local time and timezone to diagnose PVE ticket clock skew. Read-only; requires node and accepts an optional configured target.

Parametersnoderequiredtargetapproval_token

list_bridges

List available network bridges (Linux, OVS and permitted SDN VNets) on a node for VM/LXC networking. Returns the Proxmox network records as JSON.

Parametersnoderequiredtargetapproval_token

get_node_diagnostics

Read CPU, I/O wait, memory, storage and latest observed RRD disk/network metrics for one node. Missing optional metrics produce partial results. Does not execute shell commands or list processes.

Parametersnoderequiredtargetapproval_token

get_storage

List storage pools across the cluster with their usage and configuration. Example: {"storage": "local-lvm", "type": "lvm", "used": "500GB", "total": "1TB"}

Parameterstargetapproval_token

get_node_storage

Read storage capacity and active/rootdir status on one specified node. Optionally filter by storage ID. Available bytes do not guarantee migration capacity, especially on thin-provisioned storage.

Parametersnoderequiredtargetstorageapproval_token

get_cluster_status

Get overall Proxmox cluster health and configuration status. Example: {"name": "proxmox", "quorum": "ok", "nodes": 3, "ha_status": "active"}

Parameterstargetapproval_token

get_cluster_join_info

Read public cluster join metadata and certificate fingerprints. Only documented public fields are returned. Authentication credentials and arbitrary extensions are omitted. Proxmox errors are reported.

Parameterstargetapproval_token

reconcile_job

Reconcile an interrupted retry after verifying its remote task or confirming that no task was submitted. Never submits a new operation.

Parametersupidjob_idrequiredtargetapproval_tokenconfirmed_not_submitted

list_jobs

List tracked long-running jobs created by MCP tools. Parameters: status - Filter by job status (optional) tool_name - Filter by originating tool (optional) limit - Maximum rows to return (default: 100)

Parameterslimitstatustargettool_nameapproval_token

get_job

Get the current state of a tracked job by job_id. Parameters: job_id* - Stable job identifier returned by long-running tools refresh - Poll Proxmox before returning the job state (default: false)

Parametersjob_idrequiredtargetrefreshapproval_token

poll_job

Poll the backing Proxmox task for a tracked job and refresh status/progress.

Parametersforcejob_idrequiredtargetinclude_auditapproval_token

cancel_job

Best-effort cancel for a tracked long-running job. This uses the stored Proxmox task UPID when cancellation is supported.

Parametersjob_idrequiredtargetapproval_token

retry_job

Retry a tracked long-running job using its stored retry recipe. The same job_id is preserved and its attempt counter is incremented.

Parametersjob_idrequiredtargetapproval_token

get_vms

List all virtual machines across the cluster with their status and resource usage. Example: {"vmid": "100", "name": "ubuntu", "status": "running", "cpu": 2, "memory": 4096}

Parameterstargetapproval_token

preflight_vm_migration

Read-only QEMU offline migration assessment using native Proxmox migration preconditions plus VM inventory, storage capacity, bridges and HA checks. Missing evidence blocks readiness. Requires VM.Migrate permission even for the native read. Backup restorability, workload drain and CPU compatibility need external verification. Does not move or stop a VM or reserve capacity.

Parametersnoderequiredvmidrequiredtargetdestinationrequiredapproval_token

migrate_vm

High-risk OFFLINE QEMU migration with local disks after read-only preflight and explicit confirmations of backup, workload drain, CPU compatibility and migration. The VM must already be stopped. Returns a submitted UPID/job ID, never completion. Never automatically retry uncertain submissions.

Parametersnoderequiredvmidrequiredtargetdestinationrequiredapproval_tokenconfirm_migrationconfirm_backup_verifiedconfirm_workload_drainedconfirm_cpu_compatibility

configure_vm_serial_console

Configure VM ttyS0 serial socket and serial VGA display after observing a stopped VM. Requires explicit confirmation and follows target high-risk policy. Preserves other serial devices and uses the config digest against concurrent config changes. The guest must configure serial login separately. SUBMISSION_UNCERTAIN requires inspection before any retry.

Parametersnoderequiredvmidrequiredtargetapproval_tokenconfirm_display_change

import_cloud_image

Import an existing qcow2/raw/vmdk image from Proxmox import-enabled storage into an unused VM SCSI slot via the asynchronous QEMU API. Requires an observed stopped VM, explicit confirmation and configured high-risk approval. Does not fetch URLs, overwrite disks or change boot order. Returns a submitted task, never completion. Inspect SUBMISSION_UNCERTAIN outcomes before any retry.

Parametersnoderequiredvmidrequiredtargetdisk_devicesource_volumerequiredapproval_tokenconfirm_importdestination_storagerequired

get_vm_config

Get the full configuration of a QEMU virtual machine. Returns hardware configuration including CPU, memory, disk, network, BIOS type, boot order, and more. This is equivalent to get_container_config but for QEMU VMs. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '100') Example: {"vmid": "100", "name": "ubuntu", "cores": 2, "memory": 4096, "scsi0": "local-lvm:vm-100-disk-0,size=20G"}

Parametersnoderequiredvmidrequiredtargetapproval_token

set_vm_description

Set/replace the description (Notes field in the UI) of a QEMU VM. Uses PUT /nodes/{node}/qemu/{vmid}/config. Pass an empty string to clear the notes. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '100') description* - New notes text (replaces any existing notes) Example: set_vm_description node='pve' vmid='100' description='Decommissioned - see #123'

Parametersnoderequiredvmidrequiredtargetdescriptionrequiredapproval_token

get_next_vmid

Get the next free VM/container ID in the cluster. Uses GET /cluster/nextid. Call it right before clone_vm or create_vm so the target ID is one Proxmox itself considers unused. Example: {"vmid": "105"}

Parameterstargetapproval_token

update_vm_config

Update sizing, cloud-init, ISO media, boot order and net0 bridge of an existing QEMU VM. iso_volume accepts a storage volume ID or none to eject. cdrom_device defaults to ide3; existing disks and cloud-init drives cannot be overwritten. boot_order uses semicolon-separated device names. network_bridge preserves the other net0 options. Uses PUT /nodes/{node}/qemu/{vmid}/config with only the supplied fields. This is the step between clone_vm and start_vm that makes a fresh clone reachable: inject SSH keys, set the cloud-init user, pick a static IP, resize memory. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '105') memory - RAM in MiB (e.g. 4096) cores - CPU cores per socket sockets - CPU sockets name - New VM name (DNS label) sshkeys - OpenSSH public keys, one per line (cloud-init; percent-encoded for you) ciuser - cloud-init user name (e.g. 'ubuntu') ipconfig0 - cloud-init IP for net0, e.g. 'ip=dhcp' or 'ip=10.0.0.5/24,gw=10.0.0.1' nameserver - cloud-init DNS server(s) searchdomain - cloud-init DNS search domain tags - Proxmox tags, semicolon-separated approval_token - Approval token when required by the target's high-risk policy This tool is classified as high risk, including SSH key changes, and follows the selected target's command_policy.high_risk_* settings. Cloud-init fields take effect at the guest's next boot; sizing changes on a running VM stay pending until it restarts. Example: update_vm_config node='pve' vmid='105' memory=4096 ciuser='hola' sshkeys='ssh-ed25519 AAAA... ci@host'

Parametersnamenoderequiredtagsvmidrequiredcoresciusermemorytargetsocketssshkeysipconfig0boot_order+6 more

get_vm_ip_addresses

Get a running VM's network interfaces and IP addresses via the QEMU guest agent. Uses GET /nodes/{node}/qemu/{vmid}/agent/network-get-interfaces. The VM must be running with qemu-guest-agent active. Loopback is skipped; primary_ip is the first non-loopback IPv4 address. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '105') Example: {"vmid": "105", "primary_ip": "10.0.0.57", "interfaces": [{"name": "eth0", "mac": "bc:24:11:..", "ipv4": ["10.0.0.57"], "ipv6": ["fe80::..."]}]}

Parametersnoderequiredvmidrequiredtargetapproval_token

create_vm

Create a new virtual machine with specified configuration. Optionally mount an existing iso_volume (e.g. local:iso/debian.iso) at cdrom_device (default ide3). With an ISO, the default boot order is CD-ROM then disk; boot_order can specify semicolon-separated device names. Parameters: node* - Host node name (e.g. 'pve') vmid* - New VM ID number (e.g. '200', '300') name* - VM name (e.g. 'my-new-vm', 'web-server') cpus* - Number of CPU cores (e.g. 1, 2, 4) memory* - Memory size in MB (e.g. 2048 for 2GB, 4096 for 4GB) disk_size* - Disk size in GB (e.g. 10, 20, 50) storage - Storage name (optional, will auto-detect if not specified) ostype - OS type (optional, default: 'l26' for Linux) network_bridge - Network bridge name (optional, default: 'vmbr0') pool - Target Proxmox resource pool (optional) Examples: - Create VM with 1 CPU, 2GB RAM, 10GB disk: node='pve', vmid='200', name='test-vm', cpus=1, memory=2048, disk_size=10 - Create VM with 2 CPUs, 4GB RAM, 20GB disk: node='pve', vmid='201', name='web-server', cpus=2, memory=4096, disk_size=20

Parameterscpusrequirednamerequirednoderequiredpoolvmidrequiredmemoryrequiredostypetargetstoragedisk_sizerequiredboot_orderiso_volume+3 more

clone_vm

Clone an existing virtual machine. Parameters: node* - Source host node name that currently owns the VM (e.g. 'pve') source_vmid* - Existing source VM ID (e.g. '9000') target_vmid* - New VM ID for the clone (e.g. '201') name - New VM name (optional) target_node - Destination node for the clone (optional, defaults to source node) full - Full clone (true, default) or linked clone (false) storage - Target storage (optional) pool - Target resource pool (optional) snapname - Snapshot name to clone from (optional) Example: clone_vm node='pve' source_vmid='9000' target_vmid='201' name='web-201' full=true

Parametersfullnamenoderequiredpooltargetstoragesnapnamesource_vmidrequiredtarget_nodetarget_vmidrequiredapproval_token

execute_vm_command

Execute commands in a VM via QEMU guest agent. Parameters: node* - Host node name (e.g. 'pve1') vmid* - VM ID number (e.g. '100') command* - Shell command to run (e.g. 'uname -a') Example: {"success": true, "output": "Linux vm1 5.4.0", "exit_code": 0}

Parametersnoderequiredvmidrequiredtargetcommandrequiredguest_osapproval_token

start_vm

Start a virtual machine. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '101') Example: Power on VPN-Server with ID 101 on node pve

Parametersnoderequiredvmidrequiredtargetapproval_token

stop_vm

Stop a virtual machine (force stop). Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '101') Example: Force stop VPN-Server with ID 101 on node pve

Parametersnoderequiredvmidrequiredtargetapproval_token

shutdown_vm

Shutdown a virtual machine gracefully. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '101') Example: Gracefully shutdown VPN-Server with ID 101 on node pve

Parametersnoderequiredvmidrequiredtargetapproval_token

reset_vm

Reset (restart) a virtual machine. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '101') Example: Reset VPN-Server with ID 101 on node pve

Parametersnoderequiredvmidrequiredtargetapproval_token

delete_vm

Delete/remove a virtual machine completely. WARNING: This operation permanently deletes the VM and all its data! Parameters: node* - Host node name (e.g. 'pve') vmid* - VM ID number (e.g. '998') force - Force deletion even if VM is running (optional, default: false) purge - Also remove the VMID from HA resources and backup/replication jobs (optional, default: false). Required when the VM is an HA resource. This will permanently remove: - VM configuration - All virtual disks - All snapshots - Cannot be undone! Examples: - Delete test VM with ID 998 on node pve - Delete HA-managed VM 998 on node pve: purge=True

Parametersnoderequiredvmidrequiredforcepurgetargetapproval_token

get_containers

List LXC containers across the cluster (or filter by node). Parameters: - node (optional): Node name to filter (e.g. 'pve1') - include_stats (bool, default false): Fetch per-container live CPU/memory stats - include_raw (bool, default false): Include raw Proxmox API payloads for debugging - format_style ('pretty'|'json', default 'pretty'): Pretty text or raw JSON list Notes: - Live stats from /nodes/{node}/lxc/{vmid}/status/current. - If maxmem is 0 (unlimited), memory limit falls back to /config.memory (MiB). - If live returns zeros, the most recent RRD sample is used as a fallback. - Fields provided: cores (CPU cores/cpulimit), memory (MiB limit), cpu_pct, mem_bytes, maxmem_bytes, mem_pct, unlimited_memory.

Parametersnodetargetpayloadinclude_rawformat_styleinclude_statsapproval_token

start_container

Start one or more LXC containers. selector: '123' | 'pve1:123' | 'pve1/name' | 'name' | comma list Example: start_container selector='pve1:101,pve2/web'

Parameterstargetselectorrequiredformat_styleapproval_token

stop_container

Stop LXC containers. graceful=True uses shutdown; otherwise force stop. selector: same grammar as start_container timeout_seconds: 10 (default)

Parameterstargetgracefulselectorrequiredformat_styleapproval_tokentimeout_seconds

restart_container

Restart LXC containers (reboot). selector: same grammar as start_container

Parameterstargetselectorrequiredformat_styleapproval_tokentimeout_seconds

update_container_resources

Update resources for one or more LXC containers. selector: same grammar as start_container cores: New CPU core count (optional) memory: New memory limit in MiB (optional) swap: New swap limit in MiB (optional) disk_gb: Additional disk size in GiB to add (optional) disk: Disk identifier to resize (default 'rootfs')

Parametersdiskswapcoresmemorytargetdisk_gbselectorrequiredformat_styleapproval_token

create_container

Create a new LXC container from an OS template (not an ISO). Choose network_bridge and optional ip (IPv4/CIDR, dhcp or manual), gw, ip6 (IPv6/CIDR, auto, dhcp or manual) and gw6. IPv4 defaults to DHCP. Use update_container_network to edit network settings after creation. Parameters: node* - Host node name (e.g. 'pve', 'pveZ3') vmid* - Container ID number (e.g. '200', '300') ostemplate* - OS template path (e.g. 'local:vztmpl/alpine-3.19-default_20240207_amd64.tar.xz') hostname - Container hostname (optional, defaults to 'ct-{vmid}') cores - Number of CPU cores (optional, default: 1) memory - Memory size in MiB (optional, default: 512) swap - Swap size in MiB (optional, default: 512) disk_size - Root disk size in GB (optional, default: 8) storage - Storage pool for rootfs (optional, auto-detects if not specified) password - Root password (optional) ssh_public_keys - SSH public keys for root user (optional) network_bridge - Network bridge name (optional, default: 'vmbr0') start_after_create - Start container after creation (optional, default: false) onboot - Start container automatically on host boot (optional, default: false) nesting - Enable LXC nesting (optional, sets features='nesting=1', default: false) unprivileged - Create unprivileged container (optional, default: true) pool - Target Proxmox resource pool (optional) Examples: - Create Alpine container: node='pveZ3', vmid='200', ostemplate='local:vztmpl/alpine-3.19-default_20240207_amd64.tar.xz' - Create with custom resources: node='pve', vmid='201', ostemplate='local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst', cores=2, memory=2048, disk_size=20

Parametersgwipgw6ip6noderequiredpoolswapvmidrequiredcoresmemoryonboottarget+11 more

update_container_network

Update an existing LXC network interface: bridge, static IPv4/IPv6, DHCP and gateways. Preserves MAC, VLAN, firewall and other NIC settings. Use an empty gateway to remove it.

Parametersgwipgw6ip6noderequiredvmidrequiredtargetinterfaceapproval_tokennetwork_bridge

delete_container

Delete/remove an LXC container completely. WARNING: This operation permanently deletes the container and all its data! Parameters: selector* - Container selector: '123' | 'pve1:123' | 'pve1/name' | 'name' | comma list force - Force deletion even if container is running (optional, default: false) purge - Also remove the CTID from HA resources and backup/replication jobs (optional, default: false). Required when the container is an HA resource. This will permanently remove: - Container configuration - Root filesystem and all data - All snapshots - Cannot be undone! Examples: - Delete container 200: selector='200' - Delete by name: selector='my-container' - Force delete running container: selector='pve:201', force=True - Delete HA-managed container: selector='pve:202', purge=True

Parametersforcepurgetargetselectorrequiredformat_styleapproval_token

migrate_container

Submit an LXC migration after fresh preflight checks. Requires confirm_migration=True; restart=True also requires confirm_downtime=True. Follows the configured target's high-risk approval policy. Returns a submitted task UPID and optional job ID, never completion. Never automatically retries; SUBMISSION_UNCERTAIN requires inspecting Proxmox tasks and guest location before any retry.

Parametersnoderequiredvmidrequiredtargetrestartdestinationrequiredapproval_tokenconfirm_downtimeconfirm_migration

preflight_container_migration

Read-only LXC migration assessment: checks nodes, rootfs storage and space, runtime, extra mounts/devices, HA and matching backups. Missing evidence blocks readiness. This advisory does not reserve capacity, test restoreability or migrate. Running guests require allow_downtime=True.

Parametersnoderequiredvmidrequiredtargetdestinationrequiredallow_downtimeapproval_token

get_container_config

Get the full configuration of an LXC container. Returns network interfaces, mounts, features, CPU/memory limits, startup options and more. Parameters: node* - Proxmox node name (e.g. 'pve') vmid* - Container ID (e.g. '101') Example: {"vmid": "101", "hostname": "valkey", "cores": 1, "memory": 1024, "net0": "name=eth0,..."}

Parametersnoderequiredvmidrequiredtargetapproval_token

set_container_description

Set/replace the description (Notes field in the UI) of an LXC container. Uses PUT /nodes/{node}/lxc/{vmid}/config. Pass an empty string to clear the notes. Parameters: node* - Proxmox node name (e.g. 'pve') vmid* - Container ID (e.g. '101') description* - New notes text (replaces any existing notes) Example: set_container_description node='pve' vmid='101' description='GitLab Runner host (ct101-alpine)'

Parametersnoderequiredvmidrequiredtargetdescriptionrequiredapproval_token

get_container_ip

Get the current IP address(es) of a running LXC container. Queries /nodes/{node}/lxc/{vmid}/interfaces - works with DHCP (no static IP needed). Parameters: node* - Proxmox node name (e.g. 'pve') vmid* - Container ID (e.g. '101') Returns: {"vmid": "101", "name": "valkey", "interfaces": [...], "primary_ip": "10.1.0.101"}

Parametersnoderequiredvmidrequiredtargetapproval_token

list_snapshots

List all snapshots for a VM or container. Parameters: node* - Host node name (e.g. 'pve') vmid* - VM or container ID (e.g. '100') vm_type - Type: 'qemu' for VMs, 'lxc' for containers (default: 'qemu') Example: list_snapshots node='pve' vmid='100' vm_type='qemu'

Parametersnoderequiredvmidrequiredtargetvm_typeapproval_token

create_snapshot

Create a snapshot of a VM or container. Parameters: node* - Host node name vmid* - VM or container ID snapname* - Snapshot name (no spaces, e.g. 'before-update') description - Optional description vmstate - Include memory state (VMs only, default: false) vm_type - Type: 'qemu' or 'lxc' (default: 'qemu') Examples: - Create VM snapshot: node='pve', vmid='100', snapname='pre-upgrade' - Create with RAM state: node='pve', vmid='100', snapname='state1', vmstate=true

Parametersnoderequiredvmidrequiredtargetvm_typevmstatesnapnamerequireddescriptionapproval_token

delete_snapshot

Delete a snapshot. Parameters: node* - Host node name vmid* - VM or container ID snapname* - Snapshot name to delete vm_type - Type: 'qemu' or 'lxc' (default: 'qemu') Example: delete_snapshot node='pve' vmid='100' snapname='old-snapshot'

Parametersnoderequiredvmidrequiredtargetvm_typesnapnamerequiredapproval_token

rollback_snapshot

Rollback VM/container to a previous snapshot. WARNING: This will stop the VM/container and restore to the snapshot state! Parameters: node* - Host node name vmid* - VM or container ID snapname* - Snapshot name to restore vm_type - Type: 'qemu' or 'lxc' (default: 'qemu') Example: rollback_snapshot node='pve' vmid='100' snapname='before-update'

Parametersnoderequiredvmidrequiredtargetvm_typesnapnamerequiredapproval_token

list_isos

List available ISO images across the cluster. Parameters: node - Filter by node (optional) storage - Filter by storage pool (optional) Returns list of ISOs with filename, size, and storage location.

Parametersnodetargetstorageapproval_token

list_templates

List available OS templates for container creation. Parameters: node - Filter by node (optional) storage - Filter by storage pool (optional) Returns list of templates (vztmpl) with name, size, and storage. Use the returned Volume ID with create_container's ostemplate parameter.

Parametersnodetargetstorageapproval_token

download_iso

Download an ISO image from a URL to Proxmox storage. Parameters: node* - Target node name storage* - Target storage pool (must support ISO content) url* - URL to download from filename* - Target filename (e.g. 'ubuntu-22.04-live-server-amd64.iso') checksum - Optional checksum for verification checksum_algorithm - Algorithm: sha256, sha512, md5 (default: sha256) Example: download_iso node='pve' storage='local' url='https://...' filename='ubuntu.iso'

Parametersurlrequirednoderequiredtargetstoragerequiredchecksumfilenamerequiredapproval_tokenchecksum_algorithm

download_template

Submit an HTTPS LXC template download through Proxmox (content=vztmpl). Required: node, storage supporting vztmpl, trusted HTTPS url, safe filename ending in .tar.gz/.tar.xz/.tar.zst. Optional checksum and checksum_algorithm (sha256, sha512, md5). TLS verification stays enabled. High-risk/target/read-only policy applies. Rejects observed existing filenames; preflight does not reserve space or prevent concurrent writes. Proxmox downloads from its own network: HTTPS is not an SSRF boundary. Use trusted publishers and preferably a SHA-256/SHA-512 checksum. A submitted UPID is not completed work: poll_job then list_templates. Local job tracking failure retains the UPID. SUBMISSION_UNCERTAIN requires manual task/storage inspection before another call. This operation has no automatic or job retry recipe.

Parametersurlrequirednoderequiredtargetstoragerequiredchecksumfilenamerequiredapproval_tokenchecksum_algorithm

delete_iso

Delete an ISO or template from storage. Parameters: node* - Node name storage* - Storage pool name filename* - ISO/template filename to delete Example: delete_iso node='pve' storage='local' filename='old-distro.iso'

Parametersnoderequiredtargetstoragerequiredfilenamerequiredapproval_token

list_backups

List available backups across the cluster. Parameters: node - Filter by node (optional) storage - Filter by storage pool (optional) vmid - Filter by VM/container ID (optional) Returns backups with timestamp, size, compression, and notes. Use the returned Volume ID with restore_backup.

Parametersnodevmidtargetstorageapproval_token

create_backup

Create a backup of a VM or container. Parameters: node* - Node where VM/container runs vmid* - VM or container ID to backup storage* - Target backup storage compress - Compression: 0, gzip, lz4, zstd (default: zstd) mode - Backup mode: snapshot, suspend, stop (default: snapshot) notes - Optional notes/description for the backup Example: create_backup node='pve' vmid='100' storage='backup-storage' compress='zstd'

Parametersmodenoderequiredvmidrequirednotestargetstoragerequiredcompressapproval_token

restore_backup

Restore a VM or container from a backup. Parameters: node* - Target node for restore archive* - Backup volume ID (from list_backups output) vmid* - New VM/container ID for the restored machine storage - Target storage for disks (optional, uses original if not specified) unique - Generate unique MAC addresses (default: true) Example: restore_backup node='pve' archive='backup:backup/vzdump-qemu-100-2024_01_15.vma.zst' vmid='200'

Parametersnoderequiredvmidrequiredtargetuniquearchiverequiredstorageapproval_token

delete_backup

Delete a backup file from storage. WARNING: This permanently deletes the backup! Parameters: node* - Node name storage* - Storage pool name volid* - Backup volume ID to delete Example: delete_backup node='pve' storage='backup-storage' volid='backup:backup/vzdump-qemu-100-2024_01_15.vma.zst'

Parametersnoderequiredvolidrequiredtargetstoragerequiredapproval_token

get_node_syslog

Read syslog entries from a Proxmox node. Parameters: node* - Node name (e.g. 'pve', 'pve1') limit - Maximum number of log lines to return (default: 100, max: 1000) start - Start line for pagination (0-based, optional) since - Show entries from this date/time onward (format: YYYY-MM-DD or YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS, optional) until - Show entries up to this date/time (same format as since, optional) service - Filter by service name (e.g. 'pvedaemon', 'pveproxy', optional) Example: get_node_syslog node='pve' limit=50 service='pvedaemon'

Parametersnoderequiredlimitsincestartuntiltargetserviceapproval_token

get_task_log

Get the log output of a specific Proxmox task by its UPID. Parameters: node* - Node name that ran the task (e.g. 'pve') upid* - Unique Process ID of the task (e.g. the Task ID returned by VM/container operations or list_jobs) start - Start line for pagination (0-based, optional) limit - Maximum number of log lines to return (default: 50, max: 500) Example: get_task_log node='pve' upid='UPID:pve:00001234:...' limit=100

Parametersnoderequiredupidrequiredlimitstarttargetapproval_token

get_cluster_log

Read recent cluster-wide log entries. Parameters: max_entries - Maximum number of entries to return (default: 50, max: 1000) Each entry includes: time, node, user, tag (service), pri (priority), msg. Example: get_cluster_log max_entries=100

Parameterstargetmax_entriesapproval_token

get_node_firewall_log

Read the host firewall log of a Proxmox node. Parameters: node* - Node name (e.g. 'pve', 'pve1') limit - Maximum number of log lines to return (default: 100, max: 1000) start - Start line for pagination (0-based, optional) since - Show entries since this UNIX epoch timestamp (optional) until - Show entries until this UNIX epoch timestamp (optional) Example: get_node_firewall_log node='pve' limit=50

Parametersnoderequiredlimitsincestartuntiltargetapproval_token

get_guest_firewall_log

Read the firewall log of a VM (qemu) or container (lxc). Parameters: node* - Node hosting the guest (e.g. 'pve') vmid* - VM/container ID (e.g. 100) vm_type - Guest type: 'qemu' (default) or 'lxc' limit - Maximum number of log lines to return (default: 100, max: 1000) start - Start line for pagination (0-based, optional) since - Show entries since this UNIX epoch timestamp (optional) until - Show entries until this UNIX epoch timestamp (optional) Example: get_guest_firewall_log node='pve' vmid=100 vm_type='qemu' limit=50

Parametersnoderequiredvmidrequiredlimitsincestartuntiltargetvm_typeapproval_token

Version history

15
  1. v0.6.9LatestNov 4, 2026
  2. v0.6.8Oct 29, 2026
  3. v0.6.6Oct 20, 2026
  4. v0.6.5Oct 19, 2026
  5. v0.6.3Oct 18, 2026
  6. v0.6.2Oct 12, 2026
  7. v0.6.1Oct 9, 2026
  8. v0.5.27Oct 7, 2026
  9. v0.5.26Oct 7, 2026
  10. v0.5.24Oct 1, 2026
  11. v0.5.23Sep 26, 2026
  12. v0.5.22Sep 26, 2026
  13. v0.5.20Sep 24, 2026
  14. v0.5.19Sep 21, 2026
  15. v0.5.17Sep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts