Skip to main content
Glama
Sign In
pvewarden

pvewarden

by matousfiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

apply_updates

Installs official security or all updates on a Proxmox VM or container after taking a snapshot, while skipping unsupported packages and reporting failures.

Instructions

Install updates on a guest (requires tag 'pvewarden-update'). Can take 10-20 minutes. Only the distribution's official archives are used: mode='security' installs security updates, mode='all' also regular updates. Third-party repositories and held packages are never installed; updates that would need them are skipped. No release upgrades. May auto-remove unused old kernels. If nothing is pending for the mode, returns nothing_to_install=true without a snapshot. 'planned' lists the packages it set out to install. Takes a snapshot first and aborts if that fails: then tell the user, do not retry with snapshot=false on your own. snapshot=false asks the user to confirm in the client. Refused while Proxmox locks the guest (e.g. during a backup). Does not reboot. If the result has still_running=true, the update goes on in the guest: call update_result. Report 'newly_failed_services' if not empty. Full output is in the file in 'log', a path on the pvewarden server (its container), not on the Proxmox host or the guest.

Input Schema

NameRequiredDescriptionDefault
modeNo'security': security updates only; 'all': also regular updates.security
vmidYesProxmox VMID of the guest, e.g. 101 (see list_guests).
snapshotNoTake a snapshot first. Keep true; false needs the user's consent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / mode / description
      Added value: +"'security': security updates only; 'all': also regular updates."
    • addedInput schema / properties / snapshot / description
      Added value: +"Take a snapshot first. Keep true; false needs the user's consent."
    • addedInput schema / properties / vmid / description
      Added value: +"Proxmox VMID of the guest, e.g. 101 (see list_guests)."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: discloses the required tag, the 10-20 minute runtime, snapshot-then-abort semantics, the user-consent requirement for snapshot=false, lock-based refusal, no reboot, and possible auto-removal of unused old kernels. Note one mild tension: destructiveHint=false while the tool 'may auto-remove unused old kernels', but the description discloses this openly rather than contradicting it, so the agent is not misled.

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?

Critical facts (tag requirement, mode semantics) are front-loaded, but the single dense block runs long and mixes invocation guidance with result-handling guidance about several different result fields. Nearly every sentence carries operational information, so the length is defensible; chunking would improve scanability.

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

Completeness5/5

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

With no output schema, the description fully carries the return contract: nothing_to_install=true, 'planned', still_running=true plus the update_result follow-up, newly_failed_services, and the 'log' path being on the pvewarden container rather than the host or guest. Nothing an agent needs to call or interpret the tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description earns an increment by explaining consequences the schema does not: what 'all' additionally installs versus what is always skipped, that snapshot=false prompts the user in the client, and that a failed snapshot aborts the run rather than proceeding.

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?

Opens with a specific verb+resource ('Install updates on a guest') and immediately scopes it with a precondition (tag 'pvewarden-update'). It is trivially distinguishable from sibling check_updates (read-only check) and update_result (poll an in-flight run), which the description names explicitly.

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

Usage Guidelines5/5

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

Gives explicit when/when-not guidance: use mode='security' vs 'all', do not retry with snapshot=false after a snapshot failure, ask the user instead, and call update_result when still_running=true. It also names exclusions (no release upgrades, third-party repos and held packages skipped) and the blocked state ('Refused while Proxmox locks the guest').

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