Skip to main content
Glama

Undo a change

wp_undo
Destructive

Reverse one earlier change using its undo token (from the "undo" field of the original result, or from wp_undo_list). dry_run=true shows exactly what would be restored and what refused, without changing anything; wp_undo_discard drops a point without restoring it. Undoing needs the same permission as the original action, and each item is re-checked against the CURRENT state, so an option that has since been protected or a post this account may no longer edit is reported as blocked rather than restored. An undo of a page-builder change (wp_update_builder_element) or of a plugin's ability (wp_run_ability) puts every stored copy of the page back byte for byte and refuses a page that someone has changed since — restoring would throw that newer work away — unless force=true. A fully successful undo consumes the token; a partial one keeps it, so a later call can retry the rest. Afterwards the page caches of the supported caching plugins are asked to purge the restored posts, and after any other undo (options, settings, theme, files, PHP snippets) every page of this site; page_cache_purged lists them, page_cache_skipped names a cache left out on a multisite network and why. A PHP file of an active plugin or theme that is written back is followed by the same test requests as wp_write_plugin_file runs, and so is a PHP snippet of Code Snippets or WPCode that is written back switched on; probe lists their result per file or snippet. Where the site answered those requests before the undo and does worse after it (a fatal error it did not have, no answer, this MCP endpoint cut), the state before the undo is put back in the same call: the item is listed under failed with the reason, and the token is not consumed, so the undo point stays. Where nothing could be compared, the result is only reported. Forwarded by AlphaBridge Connect to the one site this connection reaches.

Input Schema

NameRequiredDescriptionDefault
forceNoPage-builder undo points only: true restores a page even where it was changed after the change being undone, which throws that later change away. Default false: such a page is reported as blocked (changed_since).
tokenYesThe undo token, e.g. undo_1a2b..., from the undo field of the original result or from wp_undo_list.
dry_runNotrue returns what the undo would restore and changes nothing. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only, change nothing. Default false."New value: +"true returns what the undo would restore and changes nothing. Default false."
    • changedInput schema / properties / force / description
      Previous value: -"Page-builder undo points only: restore a page even where it was changed after the change being undone, which throws that later change away. Default false: such a page is reported as blocked (changed_since)."New value: +"Page-builder undo points only: true restores a page even where it was changed after the change being undone, which throws that later change away. Default false: such a page is reported as blocked (changed_since)."
    • changedInput schema / properties / token / description
      Previous value: -"The undo token, e.g. undo_1a2b..."New value: +"The undo token, e.g. undo_1a2b..., from the undo field of the original result or from wp_undo_list."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say destructive/non-idempotent; the description goes far beyond by disclosing the permission requirement, re-validation against CURRENT state, token consumption on full success versus retention on partial success, cache purging side effects with their result fields, and automatic rollback with the token preserved when a PHP write breaks the site. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical framing (reverse a change via token, dry_run, discard alternative) is front-loaded, which is good. But the remainder is one dense ~250-word paragraph mixing cache purging, PHP probes and AlphaBridge forwarding, which hurts scannability and buries the token-lifecycle rule that matters most for retry decisions.

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

Completeness5/5

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

With no output schema, the description compensates by naming the return fields an agent will encounter (blocked, changed_since, failed, probe, page_cache_purged, page_cache_skipped) and explaining their meaning. Destructive edge cases, rollback behavior and cross-site forwarding are all covered, so nothing needed to call this safely is missing.

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?

Schema coverage is 100% and the schema already explains force/dry_run/token, so the baseline would be 3. The description adds real meaning on top: dry_run reports what would be 'refused', token is only consumed on full success (so retry is possible after a partial), and force interacts with the 'changed since' refusal. It repeats a fair amount of the schema wording, which keeps it off a 5.

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?

Opens with a specific verb+resource+mechanism: 'Reverse one earlier change using its undo token'. It distinguishes itself from the two closely-named siblings by naming wp_undo_discard (drops a point without restoring) and wp_undo_list (a token source), so an agent will not confuse the three.

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

Usage Guidelines5/5

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

Explicitly states where the token comes from, when to use dry_run=true, and which sibling to use instead when the goal is discarding rather than restoring. It also names the conditions that block a restore (protected option, no-longer-editable post, page changed since) and how force overrides one of them, so the agent can predict a refusal before calling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources