Skip to main content
Glama

edit_undo

Revert the newest step in Omni's edit history and return what was undone, helping you reverse an unwanted user or API change.

Instructions

Undo the newest step in Omni's history (the user's or yours; every edit call of this API is one step labelled 'API: ...'). Returns what was undone.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare the safety profile (not read-only, not idempotent, not destructive), so the bar is lower. The description adds meaningful context beyond that: the undo target is a single labeled history step and the call reports what was undone, though it says nothing about what happens when history is empty or how deep the history goes.

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 compact sentences with the action front-loaded and the parenthetical scope note earning its place by explaining what a 'step' means.

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?

Given no parameters, no output schema, and annotations covering the safety profile, the description is largely complete: it names the target and the return ('what was undone'). Only failure/empty-history behavior is left unstated.

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?

Zero parameters, so baseline is 4. The description reinforces that the tool takes no selection input by specifying it always acts on the newest history entry, which is a useful semantic clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (undo) and resource (the newest step in Omni's history), which is clearly distinct from the sibling edit_redo. It doesn't explicitly name edit_redo as the counterpart, but an agent can tell the two operations apart from the text alone.

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?

The description clarifies scope ('newest step', 'the user's or yours') and that every API edit call is one step labelled 'API: ...', which implies when this is useful. However, it never states when-not to use it or names edit_redo as the alternative for re-applying an undone step, so guidance is implied rather than explicit.

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