Proxmox MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROXMOX_HOST | No | API base URL, e.g. https://192.168.1.10:8006 | |
| PROXMOX_USER | No | user@realm for ticket auth (used only if no token) | |
| PROXMOX_MCP_DEMO | No | Serve fabricated demo data (no real host needed) | false |
| PROXMOX_PASSWORD | No | Password for ticket auth | |
| PROXMOX_TOKEN_ID | No | API token id user@realm!tokenname (recommended) | |
| PROXMOX_MCP_CONFIG | No | Path to the optional JSON config file | proxmox-mcp.config.json |
| PROXMOX_VERIFY_TLS | No | Verify the node's TLS certificate | false |
| PROXMOX_MCP_PLUGINS | No | Load only these plugins (empty = all) | |
| PROXMOX_MCP_READONLY | No | Hide all state‑changing tools | false |
| PROXMOX_TOKEN_SECRET | No | API token secret (UUID) | |
| PROXMOX_MCP_ALLOWLIST | No | Comma‑separated VMIDs/names the AI may touch (empty = all) | |
| PROXMOX_MCP_LOG_LEVEL | No | debug | info | warn | error | info |
| PROXMOX_MCP_DISABLED_PLUGINS | No | Disable these plugins |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pluginsA | Show the modular capability plugins this server exposes and whether each is currently enabled. |
| aboutA | Show who built this Proxmox MCP Server and how it is licensed. Call this to greet the user with the SoyRage Agency welcome banner. |
| list_nodesA | List the Proxmox VE cluster nodes with their online status, CPU load and memory usage. The best starting point to understand the cluster. |
| node_statusA | Detailed status for a single node: CPU/memory/swap, load average, uptime, kernel and PVE versions. |
| list_guestsA | List all QEMU virtual machines and LXC containers across the cluster with their VMID, type, node, status and live CPU/memory. Optionally filter by kind ('qemu' or 'lxc') or only running guests. |
| guest_statusA | Live runtime status of a single VM or container: run state, CPU %, memory, disk, uptime and (for VMs) QEMU guest-agent availability. |
| guest_configA | Return the full configuration of a VM or container (cores, memory, disks, network interfaces, boot order, …). |
| guest_osinfoA | What operating system does a guest run? Returns the configured OS type and, for running QEMU VMs with the guest agent, the detected OS name/version and IP addresses. Answers 'what OS is VMID 101?'. |
| list_storageA | List the storages configured on a node — type (dir/lvm/zfs/ceph/nfs…), what content they hold, and how full they are. |
| list_tasksA | List the most recent tasks on a node (VM starts, backups, migrations, snapshots…) with their type, status and who ran them. Great for answering 'what happened on this node lately?'. |
| cluster_statusA | Report cluster membership and quorum: each node's online state and whether the cluster is quorate. On a single node it reports standalone. |
| cluster_resourcesA | A single consolidated view of the cluster's resources — nodes, VMs, containers and storage — with status and utilisation. Filter by type. |
| list_snapshotsA | List the snapshots of a VM or container, including their name, parent and description. The synthetic 'current' entry marks the live state. |
| create_snapshotA | Take a snapshot of a VM or container. Optionally include the VM's RAM ( |
| rollback_snapshotA | Revert a VM or container to a snapshot. This is DESTRUCTIVE — any changes made since the snapshot are lost. Confirm with the user first. |
| delete_snapshotB | Remove a snapshot from a VM or container. |
| start_guestA | Power on a VM or container. No-op if it is already running. |
| shutdown_guestA | Gracefully shut down a VM or container via ACPI/guest OS. This is the safe way to power off — prefer it over |
| stop_guestA | Immediately stop a VM or container — equivalent to pulling the power cord. May cause data loss; prefer |
| reboot_guestA | Gracefully reboot a running VM or container. |
| suspend_guestA | Suspend (pause) a running VM — freezes it in RAM so it can be resumed instantly. Set |
| resume_guestB | Resume a suspended/paused VM. |
| migrate_guestA | Migrate a VM or container to another cluster node. Running guests are migrated online (live) when possible. |
| clone_guestA | Clone a VM or container into a new one. Great for deploying from a template. |
| set_guest_resourcesB | Quickly change a guest's CPU cores and/or memory. For VMs, memory is in MB. Some changes need a reboot to take effect. |
| backup_guestA | Create a backup of a VM or container to a storage using vzdump. |
| delete_guestA | PERMANENTLY destroy a VM or container and its disks. IRREVERSIBLE. You must pass |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 27 tools
Each tool targets a distinct action or resource. For example, guest_status, guest_config, and guest_osinfo are clearly separate. Even closely related tools like cluster_resources and cluster_status have well-defined, non-overlapping purposes.
Most tools follow a verb_noun pattern (e.g., backup_guest, list_nodes), but a few like guest_config, cluster_status, and about deviate slightly. Overall, naming is clear and predictable.
27 tools cover a wide range of Proxmox management tasks (cluster, nodes, guests, storage, backups, snapshots) without being excessive. The count feels well-scoped for the server's purpose.
Core workflows are addressed, but there are gaps like no direct 'create guest' (only clone), no tool to update full guest config, no restore from backup, and limited node maintenance actions. These missing operations could cause agent failures in some scenarios.