HomeLab MCP

by chip10

Overview Schema Source Related Servers Discussions Admin

Python

Local

pve_guest_status

Check the current status of a QEMU VM or LXC container on a Proxmox node by specifying node, guest type, and VM ID.

Instructions

Obtiene el estado de una VM QEMU o un LXC.

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": {
      "node": "<node>",
      "guest_type": "<guest_type>",
      "vmid": "<vmid>"
    },
    "name": "pve_guest_status"
  }
}

Input Schema

Name	Required	Description	Default
`node`	Yes
`vmid`	Yes
`guest_type`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 1, 2026

TDQS

C2.9/5.0

Behavior3/5

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

The core behavior is clear: the tool retrieves the status of a guest and implies a read-only operation with no side effects. However, with no annotations and no output schema, the description does not disclose what status fields are returned, whether the guest must be running, or how errors are surfaced.

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?

The description is a single short sentence that front-loads the action and object with no filler. It is compact and scannable, though it sacrifices useful detail for brevity.

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

Completeness2/5

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

The tool has no output schema and no annotations, so the description should explain return values and parameter constraints; it does neither. The missing guest_type enumeration and unclear node/vmid semantics make the definition incomplete for reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only hints at guest_type via 'QEMU o LXC'. Node and vmid are left to their property names, and the accepted values for guest_type are not enumerated.

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

Purpose4/5

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

The description states a specific verb ('Obtiene') and resource ('estado de una VM QEMU o un LXC'), clearly signaling a read-only status check. It distinguishes itself from lifecycle siblings like pve_start_guest and pve_shutdown_guest, though it does not explicitly differentiate from pve_guests, which may also report guest state.

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

Usage Guidelines2/5

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

The description provides no usage context or guidance on when to choose this tool over alternatives such as pve_guests. It does not mention prerequisites, exclusions, or typical scenarios like checking status before starting or shutting down a guest.

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