Which integrations are available for this server?

Provides tools for interacting with Proxmox VE, including cluster status, guest inventory, node status, power actions (start, shutdown, reboot, stop) on QEMU/LXC guests, and snapshot creation.

How do I use proxmox-safe-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@proxmox-safe-mcp list all guests and show cluster status" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

proxmox-safe-mcp

by bgauger

Overview Schema Source Related Servers Discussions Admin

Python

Local

Proxmox Safe MCP

A focused Proxmox MCP server exposing bounded inventory/status reads and only two narrow mutation classes: allowlisted guest power actions and snapshot creation. Extracted from spectrenet-mcp commit 2e63f009d8f4642e17398685baef0251811d6637; this repository is self-contained.

Alpha: tests are synthetic. Proxmox API compatibility has not been certified against every release; test on non-production infrastructure.

Safety contract

Nodes are explicitly allowlisted for node-targeted operations (node_status) and both mutation tools; guest types are only qemu and lxc; VMIDs must be positive integers.
cluster_status and list_guests intentionally return cluster-wide API views and are not filtered by the node allowlist. Scope the dedicated Proxmox API account/token to limit what these read tools can see.
Power actions are only start, shutdown, reboot, and stop.
Snapshot names are 1–64 ASCII letters, digits, _, or -.
Every mutation needs byte-for-byte APPROVE <action> <target> confirmation.
Mutation responses are submission receipts, not completion proof. Verify the returned UPID and final state separately.
There are no guest/snapshot deletion, host-power, storage mutation, allocation, migration, or configuration tools. node_status deliberately excludes storage enumeration.
Responses/lists/audit fields are bounded and TLS verification defaults on.

Related MCP server: Proximo

Install and run

uv sync --extra test
uv run proxmox-safe-mcp --help
uv run proxmox-safe-mcp

The server uses MCP stdio. It does not load .env; use .env.example only as fake documentation and inject secrets through a supervisor or secret manager.

Verify

uv sync --locked --extra test
uv run --locked pytest
uv run --locked python -m compileall -q src tests
uv build

Available Tools

5 tools

cluster_statusD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

guest_powerD

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes
`vmid`	Yes
`action`	Yes
`confirm`	No
`guest_type`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_guestsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

node_statusD

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

snapshot_guestD

ParametersJSON Schema

Name	Required	Description	Default
`node`	Yes
`vmid`	Yes
`confirm`	No
`guest_type`	Yes
`snapshot_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Aug 25, 2026
- First observedcluster_status
- First observedguest_power
- First observedlist_guests
- First observednode_status
- First observedsnapshot_guest

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.9/5.0

Scored 2026-08-25 01:35 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect of the Proxmox environment: cluster status, node status, guest listing, guest power control, and guest snapshotting. There is no overlap in purposes, making selection unambiguous.

Naming Consistency3/5

The names mix noun-initial patterns (cluster_status, node_status, guest_power) with verb-initial patterns (list_guests, snapshot_guest). This inconsistency is noticeable but still readable and predictable overall.

Tool Count5/5

With only 5 tools, the server is tightly scoped and each tool serves a clear purpose. This is well-balanced for a specialized MCP server focused on monitoring and safe guest operations.

Completeness3/5

The set covers status, listing, power, and snapshot operations but lacks lifecycle management (create, update, delete guests). While potentially intentional for a 'safe' server, it leaves notable gaps for full Proxmox administration.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2353
Hermes Plant — Agent Commerce Assurance A
io.github.JesseGdotIO
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Finance AI & Machine Learning
2522
penholder
ai.penholder
Preventive human-approval write-gate for AI agents: writes commit only after a human approves.
Security Autonomous Agents Agent Orchestration
1
SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
28

Related MCP Servers

ProxmoxMCP-Plus
Virtualization Monitoring
rodaddy
A
license
Not graded
quality
C
maintenance
Enables comprehensive management of Proxmox virtualization environments, including VM and container lifecycle, snapshots, backups, monitoring, and OpenAPI integration.
Updated 25 days ago (2026-08-23 00:22 UTC)
14
MIT
Proximo
App Automation Shell Access Virtualization
john-broadway
A
license
A
quality
A
maintenance
Enables management of Proxmox VE infrastructure via its REST API and execution of commands inside LXC containers via SSH, with built-in trust layers for planning, audit, undo, and diagnosis.
Updated 3 days ago (2026-09-13 21:30 UTC)
7
506 PyPI
44
Apache 2.0
Proxmox MCP Server
Virtualization Cloud Platforms Networking & Infrastructure
jskoetsier
A
license
C
quality
D
maintenance
Enables management of Proxmox VE environments, including VMs, containers, storage, and cluster operations through natural language.
Updated 7 months ago (2026-02-13 07:43 UTC)
76
65 npm
MIT
proxmox-mcp
Virtualization Shell Access Command Line
ssan9876
F
license
A
quality
C
maintenance
Enables an AI assistant to fully navigate a single-node Proxmox VE host over SSH, with modes for read-only inspection, safe operations, and full control including provisioning and destruction.
Updated a month ago (2026-08-06 04:05 UTC)
34
-