Skip to main content
Glama
proxmox-safe-mcp

proxmox-safe-mcp

by bgauger

Proxmox Safe MCP

제한된 인벤토리/상태 읽기와 두 가지 좁은 변형 클래스(허용 목록에 등록된 게스트 전원 작업 및 스냅샷 생성)만 노출하는 집중형 Proxmox MCP 서버입니다. spectrenet-mcp 커밋 2e63f009d8f4642e17398685baef0251811d6637에서 추출되었으며, 이 저장소는 자체 포함(self-contained)입니다.

알파: 테스트는 합성(synthetic)입니다. 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: proxmox-mcp

설치 및 실행

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 tools
cluster_statusD
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

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
NameRequiredDescriptionDefault
nodeYes
vmidYes
actionYes
confirmNo
guest_typeYes

Output Schema

NameRequiredDescription

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
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

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
NameRequiredDescriptionDefault
nodeYes

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
NameRequiredDescriptionDefault
nodeYes
vmidYes
confirmNo
guest_typeYes
snapshot_nameYes

Output Schema

NameRequiredDescription

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.

  1. 5 tool updatesv0.1.0
    • First observedcluster_status
    • First observedguest_power
    • First observedlist_guests
    • First observednode_status
    • First observedsnapshot_guest

TDQS

D1.9/5.0

Scored 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

ActivityStale
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers

  • 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.
    6
    740 PyPI
    85
    AGPL 3.0
  • F
    license
    A
    quality
    D
    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.
    34
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables management of many Proxmox VE clusters from a single server, exposing read and inventory tools plus guarded destructive operations that follow a plan → approve → apply flow. Per-cluster tokens, fail-closed guest protection with time-boxed waivers, and audit logging keep every action scoped, attributable, and reversible.
    1
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables MCP clients to diagnose Proxmox VE clusters — quorum and HA state, Ceph and ZFS health, backup coverage audits, task failures, pending updates and node evacuation planning — with answers returned as findings and recommended steps. VM power, snapshot and migration operations are available but disabled by default, requiring a preview and a bound confirmation token before anything executes.
    13
    153 PyPI
    MIT