Skip to main content
Glama
Sign In
Proxmox VE MCP server

Proxmox VE MCP server

by askmojood
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Take a snapshot

snapshot_guest

Takes a snapshot of a running Proxmox VE VM or container; the first call returns a confirmation code, and the snapshot is created only after user approval.

Instructions

Take a snapshot of a VM or container (it keeps running). The first call changes nothing and returns a summary and a confirmation code; the snapshot is taken 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>",
      "name": "<name>"
    },
    "name": "snapshot_guest"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesletters, digits, "-" or "_", starting with a letter, e.g. "before-update"
guestYesa name or id, e.g. "erp-db"
descriptionNowhy, in a few words
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.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=false and readOnlyHint=false; the description usefully adds the non-obvious confirmation handshake, which the agent could not infer from the annotations alone. It stops short of disclosing side effects an operator would care about, such as storage consumption, name-collision behavior, or whether the guest is briefly quiesced.

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

Conciseness5/5

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

Two sentences, no filler, with the core action front-loaded and the confirmation protocol immediately after. Every clause carries information the agent needs to act correctly.

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 a full-coverage schema, an output schema, and annotations covering the safety profile, the description supplies the one thing structured fields cannot: the interactive confirmation sequencing. It is nearly complete, missing only failure-mode guidance such as duplicate snapshot names or what the returned code expires against.

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 description coverage is 100%, so name, guest, description, and confirmation are all documented in the schema itself, including the instruction to leave confirmation empty on the first call. The description's explanation of the code largely restates the confirmation parameter's own description rather than adding format or constraint detail beyond it, so the baseline 3 applies.

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 concrete verb and resource ("Take a snapshot of a VM or container") plus a clarifying parenthetical that the guest keeps running, which preempts the most likely agent misconception. No sibling (find_guests, guest_details, power_guest, overview, needs_attention) does anything similar, so the tool is unambiguous within its family.

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?

Gives explicit procedural guidance for the two-step protocol: the first call is a no-op returning a summary and code, and the snapshot happens only on a second call after the user says yes. It does not state when to prefer a snapshot over other guest operations, but no alternative exists among the siblings, so the gap is minor.

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