proxmox_node_disk_adminInitialize GPT partition tables or wipe block devices on a Proxmox node. Select init_gpt for setup or wipe to erase disk data.
Destructive disk operations. action=init_gpt: initialize GPT | action=wipe: wipe disk (all elevated)
| Name | Required | Description | Default |
|---|---|---|---|
| disk | Yes | Block device path (e.g., /dev/sdb) | |
| node | Yes | Node name | |
| uuid | No | Optional UUID for the disk | |
| action | Yes |
Changes observed during successful MCP inspections.
v1.3.0Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"v1.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true and readOnlyHint=false. The description adds meaningful context by labeling the operations destructive and noting that all actions require elevated privileges, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, front-loads the destructive nature, and uses a clear pipe-separated format for the two actions. Every phrase contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive admin tool with rich annotations and a clear schema, the description covers the essential behavioral and authorization context. It could add explicit warnings about data loss or examples, but the current definition is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes node and disk, but the description adds critical meaning to the action enum by mapping init_gpt and wipe to their human-readable operations. This helps the agent understand what each action actually does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (disk) and specific operations (init_gpt, wipe), and explicitly labels them destructive, distinguishing this tool from non-destructive siblings like proxmox_node_disk. The action list makes the scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the action list: use for initializing GPT or wiping disks. However, it does not explicitly state when not to use it or point to non-destructive alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.