Undo agent changes

Misaki Studio can undo or redo one eligible content step in a referenced design file through MCP. The UI and MCP use the same file history, so the next step is determined by the file's actual edit order—not by whether a person or agent made it.

Coverage: UI + MCP for supported design-file content. Partial MCP for recovery across the rest of the project.

What MCP Undo covers

The undo and redo operations load a design file and call its shared content history:

undo { fileUuid }
redo { fileUuid }

Each call moves one history step. Page, Component, and Mockup files use the shared visual design-file model; use a current design-file UUID from list-design-files or get-project-details.

The top-bar Previous and Next controls are unrelated. They navigate file-selection history and do not reverse content.

Undo safely

1. Stop edits to the target file in both the UI and MCP.

2. Read the current tree and the values involved in the unwanted change.

3. Confirm the file UUID and the most recent eligible edit.

4. Call undo once.

5. Read the same targets again and preview the result.

6. Call another undo only after confirming that a further history step should be reversed.

Example:

In the selected Website project, inspect <component reference> and summarize its current state. If the most recent eligible edit is the padding change we just reviewed, call undo once on that design file. Read the padding and surrounding element tree back, show a Preview screenshot, and stop. Do not undo a second step or change any other file.

The condition is important. An intervening UI edit may now be the top history item even if the agent's previous task is the change you remember.

Redo safely

redo reapplies one step that was just undone, provided a new edit has not invalidated the redo path.

Read <component reference>. If the last operation was the one-step undo from this task and the redo is still appropriate, call redo once. Read and preview the result, then stop.

Do not use repeated undo/redo calls to search blindly through a file's history. The operation returns that it moved a step; verification establishes which content is now present.

What design-file Undo does not cover

Do not promise MCP recovery through undo for:

• creating, renaming, moving, duplicating, converting, or deleting a whole file or folder;

• deleting a project;

• edits to non-design file kinds through their dedicated data editors;

• export settings or other project-wide operations unless that workflow documents its own recovery;

• files written to a local export destination;

• Git commits, pushes, tags, or remote repository state;

• package or website publication;

• mutations in an external database or service.

delete-file explicitly cannot be undone. Confirm the exact target and recovery plan before calling it.

Warnings and partial failure

Undo is not a substitute for checking a failed write. A tool handler can fail after some work, and an unknown-field warning can accompany a partially applied call. First read the current target; then either correct the remaining difference or undo the top eligible design-file transaction when you know it represents the unwanted change.

If the wrong history step is undone, do not continue automatically. Verify the state and use one deliberate redo if it is still available.

Recovery outside Undo

For changes outside the design-file stack, recovery depends on the operation:

• recreate or restore a deleted project file from a known copy or versioned source;

• inspect and reverse a file/folder move or rename as a new explicit operation;

• use a reviewed local backup or Git history for exported files;

• revert remote Git, package, website, database, or service changes at that destination.

Document the recovery route before authorizing a destructive or external action.