Skip to main content
Glama
vmware-skills

VMware-Monitor

vm_backup_snapshot_history

Read-onlyIdempotent

Measure how long image-level backups held a VMware snapshot open on one VM using vCenter task history, so you can recover the backup window without backup server credentials.

Instructions

[READ] How long backups held a snapshot open on one VM, from task history.

Image-level backup products (Veeam, Commvault, Rubrik, NetBackup) snapshot the VM, copy the frozen disks, then delete the snapshot. vCenter records both ends, so the backup window is recoverable without credentials for the backup server.

This is a LOWER BOUND on the job, not its duration: work the product does before the snapshot is taken and after it is removed is invisible to vCenter. The returned basis says so — quote it alongside any figure.

Returns a rollup, not the list envelope: counts, four hour statistics (backup_active / snapshot_present / total_window / snapshot_removal), latest_cycle, longest_cycle, and unmatched rows for creations with no removal (a backup that left its snapshot behind) or removals whose creation predates the window.

Read two fields before reporting all-clear. history_unavailable non-null means the history could not be read at all — that is not "no backups". coverage_note non-null means vCenter has already expired part of the requested window (task.maxAge — 30 days by default; the option is NOT called vpxd.task.maxAge, which raises vim.fault.InvalidName), so the counts describe a shorter period than days asked for. window_fully_covered is the positive form: True when retention is at least days and nothing in the window can have expired, so a VM whose oldest task is recent was simply quiet; None when retention or the history could not be read.

An unmatched creation is not a failed backup. Each one carries status: "open", age_hours, this VM's longest_completed_cycle_hours and possibly_in_progress — True while it is inside that VM's own observed envelope, False past it, None when there is no completed cycle to compare against. Do not report incomplete_cycles as failures without reading those.

The creation task itself, during the seconds it executes, is absent entirely: no completion time yet, so it forms neither a cycle nor an unmatched row. A backup whose snapshot already exists is not this case — that is the open cycle described above. So no open cycle does not prove no backup is running.

Duplicate VM names raise rather than resolve to one, because a duration attributed to the wrong same-named VM looks exactly like a correct answer. For snapshots that exist right now use vm_list_snapshots or snapshot_aging.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far back to look, 1 to 365 (default 30).
limitNoMax cycle rows when include_cycles is set (capped at 200).
targetNovCenter/ESXi target from config (default if omitted).
vm_nameYesExact VM name; duplicates are refused, not guessed.
include_cyclesNoAlso return the individual cycles, newest kept on cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare a safe read-only, idempotent, non-destructive operation, yet the description adds substantial context beyond them: it is a lower bound, history_unavailable vs coverage_note semantics, vCenter task.maxAge retention expiry (and the vim.fault.InvalidName naming trap), and that duplicate VM names raise rather than resolve. This is rich disclosure, though it stops short of describing pagination or the exact shape returned beyond field names.

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?

Front-loaded with the [READ] tag and the core measurement up top, then structured warnings in descending priority. It is long and occasionally dense, but nearly every sentence carries actionable caveats; a touch of pre-emptive narrative (the vpxd naming aside) keeps it from a 5.

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?

No output schema exists, so the description carries the return-value burden and does so: it enumerates the rollup fields (counts, four hour statistics, latest/longest cycle, unmatched rows) and explains how to interpret each. Nothing essential for correct interpretation is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds interpretation the schema lacks — that the returned counts may cover less than `days` because of retention, and that an exact vm_name is required with duplicates refused rather than guessed — clarifying the practical meaning of two 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?

Opens with a specific verb+resource+scope: measuring how long backup products held a snapshot open on one VM, derived from vCenter task history. It explicitly distinguishes itself from sibling tools by naming vm_list_snapshots and snapshot_aging for currently-existing snapshots, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit routing to alternatives (vm_list_snapshots / snapshot_aging for present snapshots) and states the key use conditions. It also tells the agent when NOT to trust an all-clear, and warns that no open cycle does not prove no backup is running — clear when-to-use and when-not guidance.

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