Skip to main content
Glama

pbs_pull

Pull backup snapshots from a remote PBS datastore into a local datastore. Use dry-run to preview changes and confirm to execute. Includes filtering, rate limiting, and options for verified or encrypted snapshots.

Instructions

MUTATION: pull backups from a remote PBS datastore into the LOCAL datastore store.

RISK_MEDIUM by default, escalating to RISK_HIGH when remove_vanished=True (see proximo.pbs_admin module docstring's RISK RATING section — matches the campaign's own "remove-vanished DELETES local snapshots" framing). WRITES real backup data into store; an over-broad or absent group_filter transfers every group in scope. Dry-run by default (returns a PLAN disclosing every param that changes where data lands or what gets deleted); confirm=True executes (POST /pull). The live schema declares this returns null — no UPID to poll; Smoke-confirm whether this call blocks synchronously for the full transfer duration before relying on it for a large sync. No rollback primitive. Needs PROXIMO_PBS_* config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nsNoNamespace on the LOCAL datastore to pull into. Defaults to root.
storeYesLOCAL PBS datastore name to pull backups INTO. REQUIRED.
remoteNoRemote ID identifying the source PBS. OPTIONAL per the live schema (Smoke-confirm what PBS does when omitted).
confirmNoFalse (default) returns a dry-run PLAN only; True executes the pull.
rate_inNoInbound rate limit as a byte size with unit.
burst_inNoInbound burst limit as a byte size with unit, e.g. '10MB'.
rate_outNoOutbound rate limit as a byte size with unit.
burst_outNoOutbound burst limit as a byte size with unit.
max_depthNoNamespace recursion depth, 0-7 (0 = no recursion; empty/omitted = automatic full recursion).
remote_nsNoNamespace on the REMOTE datastore to pull from. Defaults to root.
group_filterNoGroup filters, e.g. '[exclude:]type:vm' or 'group:GROUP' or 'regex:RE'. Omit to pull EVERY group in scope.
remote_storeYesDatastore name on the remote PBS to pull FROM. REQUIRED.
transfer_lastNoLimit transfer to the last N snapshots per group, skipping older ones (>=1).
verified_onlyNoOnly synchronize verified backup snapshots, exclude others.
encrypted_onlyNoOnly synchronize encrypted backup snapshots, exclude others.
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.
resync_corruptNoRe-pull local snapshots that previously failed verification, overwriting them.
worker_threadsNoNumber of worker threads to process groups in parallel, 1-32.
decryption_keysNoIDs of already-registered client encryption keys (pbs_encryption_key_*) to use for decrypting remote content. NOT the raw key material.
remove_vanishedNoDELETE local snapshots that no longer exist on the remote. Escalates this call's risk to HIGH — no dry-run preview exists.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description carries full burden. It discloses that the tool is a MUTATION, writes real data, has risk levels (RISK_MEDIUM escalating to RISK_HIGH with remove_vanished), dry-run behavior, blocking uncertainty, lack of rollback, and configuration requirements. This is far beyond typical transparency.

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 well-structured, front-loading the core purpose and risk. Every sentence adds value, covering purpose, risk, behavior, and caveats without being overly verbose. The format is concise and informative.

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?

Given the tool's complexity (20 parameters, 2 required) and the presence of an output schema, the description covers key contextual aspects: flow (dry-run then confirm), risk, blocking behavior, config needs, and group_filter warning. It is nearly complete, though it could elaborate on the interaction between remote and remote_store parameters.

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 100% with detailed parameter descriptions, so baseline is 3. The description adds some context (e.g., over-broad group_filter risk) but much of this is already in the schema. No new semantic insight beyond what the schema provides is given.

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 purpose: 'pull backups from a remote PBS datastore into the LOCAL datastore `store`.' It specifies the verb (pull), resource (backups), direction (remote to local), and destination. This distinguishes it from siblings like pbs_push (which pushes to remote) and other datastore operations.

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

Usage Guidelines3/5

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

The description provides usage context such as dry-run default and risk escalation with remove_vanished, but does not explicitly contrast with alternatives like pbs_push or other sync mechanisms. No 'when to use this vs. when not' guidance is given, missing a clear differentiation from sibling tools.

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