Recover from a failed MCP write
There is no undo. Recovery means establishing what actually happened, then reversing it deliberately.
First: stop
Close the write gate for the area involved. That takes effect immediately and prevents the assistant making the situation worse while you investigate.
Do not ask the assistant to "fix it" yet. An assistant that has just done something unexpected is not a reliable instrument for repairing it, and a second unbounded attempt is how a small problem becomes a large one.
Second: establish what ran
Open Settings → POM AI → MCP server and read Recent MCP logs. Each entry records the time, the action, the status, the authentication type and the acting user; selecting an action opens the full entry with arguments and outcome.
Work out:
- which tool calls succeeded, and in what order;
- which failed, and with what error;
- which records were touched;
- whether the run stopped partway.
The log is the authoritative record. The assistant's summary of what it did is a description, not evidence — and if it misunderstood the task, its summary will reflect the misunderstanding.
Entries are pruned according to Log retention days, so investigate promptly on a site with a short retention.
Third: distinguish the three cases
The write was refused. Nothing changed. Fix the cause — a closed gate, a missing scope, a missing capability, a malformed argument — and retry. See the error tables in Run your first write MCP request.
The write succeeded but was wrong. The site changed. You need to reverse it.
A batch stopped partway. Some records changed and some did not. This is the awkward case, and the log is the only way to draw the line.
Reversing a wrong write
If you have the old value, write it back. This is why inspecting before changing recommends having the assistant show you current values first — the conversation then holds your undo.
If the record is a post or page, check WordPress revisions. Content changes made through MCP go through the ordinary WordPress save path, so a revision usually exists. Revisions cover content, title and excerpt — not taxonomy terms, meta or featured images.
If it was a deletion, check the trash. Posts, pages and comments normally go to trash rather than being removed outright, so restoring is possible. Media deletion and term deletion are not recoverable this way.
If it was a theme setting, template or option, there is no revision history. Restore from backup, or from a value you recorded.
If none of the above, restore from backup.
The batch case
For a run that stopped partway:
- From the log, list the records that were successfully changed.
- Decide whether to complete the job or reverse it.
- If completing, give the assistant the explicit list of remaining IDs — do not let it re-derive the set, or it may redo the ones already done.
- If reversing, work from the recorded old values.
Re-running the original instruction is the mistake to avoid. It will start from the beginning.
Changes with wide blast radius
Some writes affect far more than the record named:
| Change | Also affects |
|---|---|
| A theme template | Every page using that template |
| A theme setting | Potentially the whole site's appearance |
| An option | Whatever reads that option |
| A content model change | Post types, taxonomies and fields site-wide |
| A term deletion | Every post that was in that term |
| A product price | The storefront, immediately and publicly |
For these, check the rendered site rather than only the record. And purge the cache — a corrected value behind a cached page still shows the wrong one. See Clear the POM Cache.
Afterwards
- Note what the instruction was, and how it was interpreted. Most bad writes trace to an unbounded scope rather than a faulty tool.
- Close gates you opened for the task.
- Consider whether the acting user needs that capability at all. A capability the assistant never legitimately needs is one it cannot misuse.
- Add the boundary to your standing instruction so the same misreading cannot recur.
Preventing the next one
The measures that actually work, in order of effectiveness:
- Work on staging for anything structural.
- Keep write gates closed except during the task.
- Use a limited acting user rather than an administrator.
- Ask for values before changes, so recovery is possible.
- Pilot on three records before doing three hundred.
- Instruct the assistant to stop on the first error.
See Prompt patterns for multi-step MCP work.
If you suspect the client itself
Reset OAuth revokes every client, code and token for the site at once, and Revoke API key stops key access. Both are immediate. Disabling the POM AI MCP tool removes the server entirely.