Unofficial-Proxmox-MCP

pve_create_lxc

Provision a new Proxmox VE LXC container from an OS template tarball with configurable CPU, memory, disk, storage, network, and optional SSH key.

Instructions

Create a new LXC container from an OS template tarball.

Args: vmid: Unique Container ID (e.g. 255). hostname: Hostname for the container. ostemplate: Storage template path (e.g. 'local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst'). cores: Number of assigned CPU cores. memory_mb: Memory in megabytes. disk_gb: Root filesystem disk size in gigabytes. storage: Target storage pool (e.g. 'local-lvm' or 'fast-tier'). password: Root user password. ssh_public_key: Optional SSH public key to inject into /root/.ssh/authorized_keys. net0: Network interface configuration string. unprivileged: If True, provisions container in an unprivileged user namespace (recommended). node: Target node name.

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": {
      "vmid": "<vmid>",
      "hostname": "<hostname>",
      "ostemplate": "<ostemplate>"
    },
    "name": "pve_create_lxc"
  }
}

Input Schema

Name	Required	Default
`net0`	No	name=eth0,bridge=vmbr0,firewall=1,ip=dhcp
`node`	No
`vmid`	Yes
`cores`	No
`disk_gb`	No
`storage`	No	local-lvm
`hostname`	Yes
`password`	No
`memory_mb`	No
`ostemplate`	Yes
`unprivileged`	No
`ssh_public_key`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 9, 2026

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are supplied, so the description must carry the full behavioral disclosure. It does not say whether the container is started after creation, whether the call blocks until provisioning finishes, what permissions or API tokens are required, what happens on name or ID collision, or how long a typical create takes. The two useful behavioral details are the unprivileged-namespace recommendation and the fact that the SSH key lands in /root/.ssh/authorized_keys, but that is thin for a destructive create operation with zero annotation coverage.

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 purpose is front-loaded in a single sentence, followed by a compact parameter list, with no filler or marketing language. Listing all 12 parameters is justified given that the schema has no per-property descriptions. The code-block style argument list is readable but slightly repetitive of parameter names that already appear in the schema.

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?

An output schema exists, so the description does not need to explain return values. For a 12-parameter create operation with no annotations, it explains the purpose and every parameter, and it omits only post-creation state and failure behaviors. Those are real gaps, but they are narrower than the kind of omission that would make the tool uncallable.

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?

Schema coverage is 0% for all 12 parameters, so the Args block is doing all the documenting, and it does cover every parameter with at least a one-line gloss plus concrete examples for vmid, ostemplate, and storage. It falls short on the less obvious ones: net0 is not explained beyond the schema default, node has an empty default with no statement of what happens when it is omitted, and password is shown with an empty default without saying whether a root password is required for login to work. That is meaningful compensation but not complete.

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 opens with a specific verb and resource: 'Create a new LXC container from an OS template tarball.' This is enough to distinguish it from pve_create_vm by the LXC/VM distinction, and from pve_clone_system by 'from an OS template tarball'. However, it never names a sibling as an alternative, so the differentiation is implicit rather than stated.

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 does not say when to use this tool rather than pve_create_vm, pve_clone_system, or pve_lifecycle. The only guidance is a parenthetical note that unprivileged mode is 'recommended', and that covers one parameter rather than the choice of tool. An agent must infer prerequisites: the template must already exist in a storage pool, and the vmid must be free.

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