Skip to main content
Glama
sangingeum
by sangingeum

undo_last

Destructive

Revert the previous undoable operation in the selected workspace; conflicting path changes block the entire undo and modify nothing.

Instructions

Undo the most recent undoable operation in the selected workspace. Destructive.

    Same conflict rules as undo_operation: any path changed after the
    operation refuses the whole undo with UNDO_CONFLICT and modifies nothing.
    history_skipped entries in the result were above the history size cap and
    cannot be restored (HISTORY_UNAVAILABLE). The undo is itself recorded.
    

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so 'Destructive.' adds little. However the description adds substantial non-redundant behavior: an all-or-nothing conflict rule (any later path change aborts with UNDO_CONFLICT and modifies nothing), non-restorable history_skipped entries (HISTORY_UNAVAILABLE), and the fact that the undo is itself recorded in history.

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-loads the core action in the first clause and follows with the failure semantics that matter. Only waste is the one-word 'Destructive.' sentence, which merely restates destructiveHint=true.

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?

With no parameters and no output schema, the description carries the burden of explaining outcomes, and it does explain the abort code, the partial-restore limitation, and side effects on history. It is slightly incomplete on what a successful result contains beyond history_skipped (e.g. a list of restored paths).

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?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain any inputs, and its added detail about result codes (UNDO_CONFLICT, HISTORY_UNAVAILABLE) concerns outcomes rather than 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?

States a specific verb and resource ('Undo the most recent undoable operation') and scopes it to 'the selected workspace'. It also names its sibling operation (undo_operation) for the shared conflict semantics, so an agent can distinguish the two without opening schemas.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: 'most recent undoable operation' suggests use when you want a blind rollback, but it never says 'use undo_operation instead when you have a specific operation id' or what happens if no undoable operation exists. It also does not explain how the 'selected workspace' is established.

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