Skip to main content
Glama
Sign In
Proxmox VE MCP server

Proxmox VE MCP server

by askmojood
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Start, shut down or reboot a guest

power_guest
Destructive

Starts, cleanly shuts down, or reboots a Proxmox VE VM or container, requiring a one-time confirmation code before any change is applied.

Instructions

Start, cleanly shut down, or reboot a VM or container. The first call changes nothing and returns a summary and a confirmation code; it happens only on a second call with the code, after the user has said yes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guest": "<guest>",
      "action": "<action>"
    },
    "name": "power_guest"
  }
}

Input Schema

NameRequiredDescriptionDefault
guestYesa name or id, e.g. "mail-relay"
actionYesshutdown and reboot go through the guest OS
confirmationNoleave empty first; pass the code only after the user confirms

Output Schema

NameRequiredDescriptionDefault
doneYesfalse: nothing has changed yet; true: Proxmox has done it
guestNo
problemNowhy it can't be done; nothing was changed
summaryYes
confirmationNowhen done is false: the code to pass back, only after the user says yes
expires_in_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and non-idempotent, so safety is partly covered; the description adds the crucial behavior not present in annotations — that the first invocation is a no-op returning a summary plus confirmation code. It does not say what state running guests end in or whether pending operations block the action, so a 4 rather than 5.

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

Conciseness4/5

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

Two tight sentences with no filler; the verb list leads and the confirmation rule follows. The line break mid-sentence is a formatting artifact rather than redundancy, though a single flowing sentence would read more cleanly.

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

Completeness4/5

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

With an output schema present, return values need no explanation, and the description still helpfully notes the first call returns a summary and code. For a destructive three-action tool it is nearly complete, missing only the post-action guest state or any note on errors such as an already-running or unreachable guest.

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

Parameters3/5

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

Schema coverage is 100% and the confirmation parameter already documents 'leave empty first; pass the code only after the user confirms', so the description mostly restates that contract rather than extending it. Baseline 3 applies when the schema carries parameter meaning.

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

Purpose5/5

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

States a specific set of verbs (start, shut down, reboot) against a specific resource (VM or container), matching the action enum exactly. No sibling tool (needs_attention, overview, find_guests, guest_details, snapshot_guest) touches power state, so the tool is unambiguous in the toolset.

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

Usage Guidelines4/5

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

The description gives clear operational guidance for the two-step confirmation flow: first call changes nothing, act only on the second call with the code after user approval. It does not explicitly name alternatives or say when not to use it, but the sibling set makes the domain obvious.

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

Deploy Server

Other Tools