rust-proxmoxmcp MCP server

rustproxmoxmcp

One Rust MCP server for many Proxmox VE clusters a mechub project — sovereign network-security automation

Unofficial / community project. This is an independent community project and does not claim affiliation with or endorsement by Proxmox Server Solutions GmbH. Product names and trademarks are used only to identify the systems with which the software interoperates.

Status: 0.11.0 — the tool surface is complete but for one gap

50 callable tools: 31 read, 18 low, and applyproxmoxchangeset as the single destructive entry point. Seven further names --- deletevm, deletecontainer, deletesnapshot, deletebackup, deleteiso, restorebackup, rollbacksnapshot --- are authorization scopes, not tools: a token grants them by name and reaches them through planproxmoxdestroy. KNOWN_TOOLS therefore holds 57 entries.

What is still missing

mecmcp-policy compiling an allow/deny rule set over the command subject, and that is not wired. Arbitrary command execution inside every guest is remote code execution as a tool call; it ships with a policy engine or not at all.

• executevmcommand. Deliberate. The design spec makes it conditional on

The remaining gap is tracked in #57. Everything else the third-party proxmox-mcp offers has an equivalent here --- see docs/MIGRATING-FROM-PROXMOX-MCP.md, which also lists the arguments that changed shape.

Change control

Destructive work goes through plan → approve → apply. The plan renders a server-generated preview and records the action; the approval binds the plan digest over (owner, device, expected fingerprint, actions); the apply re-checks the guest's fingerprint and refuses one that moved.

Two things worth stating plainly, because both are easy to assume wrongly:

covers the stored preview's hash alongside the plan, so an approver commits to the exact text they were shown as well as to the operation and its parameters. The coordinator refuses any later write that swaps or drops that preview once an approval exists (#56).

• The approval binds the preview. Since mecmcp 0.23.0 the approval digest

This reverses what earlier revisions of this section said. Before 0.23.0 the preview was stored with its own hash but was not part of the digest, so an approver committed to the action and the preview was merely rendered from it.

supplies the override a protected guest needs, so on a lab-mode server a protected guest is approved on creation with no second principal, while an ordinary guest still requires one and self-approval is refused. That inversion surprises people.

• --lab-mode is the protection override, not a blanket waiver. It

--waivers-file (default /etc/proxmoxmcp/waivers.json, mode 0600, service-owned) carries time-boxed operator waivers. Both overrides originate outside the tool call: there is deliberately no grantwaiver tool and no force argument**, because an override a caller can pass is not an override.

waiver lets a plan against a protected guest proceed past the protection gate; the resulting change set still goes through the normal plan → approve → apply flow and still needs a distinct human approver (or --lab-mode, which is the one path that also waives approval). The waiver's reason and ticket are printed in the stored preview so the approver can see why protection was lifted before deciding whether to also approve.

• A waiver lifts protection only, never the second approver. A matching

waivers.json schema

Shortened. The full README is on GitHub.