proxmox-safe-mcp
Proxmox Safe MCP
Сфокусированный Proxmox MCP сервер, предоставляющий ограниченные операции чтения инвентаря/статуса и только два узких класса мутаций: разрешённые действия с питанием гостевых систем и создание снимков. Извлечено из коммита spectrenet-mcp 2e63f009d8f4642e17398685baef0251811d6637; этот репозиторий самодостаточен.
Альфа: тесты синтетические. Совместимость с Proxmox API не сертифицирована для каждого релиза; тестируйте на непродакшн-инфраструктуре.
Контракт безопасности
Узлы явно внесены в белый список для операций, нацеленных на узлы (
node_status), и обоих инструментов мутаций; типы гостевых систем — толькоqemuиlxc; VMID должны быть положительными целыми числами.cluster_statusиlist_guestsнамеренно возвращают представления API на уровне кластера и не фильтруются по белому списку узлов. Ограничьте выделенную учётную запись/токен Proxmox API, чтобы ограничить, что могут видеть эти инструменты чтения.Действия с питанием — только
start,shutdown,rebootиstop.Имена снимков — 1–64 буквы ASCII, цифры,
_или-.Каждая мутация требует подтверждения
APPROVE <action> <target>байт-в-байт.Ответы на мутации — это квитанции о приёме, а не доказательство завершения. Проверяйте возвращённый UPID и конечное состояние отдельно.
Нет инструментов для удаления гостевых систем/снимков, управления питанием хоста, изменения хранилища, выделения ресурсов, миграции или конфигурации.
node_statusнамеренно исключает перечисление хранилища.Ответы/списки/поля аудита ограничены, а проверка TLS включена по умолчанию.
Related MCP server: Proximo
Установка и запуск
uv sync --extra test
uv run proxmox-safe-mcp --help
uv run proxmox-safe-mcpСервер использует MCP stdio. Он не загружает .env; используйте .env.example только как фиктивную документацию и внедряйте секреты через супервизор или менеджер секретов.
Проверка
uv sync --locked --extra test
uv run --locked pytest
uv run --locked python -m compileall -q src tests
uv buildСм. архитектуру и операции и детали безопасности. MIT © 2026 Ben Gauger.
Available Tools
5 toolscluster_statusD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| vmid | Yes | ||
| action | Yes | ||
| confirm | No | ||
| guest_type | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | ||
| vmid | Yes | ||
| confirm | No | ||
| guest_type | Yes | ||
| snapshot_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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 updates
v0.1.0- First observed
cluster_status - First observed
guest_power - First observed
list_guests - First observed
node_status - First observed
snapshot_guest
TDQS
Scored across 5 tools
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.
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.
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.
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
Related MCP Connectors
- emisarOAuthdev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Manage remote servers, SSH terminals, files, databases and proxies with scoped access and approvals.
1Preventive human-approval write-gate for AI agents: writes commit only after a human approves.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables comprehensive management of Proxmox virtualization environments, including VM and container lifecycle, snapshots, backups, monitoring, and OpenAPI integration.14MIT
- AlicenseAqualityAmaintenanceEnables 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.7533 PyPI56Apache 2.0
- FlicenseAqualityCmaintenanceEnables 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.34-
- FlicenseNot gradedqualityCmaintenanceEnables managing a Proxmox cluster through natural language chat, including VM/container inventory, power control, configuration changes, cloning, snapshots, network/firewall visibility, and running commands or writing files inside guests.-