Veeam AIops
Operate and triage a Veeam Backup & Replication environment through governed MCP tools.
Inspect backups, protected objects, storage usage, and per-object storage rankings for showback.
Run read-only diagnostics: job-failure RCA and repository-capacity RCA.
List and inspect jobs, repositories, restore points, sessions, managed servers, and proxies.
Start, stop, retry, enable, or disable backup jobs; all write tools support dry-run previews.
Stop running sessions and poll session progress/logs instead of re-issuing operations.
Start VM restores from restore points; this is marked high risk and irreversible.
Review and apply recorded undo tokens for reversible write operations.
Use safety/governance features: audit logging, descriptive risk tiers, undo recording, truncated-result indicators, and restore safety refusals.
Preview writes, but note the server records rather than authorizes operations; permissions are enforced by the connected Veeam account.
Provides tools for managing Veeam Backup & Replication operations, including listing, starting, stopping, enabling, and disabling jobs; managing restore points and initiating restores; listing repositories and backups; monitoring sessions; and running diagnostics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Veeam AIops list all backup jobs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Veeam AIops
Audit availability: Real writes require a committed
pendingaudit row and stop before contacting the platform if storage is unavailable. Reads and previews may continue with a warning; new audit rows store outcome summaries rather than full responses.
Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by Veeam Software. "Veeam" is a trademark of its owner. MIT licensed.
AI-powered Veeam Backup & Replication operations with a built-in governance
harness — unified audit log, policy engine, token/runaway budget guard,
undo-token recording, and descriptive risk tiers. Self-contained: no
external dependencies beyond httpx and the MCP SDK. Coverage is not yet full
coverage of every Veeam operation.
Verification status: the test suite is mock-based; selected CLI/REST reads were validated against Veeam B&R 13.1.1.18. MCP lifecycle, writes, restore safety, and later releases remain unverified on a live server. See docs/VERIFICATION.md.
What works
CLI (
veeam-aiops ...):init,overview,job list/get/start/stop/retry/enable/disable,restore list-points/start,repository list/get/state,session list/get/log/stop,backup list/objects/usage/ranking,diagnose job-failures/repo-capacity,infra servers/proxies,secret set/list/rm/migrate/rotate-password,doctor,mcp.MCP server (
veeam-aiops mcporveeam-aiops-mcp): 27 tools (19 read, 8 write), every one wrapped with the bundled@governed_toolharness.Diagnostics / RCA (read-only):
diagnose job-failurestriages recent job sessions — flags every Failed/Warning run and categorizes the likely cause (repository full, source/guest unreachable, credential/VSS failure, retry exhaustion), citing the session result + matched error substring;diagnose repo-capacityflags repositories under the free-space thresholds (<15% warn, <10% critical). Both cite the measured number that tripped each finding, worst-first.Encrypted credentials: passwords live in an encrypted store
~/.veeam-aiops/secrets.enc(Fernet + scrypt) — never plaintext on disk. Unlock with a master password fromVEEAM_AIOPS_MASTER_PASSWORD(MCP/CI) or an interactive prompt (CLI).Reversibility: write ops with a clean inverse (job start/stop/retry, enable/disable) record an inverse undo descriptor; the irreversible VM restore declares none and is tagged
highrisk.Async sessions: Veeam jobs and restores run as sessions — poll progress with
session list/session get/session log(the runaway budget guard prevents poll loops from running away).
Related MCP server: spanning-mcp
What this tool does, and does not, decide
It delivers Veeam Backup & Replication operations — reads and writes — accurately and efficiently, and records every one of them. It does not decide whether a write is allowed to happen. That is the agent's judgement, or the permission of the Veeam account you connect it with: give that account a read-only or restricted role on the VBR server and the writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.veeam-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse.
Each tool declares a
risk_level, kept in agreement with its[READ]/[WRITE]documentation tag by a test, and carried into the audit row as a descriptive tier — so a reviewer can see at a glance that a row was a high-risk restore. It is a label, not a gate.
Running a smaller / local model? See agent-guardrails.md — it lists the guardrails this tool now enforces for you (so you don't spend prompt budget restating them) and gives a ready-made system prompt for what's left.
Quick start
As a Claude Code plugin
One install gives an agent both the skill and the MCP server:
/plugin marketplace add AIops-tools/marketplace
/plugin install veeam-aiops@aiops-toolsThe MCP server is fetched with uv and pinned to the
package version this plugin declares, so an audit row can be traced back to the
code that wrote it. Credentials are still configured with veeam-aiops init — see below.
As an OpenClaw plugin
The same bundle is published on ClawHub, where one install delivers the skill and its MCP server together:
openclaw plugins install clawhub:@zw008/veeam-aiops
openclaw skills info veeam-aiops # expect: Visible to model: yesRestart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is
fetched with uv, pinned to this exact release, so
uvx has to be on PATH — without it the skill still installs but reports
Visible to model: no. Credentials are configured exactly as below.
As a CLI or standalone MCP server
uv tool install veeam-aiops
veeam-aiops init # interactive wizard: connection details + encrypted password
veeam-aiops doctor # verify config, encrypted store, connectivityinit writes ~/.veeam-aiops/config.yaml (non-secret connection details) and
stores the login password encrypted in ~/.veeam-aiops/secrets.enc. Example
config it produces:
targets:
- name: vbr-lab
host: 10.0.0.20
username: "DOMAIN\\backup-admin"
port: 9419
verify_ssl: false # self-signed lab certs only
timeout: 30 # seconds per request; raise for large estatesOn a large VBR installation the
/jobsand/sessionsendpoints can take far longer than the rest of the API — a live 13.1 environment did not answer a single-record/jobsquery inside 120 s while repositories answered in under 3 s.timeoutlets you give those endpoints longer. It does not make a slow endpoint fast: if a raised budget also expires, the endpoint is the bottleneck, not this client. The same holds for/backups/{id}/backupFiles, whichbackup rankingreads once per backup: a 123-backup 13.1 estate neededtimeout: 300for a complete ranking, and a backup that times out is flagged (timedOut) with this advice rather than silently left out. Scope the ranking (--backup,--repository) when you need part of the estate quickly.
For non-interactive use (MCP server, CI, cron) export the master password so the store can be unlocked without a prompt:
export VEEAM_AIOPS_MASTER_PASSWORD='your-master-password'Where that password then lives: an exported variable is readable by every process this shell starts and is recorded by shell history. On a shared or long-lived host, prefer the interactive prompt, or inject it from a secret manager for the life of the one command that needs it.
Managing secrets
veeam-aiops secret set vbr-lab # prompts hidden for the password
veeam-aiops secret list # names only, values never shown
veeam-aiops secret rm vbr-lab
veeam-aiops secret rotate-password # re-encrypt under a new master password
veeam-aiops secret migrate # import a legacy plaintext .env, then deletes itMigrating from an old ~/.veeam-aiops/.env (legacy VEEAM_<TARGET>_PASSWORD
vars)? Run veeam-aiops secret migrate; the old .env is renamed to
.env.migrated. The plaintext env var is still honoured as a fallback (with a
deprecation warning) for a smooth transition.
Audit & safety
All operations are logged to a local SQLite audit DB under ~/.veeam-aiops/
(relocatable via VEEAM_AIOPS_HOME) — the harness records, it does not
authorize. Every call, over MCP and the CLI alike, lands an audit row; the
token/runaway budget guard is a safety backstop (not an authorization gate) that
stops a stuck agent from burning unbounded calls, and each row carries a
descriptive risk tier that gates nothing. Destructive CLI commands (job stop,
restore start) require double confirmation and support --dry-run.
API-returned text is run through a prompt-injection sanitizer.
Contributing & feature requests
Coverage is intentionally focused. Missing a device, action, or feature you need? Open an issue or pull request at github.com/AIops-tools/Veeam-AIops — feature requests, contributions, and comments are all welcome.
License: MIT.
Available Tools
27 toolsbackup_listARead-only
[READ] List stored backups with id, name, type, creationTime.
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
backup_object_listARead-only
[READ] List the protected objects (VMs/agents) inside a stored backup.
Args: backup_id: Veeam backup id (see backup_list). target: Veeam target name from config.
Inputs: backup_id (required), target.
backup_object_storage_usageARead-only
[READ] Backup storage one VM/agent consumes, per backup (showback input).
Finds the protected object by exact name and sums Veeam's own per-file sizes (backupSize = on disk after compression/dedup, dataSize = before) across every backup holding it — primary job and backup copies reported separately with repository, restore-point count, full vs incremental bytes, GFS files, job retention and an increment-vs-full change rate. Needs VBR 12.3+.
Read before charging: files shared by several machines are reported in
sharedStoredBytes and never included in storedBytes; caveats says when
storedBytes is an upper bound (block-clone repositories) or when the server
cannot express shared files. found=false returns name candidates, not a guess.
No pricing — apply your own rates to the bytes.
Args: name: Protected object name as Veeam shows it (case-insensitive, exact). target: Veeam target name from config; omit to use the default.
Inputs: name (required), target.
backup_storage_rankingARead-only
[READ] Protected objects ranked by backup storage consumed, largest first.
Answers "which machines are the most expensive to protect". Each backup file
is charged to its single owner and one machine is merged across backups
(vCenter path / moref, agent BIOS UUID), each row carrying an explicit rank.
Shared and unattributable files are totals, never charged to anyone, split
into ownerlessStoredBytes (per-job chain files naming no owner — ordinary,
often large) and unmatchedOwnerStoredBytes (a file naming an owner its own
backup does not list and the server cannot resolve). An owner id missing
from its backup's listing is looked up once through /backupObjects/{id};
when found (a machine moved to another job) its bytes are charged and also
counted in recoveredOwnerStoredBytes, and unmatchedOwners says how each
id resolved (largest ids first; at most 50 entries, unmatchedOwnersTotal
and unmatchedOwnersTruncated say when there are more). Judge whether these
numbers can be billed on
unmatchedOwnerFiles being 0, never on the unresolved* sum.
A complete scan of a large estate is slow (a 123-backup VBR 13.1 estate took
21 minutes): scope it with backups or repository when the question is
about part of the estate. scoped true or backupsTruncated true means the
ranking covers only the selection or the scanned subset and must not be
reported as an estate-wide ranking. An entry in unreadableBackups with
timedOut true is fixed by raising the target's timeout in config.yaml,
not by retrying. Needs VBR 12.3+.
Args: limit: Rows to return, 1-500 (default 20). max_backups: Backups to scan within the scope, 1-1000 (default 100); raise for full coverage. backups: Only these backups, by id or name (a backup is named after its job; see backup_list). Omit for all. repository: Only backups stored in this repository, by id or name. concurrency: Backups read in parallel, 1-8 (default 1, sequential). Unmeasured on a real VBR: parallel reads load the same server and can push reads past the timeout; lower it if backups time out. target: Veeam target name from config; omit to use the default.
Inputs: limit, target, backups, repository, +2 more.
job_disableADestructive
[WRITE] Disable a backup job (skips scheduled runs). Inverse: job_enable.
Pass dry_run=True to preview.
Args: job_id: Veeam job id. dry_run: If True, preview without disabling. target: Veeam target name from config.
Inputs: job_id (required), target, dry_run.
job_enableADestructive
[WRITE] Enable a backup job (clears the disabled flag). Inverse: job_disable.
Pass dry_run=True to preview.
Args: job_id: Veeam job id. dry_run: If True, preview without enabling. target: Veeam target name from config.
Inputs: job_id (required), target, dry_run.
job_failure_rcaARead-only
[READ] Triage recent backup-job sessions: flag every Failed/Warning run.
Pulls the newest limit sessions, fetches the failing log records for each
bad run, and categorizes the likely cause (repository full, source/guest
unreachable, credential/VSS failure, retry exhaustion) worst-first, citing
the session result and the matched error substring for every finding.
sessionsTruncated=true means older sessions were not analysed. For "what
failed last night", pass since_hours=24 so the window is a time span rather
than whatever fits in the newest limit sessions of every type.
Args: limit: Newest sessions to analyse, 1-1000 (default 100). since_hours: Only sessions created in the last N hours (optional). target: Veeam target name from config; omit to use the default.
Inputs: limit, target, since_hours.
job_getBRead-only
[READ] Return detail for a single backup job by id.
Args: job_id: Veeam job id (see job_list). target: Veeam target name from config.
Inputs: job_id (required), target.
job_listARead-only
[READ] List backup jobs with id, name, type, status, lastResult.
Use job_get for full detail of a single job.
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
job_retryADestructive
[WRITE] Retry a failed backup job (re-runs failed objects only).
Runs as an async session — poll with session_list / session_get. Inverse: job_stop (cancels the in-flight retry). Pass dry_run=True to preview.
Args: job_id: Veeam job id. dry_run: If True, preview without retrying. target: Veeam target name from config.
Inputs: job_id (required), target, dry_run.
job_startADestructive
[WRITE] Start a backup job. Runs as an async session. Inverse: job_stop.
Poll progress with session_list / session_get; do not re-issue. Pass dry_run=True to preview.
Args: job_id: Veeam job id. dry_run: If True, preview without starting. target: Veeam target name from config.
Inputs: job_id (required), target, dry_run.
job_stopADestructive
[WRITE] Stop a running backup job. Inverse: job_start.
Pass dry_run=True to preview.
Args: job_id: Veeam job id. dry_run: If True, preview without stopping. target: Veeam target name from config.
Inputs: job_id (required), target, dry_run.
managed_server_listBRead-only
[READ] List managed servers (id, name, type, description).
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
overviewARead-only
[READ] One-shot health summary: jobs by last result, repos near full, running sessions.
Call this first to triage a Veeam environment before drilling into a specific job, repository, or session.
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
proxy_listARead-only
[READ] List backup proxies (id, name, type, server).
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
repository_capacity_rcaARead-only
[READ] Flag backup repositories running low on free space.
Pulls per-repository capacity state and reports worst-first findings for any repository under the free-space thresholds (<15% warn, <10% critical), each citing the measured free% and free bytes plus an extend/offload/retention action.
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
repository_getARead-only
[READ] Detail for one repository incl. capacity/free/used when known.
Args: repository_id: Veeam repository id (see repository_list). target: Veeam target name from config.
Inputs: repository_id (required), target.
repository_listARead-only
[READ] List backup repositories with id, name, type, path.
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
repository_stateARead-only
[READ] Capacity summary for every repository (capacity/free/used/used%).
Args: target: Veeam target name from config; omit to use the default.
Inputs: target.
restore_list_pointsARead-only
[READ] The newest restore points (id, name, creationTime, type), newest first.
Returns {"restorePoints": [...], "returned", "limit", "truncated", "order"}. truncated=true means older points exist beyond this window — raise limit or filter by backup_id; do not read a short list as "that is all there is". With backup_id, a server that ignores the filter is refused, not trusted.
Args: backup_id: Optional Veeam backup id (see backup_list) to filter by. limit: Points to return, 1-1000 (default 100). target: Veeam target name from config; omit to use the default.
Inputs: limit, target, backup_id.
session_getARead-only
[READ] Poll one session by id to check job/restore progress.
Use after job_start or start_vm_restore to follow the operation instead of re-issuing it.
Args: session_id: Veeam session id (see session_list). target: Veeam target name from config.
Inputs: session_id (required), target.
session_listARead-only
[READ] The newest sessions with id, name, type, state, result, newest first.
Returns {"sessions": [...], "returned", "limit", "truncated", "order"}. truncated=true means older sessions exist beyond this window.
Args: limit: Sessions to return, 1-1000 (default 100). target: Veeam target name from config; omit to use the default.
Inputs: limit, target.
session_logARead-only
[READ] Return the log records (events) of one session.
Use to see why a session failed instead of re-running the job blind.
Returns {records, returned, totalRecords, truncated}: truncated is
true when the server holds more records than it returned (the endpoint
cannot be paged), null when it did not report a total. Do not conclude
"no error in the log" from a truncated or null-truncated result.
Args: session_id: Veeam session id (see session_list). target: Veeam target name from config.
Inputs: session_id (required), target.
session_stopADestructive
[WRITE] Stop a running session (cancels the underlying operation).
No undo token — a stopped session must be re-issued via the originating job/restore. Pass dry_run=True to preview.
Args: session_id: Veeam session id (see session_list). dry_run: If True, preview without stopping. target: Veeam target name from config.
Inputs: session_id (required), target, dry_run.
start_vm_restoreADestructive
[WRITE] Start a VM restore from a restore point. IRREVERSIBLE — no undo token.
Overwrites or creates a VM; confirm with the user before calling. Runs as an async session — poll with session_list / session_get. Pass dry_run=True to preview: the preview resolves the opaque restore-point id to the VM name and creation time it would restore, so there is something real to confirm.
Refuses when that VM name matches the configured VBR host — with no target mapping this is a restore-to-original, so it would overwrite the Veeam server serving this API. The name check is a safety net, not a proof (a VM display name is not a hostname); read the preview before approving.
Refuses separately when the restore point cannot be READ at all, because then it cannot name the machine it would overwrite — a preview reporting vmName: null is not something to approve. Set acknowledge_unresolved=True only when the user has confirmed the target in the Veeam console.
Args: restore_point_id: Restore point id (see restore_list_points). dry_run: If True, preview without restoring. acknowledge_unresolved: Proceed even though the restore point could not be read and the target machine is therefore unknown. target: Veeam target name from config.
Inputs: restore_point_id (required), target, dry_run, acknowledge_unresolved.
undo_applyADestructive
[WRITE][risk=medium] Apply a recorded undo by dispatching its inverse tool.
The inverse runs through its own governed tool, so it is audited under its own risk tier. Pass dry_run=True to preview the inverse call without executing it. A token can only be applied once.
Args:
undo_id: The undoId from undo_list (or an _undo_id in a write result).
dry_run: If True, preview the inverse tool + params without running it.
target: Passed through to the inverse tool when it accepts a target.
Inputs: undo_id (required), target, dry_run.
undo_listARead-only
[READ] List recorded, not-yet-applied undo tokens (most recent first).
Each entry names the original tool, the inverse tool that undo_apply
would run, and a human note. Use the undoId with undo_apply.
Returns an envelope rather than a bare list::
{"undos": [...], "returned": 50, "limit": 50, "truncated": true}so a truncated read announces itself. A bare list cannot say "there is
more" — the consumer has to infer it from the length happening to equal the
limit, and a smaller local model faced with a capped result tends to report
that it has seen every token. One extra row is requested so truncated
is measured rather than guessed from a length coincidence.
Each entry carries effectVerified. False means the original write
lost its response, so the change it reverses is PROBABLE, not confirmed —
check the live state before applying, and do not report the result as a
restore of a state that may never have been reached.
Args: limit: Max rows to return (default 50, capped at 500). target: Unused (undo state is host-local); accepted for CLI uniformity.
Inputs: limit, target.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 27 tools
Most tools target distinct resources and actions, and descriptions clarify boundaries (e.g., session_stop vs job_stop, session_list vs job_list). Some overlap between repository_list, repository_get, repository_state, and repository_capacity_rca creates minor confusion, but each has a clear purpose.
Most names follow a clear resource_action pattern (e.g., job_list, session_get, backup_object_list), but there are deviations like overview, start_vm_restore (verb first), and backup_storage_ranking (noun phrase). These are readable and mostly consistent overall.
27 tools is slightly high but reasonable for a comprehensive Veeam management interface covering jobs, sessions, repositories, backups, and restores. Each tool appears to earn its place, though some could be consolidated.
The tool set covers the full lifecycle: listing, starting, stopping, enabling/disabling, retrying jobs, session monitoring, repository capacity, restore points, and restore operations. Undo tokens and storage usage tools add depth, leaving no obvious gaps for the domain.
Maintenance
Related MCP Connectors
AI-powered incident management and server monitoring via MCP.
Hosted MCP servers for MSP tools: ConnectWise, NinjaOne, Microsoft 365, SentinelOne, Pax8 and more.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server for Kaseya VSA — endpoints, patches, procedures, alarms, and tickets. Enables AI assistants to manage and monitor devices via the Kaseya VSA RMM platform.Apache 2.0
- AlicenseNot gradedqualityBmaintenanceMCP server for Spanning Cloud Backup — M365/GWS/Salesforce SaaS backup, restore, and audit. Enables AI assistants to manage and monitor cloud backup protection via the Spanning API.Apache 2.0

Keepit MCPofficial
AlicenseNot gradedqualityBmaintenanceMCP server for interacting with Keepit backup and data protection services. Enables monitoring, management, and security operations through natural language.5MIT- AlicenseNot gradedqualityCmaintenanceExtends Veeam Intelligence to MCP-compatible clients, enabling secure, real-time operational insight across Veeam Backup & Replication, Veeam ONE, and VSPC via natural language or AI workflows.21MIT