Skip to main content
Glama

undo_edit

Revert plumb's most recent file write, restoring only that change instead of discarding all uncommitted edits; refuses if the file changed since, unless forced.

Instructions

Revert plumb's most recent write to a file — the safe alternative to git checkout <file>, which discards EVERY uncommitted change in the file. undo_edit restores only what plumb's last edit_file/write_file changed, and refuses by default if the file was modified since (an external or peer edit), so it never silently clobbers someone else's work (pass force:true to override). If the last write created the file, undo removes it. Single-level per file: it undoes the last write; a fresh write re-arms it. Undo history is per session and cleared on a workspace switch. Very large files (pre-write content over 1 MiB) are not snapshotted, so undo is unavailable for them. Both the restore and the removal of a file the write created return a diff of what the undo changed, gated by [edits].show_write_diff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoRevert even if the file changed since plumb's last write to it (an external or peer edit). Default false — the undo is refused in that case so it cannot silently discard someone else's change.
file_pathNoAbsolute path, file:// URI, or workspace-relative path of the file to revert.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.16.6

TDQS

A4.9/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 it does: refusal on external/peer edits by default, force override semantics, single-level re-arming behavior, session-scoped history cleared on workspace switch, and the 1 MiB snapshot limit. It also discloses the return payload (diff gated by [edits].show_write_diff), which is unusually thorough.

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?

Front-loaded with the core action and the sibling it replaces, then layered with constraints. Every sentence carries a distinct operational fact — no filler, no repetition of the title.

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 destructive-capable mutation tool with no annotations and no output schema, the description covers preconditions, failure modes, irreversible effects (file removal), scope limits, and the shape of the return value. Nothing an agent needs to call it safely 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 meaningful context for `force` by explaining why the default refusal exists (never silently clobbering peer edits) and confirms the accepted path forms for file_path. It reinforces rather than merely restates the schema.

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 ('revert plumb's most recent write to a file') and immediately scopes the blast radius compared to `git checkout <file>`, naming the distinction between last-write-only vs. all uncommitted changes. An agent can distinguish it from edit_file, write_file, and git 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?

Explicitly names the alternative (`git checkout <file>`) and the condition that selects undo_edit over it. It also states when the tool refuses (file changed since last write), the escape hatch (force:true), and when it deletes rather than restores.

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