Skip to main content
Glama

undo

Restore a previous saved version of a CAD document to revert recent modifying operations; specify the number of steps and check history first, as no redo is available.

Instructions

Undo the last steps modifying operations by restoring the previous saved version of the document (up to 20 versions are kept). The restored version replaces the current file; there is no redo, so check list_history first if unsure.

Input Schema

NameRequiredDescriptionDefault
docYes
stepsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it discloses that the restored version REPLACES the current file, that there is no redo, and that only 20 versions are retained. These are the exact behavioral traits an agent needs before invoking a destructive mutation.

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

Conciseness5/5

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

Two sentences, front-loaded with the action, then the behavioral caveats. No filler; every clause 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?

An output schema exists so return values need no explanation, and the description covers irreversibility and version limits thoroughly. The only shortfall is that the document identifier parameter and the behavior when fewer than `steps` versions exist are left unstated.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It clarifies `steps` (how many modifying operations to roll back) and implicitly the default of one, but never explains what `doc` identifies (name, path, or ID) — a gap for the only required parameter.

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 (undo) and resource (last N modifying operations on a document), plus the mechanism (restoring a saved version). An agent can distinguish it from siblings like list_history or object_history 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 Guidelines4/5

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

Explicitly directs the agent to check list_history first when unsure, which is a real alternative-routing instruction. It does not spell out when NOT to use it (e.g. a redo path, since none exists) beyond the no-redo warning, but the context is clear.

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