null *ptrs;
EN ES

Why every MCP4Unreal response declares its transaction mode

Competitors claim 'Ctrl+Z reverts any AI action'. We ship three declared transaction modes instead. Here is why universal undo is a promise the editor cannot keep — and what we do about it.


The promise everyone else makes

Several Unreal MCP plugins advertise full undo support: every AI action, instantly reversible with Ctrl+Z. It is a great headline. It is also not something Unreal Editor can actually guarantee, and anyone who has worked with FScopedTransaction knows why.

The editor’s transaction system captures changes to UObjects that participate in the undo buffer. It does not capture files written to disk, assets imported through external pipelines, source-control operations, or state owned by subsystems that never registered with the transaction system. A plugin that claims “any action” either restricts itself to the safe subset and overstates the claim, or claims it anyway and lets you find the exceptions in production.

What we ship instead

Every MCP4Unreal response declares one of three transaction modes:

  • execution_scoped — the mutation ran inside an editor transaction. The undo stack captured it. Ctrl+Z works, and we say so per call, not per brochure.
  • handler_owned — the handler manages its own state lifecycle. Undo semantics are the handler’s documented behavior, not the editor’s.
  • not_applicable — read-only or planning calls. Nothing to undo.

The caller — human or agent — always knows whether the change it just made can be rolled back by the editor history. No guessing, no surprises at the worst moment.

Why this is a feature and not a limitation

The honest answer to “can this be undone?” is “it depends on the operation”. Our position is that an automation bridge should give you that answer on every single response instead of a blanket marketing yes. That is the same principle behind our HonestStub and PlanningOnly tool states: the catalog tells you what actually happens, not what sounds best.

On top of the modes sit confirmation gates. Write, editor-mutation, and destructive tool classes require an explicit confirmation or a dry run before they execute — the validator refuses to ship a tool that skips the gate. Reversibility is the second line of defense; the first is that nothing destructive runs without you saying so.

Where this is going

Declared modes also give us a measurable path forward: we can audit what percentage of the mutation surface is execution_scoped today, migrate handler_owned operations into editor transactions where that is technically sound, and publish the exception matrix for everything that genuinely cannot be undone. When we claim broader undo coverage, it will arrive the same way every MCP4Unreal claim arrives — with validation evidence behind it.