Skip to main content
Glama
AIops-tools

Veeam AIops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

backup_storage_ranking

Read-only

Rank protected objects by backup storage consumed to pinpoint high-cost machines. Scope by backup or repository for estate-wide or partial analysis.

Instructions

[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.

Input Schema

NameRequiredDescriptionDefault
limitNo
targetNo
backupsNo
repositoryNo
concurrencyNo
max_backupsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.16.1
    • addedInput schema / properties / backups
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Backups"
+}
    • addedInput schema / properties / concurrency
      Added value: +{
+  "default": 1,
+  "title": "Concurrency",
+  "type": "integer"
+}
    • addedInput schema / properties / repository
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Repository"
+}
  2. Addedv0.13.1

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint available, the description carries rich behavioral detail well beyond annotations: a concrete cost profile ('a 123-backup VBR 13.1 estate took 21 minutes'), parallel-read risk that can push past the timeout, the config.yaml timeout remedy instead of retrying, the meaning of `scoped`/`backupsTruncated` as non-estate-wide results, and the VBR 12.3+ requirement.

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?

Purpose and the 'largest first' ranking are front-loaded, and most sentences pay for themselves with operational detail. The middle block on ownerlessStoredBytes/unmatchedOwnerStoredBytes/unmatchedOwners is dense and heavily nested, but since there is no output schema it is load-bearing rather than filler.

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 slow, estate-wide aggregation tool with 0% schema coverage and no output schema, the description supplies the missing pieces: output field semantics, attribution rules, truncation flags, performance expectations and scoping caveats. An agent has everything needed to call it and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must and does document all six parameters with meaning beyond the bare types: ranges and defaults for limit/max_backups/concurrency, 'raise for full coverage,' 'by id or name' for backups/repository, and target's config-derived lookup with default fallback.

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?

Opens with a specific verb+resource+ordering: 'Protected objects ranked by backup storage consumed, largest first,' plus a plain-language framing ('which machines are the most expensive to protect'). An agent can immediately tell this is a ranking/aggregation tool rather than a per-object usage lookup, even though it does not explicitly name the nearby backup_object_storage_usage sibling.

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?

Gives explicit selection context: 'scope it with `backups` or `repository` when the question is about part of the estate.' It also states the decision rule for billing ('Judge whether these numbers can be billed on `unmatchedOwnerFiles` being 0'). However, it never names an alternative tool for cases where a scoped or cheaper answer would be preferable, so it falls short of a full when/when-not/alternatives statement.

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

Deploy Server

Other Tools