Skip to main content
Glama
AIops-tools

Veeam AIops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

undo_list

Read-only

List recorded, not-yet-applied undo tokens so you can inspect and apply reversals via undo_apply, with entries showing the inverse tool and whether the original change was verified.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
limitNo
targetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, and the description goes well beyond by documenting the return envelope, truncation behavior, and the effectVerified=False meaning ('the change it reverses is PROBABLE, not confirmed'). This is rich behavioral context an agent needs to avoid false restore claims.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly with [READ] and the core purpose, but it is long and includes design rationale that doesn't serve the caller, e.g. the aside about a 'smaller local model ... tends to report that it has seen every token' and the 'one extra row is requested' justification. Useful signal is diluted by internal commentary.

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?

There is no output schema, so the description must carry the return format, and it does (the undos/returned/limit/truncated envelope plus effectVerified semantics). Both parameters are addressed and the read-only nature is asserted, leaving nothing an agent needs before calling.

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?

With 0% schema coverage the description must compensate, and it does: limit is documented with a default and a 500 cap not present in the schema, and target is explicitly called out as unused. Both params get meaning beyond the bare types, though the 'Args:' docstring block is a slightly awkward vehicle.

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?

States a specific verb (List) and resource (undo tokens) with scope ('recorded, not-yet-applied') and ordering ('most recent first'). It explicitly routes to the sibling undo_apply, letting an agent distinguish it from that tool without opening either schema.

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?

Tells the agent to take the undoId and use undo_apply, and gives a specific precautionary condition (effectVerified=False means check live state before applying and don't claim a restore). Clear context, though there is no explicit 'when not to use' or prerequisite beyond this.

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