Skip to main content
Glama

undo_apply

Destructive

Apply a recorded undo by dispatching its inverse tool, with dry_run=True to preview before execution. Each undo token can only be run once.

Instructions

[WRITE][risk=medium] Apply a recorded undo by dispatching its inverse tool.

The inverse runs through its own governed tool, so its real risk tier is
recorded there. 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.

Input Schema

NameRequiredDescriptionDefault
targetNo
dry_runNo
undo_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing that the inverse executes through its own governed tool (so the real risk tier lives there), that dry_run previews the inverse tool and params, and that a token is single-use. These are meaningful operational facts; only failure behavior and return shape are left unspecified.

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 one-line summary, followed by a tight behavioral paragraph and an Args block that substitutes for the undocumented schema. Slightly longer than strictly necessary for a 3-param tool, but each sentence adds information.

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?

No output schema exists and annotations only carry the safety profile, so the description usefully covers sourcing the token, previewing, and single-use semantics. It stops short of describing what is returned on success or how partial/aborted inverses behave.

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 carries the full burden and does: undo_id is sourced from undo_list or an _undo_id field, dry_run previews the inverse call without executing, and target is passed through only when the inverse tool accepts one.

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+resource ('Apply a recorded undo by dispatching its inverse tool') and marks the operation class as [WRITE] with risk=medium. It is clearly distinguishable from the read-only sibling undo_list.

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?

Explicitly points to undo_list (and _undo_id in write results) as the source of the id, and tells the caller how to preview via dry_run=True. It does not state when *not* to use it or what to do if the token was already consumed, beyond noting a token applies only once.

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