godot-omni

Overview Schema Source Related Servers Discussions Admin

undo_redo_manage

Manage Godot editor's undo/redo history by inspecting stack depth, active action, and history IDs, then execute undo or redo actions to adjust changes.

Instructions

Editor Undo/Redo History Introspection and Transaction Execution.

Ops:

get_history() Query active action name, undo stack depth, and history IDs.
undo() Execute an undo action in the active editor.
redo() Execute a redo action in the active editor.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "undo_redo_manage"
  }
}

Input Schema

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv5.0.28Sep 23, 2026

TDQS

A3.7/5.0

Behavior2/5

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

There are no annotations, so the description carries the full behavioral burden. It labels get_history as a query and undo/redo as 'Execute', which hints at read vs. mutating behavior, but it never discloses failure modes (e.g., empty undo stack), side effects on history, permissions, or whether changes are reversible beyond the undo/redo pair.

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?

The description is compact and front-loaded, with a clear summary line followed by a bulleted op list and a brief call-shape note. There is no filler or redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so explaining return values is not necessary; the op list gives enough to invoke each operation. However, missing session/active-editor preconditions, failure behavior, and per-op parameter semantics leave an agent to infer important operational constraints.

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 description coverage is 0%, so the description must explain op, params, and session_id. It adds a canonical call shape and notes that op/session_id remain top-level, which is useful structural guidance. However, it does not define what session_id means, what values params may contain, or prerequisites for any operation, so it only partially compensates for the schema gap.

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?

The description is specific: 'Editor Undo/Redo History Introspection and Transaction Execution' and then enumerates three distinct operations (get_history, undo, redo) with one-line behaviors. This clearly separates it from the many sibling *_manage tools by domain and action.

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?

The opening line and op list make the use context explicit: use this tool when you need to inspect the active editor's undo/redo history or execute an undo/redo transaction. It does not name an alternative or exclusion, but the domain is clear enough that an agent can select it among siblings like editor_manage or editor_state.

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

Deploy Server