proxmox-mcp

proxmox_delete_container

Permanently delete a stopped container in a Proxmox cluster. Returns a task UPID to track deletion progress.

Instructions

Permanently delete a container (the container must be stopped first). Returns the task UPID — use proxmox_task_status to check whether it finished.

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>",
      "vmid": "<vmid>"
    },
    "name": "proxmox_delete_container"
  }
}

Input Schema

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

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the irreversible nature ('Permanently delete'), a precondition (container must be stopped), and the return type (task UPID). It lacks details on authentication, error handling, or consequences of non-compliance, but covers key behavioral aspects.

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?

The description is extremely concise: two sentences with no filler. The first sentence front-loads the core action and precondition. Every word is necessary and contributes to understanding.

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?

For a simple deletion tool with an output schema (implied), the description covers the essential: action, precondition, and follow-up. It could mention error scenarios (e.g., container not stopped) or permissions, but given the tool's simplicity and sibling context, it is mostly complete.

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?

The description does not elaborate on the parameters 'node' and 'vmid' beyond the schema titles. With 0% schema description coverage, the description should compensate, but it only mentions 'container' implicitly tying to vmid. This provides minimal added meaning, leaving the agent to infer parameter roles from the tool name.

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?

The description clearly states the tool's action: 'Permanently delete a container'. It specifies the resource (container) and verb (delete), distinguishing it from sibling tools like proxmox_delete_vm (for VMs) and proxmox_container_action (for other container actions).

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 provides a clear precondition: 'the container must be stopped first'. It also advises using proxmox_task_status to check the result, guiding the agent on follow-up. However, it does not explicitly state when not to use this tool or compare it to alternatives, though the context of deletion is implicit.

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

Deploy Server