Skip to main content
Glama

pbs_node_disk_zfs_create

Create a ZFS pool from disks and mount as a datastore on a Proxmox Backup Server node. Dry-run by default; confirm to execute, formatting disks irreversibly.

Instructions

MUTATION: create a zpool from disks and mount it as a zfs datastore on a PBS node.

RISK_HIGH: FORMATS the named device(s) immediately — any pre-existing data is destroyed, irreversibly. Unlike the directory backend, PBS's API has NO delete endpoint for a zfs backend at all (module docstring gap #3) — once created, this zpool cannot be destroyed through this API. Dry-run by default (returns a PLAN, which names this no-delete gap explicitly); confirm=True executes (POST /nodes/{node}/disks/zfs, Smoke-confirm) and returns {"status": "submitted", "result": <task UPID | None>}. Needs PROXIMO_PBS_* config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDatastore name to create (3-32 chars, alnum/underscore start).
nodeNoPBS node name (or 'localhost').localhost
ashiftNoPool sector size exponent, 9-16 (PBS default 12 if omitted).
confirmNoFalse (default) returns a dry-run PLAN only; True executes the creation.
devicesYesComma-separated bare disk names to consume (e.g. 'sda,sdb') — NOT /dev/ paths.
raidlevelYesZFS RAID level: single, mirror, raid10, raidz, raidz2, or raidz3. (No dRAID — PBS's schema doesn't offer it, unlike PVE.)
compressionNoZFS compression algorithm: gzip, lz4, lzjb, zle, zstd, on, or off.
add_datastoreNoIf True, also register a PBS datastore using this zpool.
proximo_targetNoWhich configured Proxmox target to run this call against — a target name from your multi-target config (a specific PVE/PBS/PMG/PDM box). Omit to use the single/default target from the environment; the selection applies only to this call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully discloses the behavioral traits: it is a mutation that formats devices immediately, destroys data irreversibly, has no delete endpoint, and explains the dry-run vs confirm execution flow. It also mentions the return format and configuration requirements.

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 paragraph, front-loaded with the MUTATION label and RISK_HIGH warning. It is concise and efficiently communicates key behavioral information without unnecessary verbosity.

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?

For a complex tool with 9 parameters and no annotations, the description covers all critical aspects: purpose, risk, irreversibility, dry-run vs confirm, return format, and configuration requirements. It is comprehensive and leaves no major gaps.

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?

The input schema has 100% description coverage, so the schema already documents each parameter. The description adds value by explaining the dry-run default (confirm parameter) and the overall return format, but does not provide additional semantic details beyond the schema for individual parameters.

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 creates a zpool from disks and mounts it as a ZFS datastore on a PBS node. The verb 'create' and resource 'zpool' are specific, and the context of disk formatting distinguishes it from siblings like pbs_node_disk_directory_create.

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 clear usage context: it creates a zpool from disks, with a dry-run default and confirm flag. It mentions the no-delete limitation and contrasts with the directory backend. However, it does not explicitly state when not to use this tool or list alternatives beyond the directory backend comparison.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/john-broadway/proximo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server