Infrastructure and backups require a separate administrative channel

The MCP server runs inside WordPress and exposes application-level content and selected product operations. It does not provide shell access, database administration, file browsing, backups, restores, deployments, DNS, TLS, hosting, cron management, or server monitoring.

What “back up first” means

For a consequential task, the client can recommend a backup and pause before the write. It cannot assert that a backup exists or create one through POM AI. The user or hosting administrator must verify the backup in the platform that owns it.

A WordPress read-back is useful evidence but is not a backup. A dry-run predicts an accepted payload but stores no recovery copy. Native WordPress trash or revisions may help some content types, yet POM AI does not expose a universal restore workflow.

Handoff checklist

Before large template, content-model, media-replacement, price, stock, or bulk changes:

• record the exact site and scope;
• have an administrator confirm the relevant backup and restore point;
• use staging when available;
• keep the MCP change bounded and review its dry run;
• verify application state after each non-atomic step.

If an infrastructure problem occurs, stop WordPress writes. Share the public symptom, time, URL, and redacted MCP error with the appropriate administrator; never include credentials or private configuration.

Related guides: failed-write recovery, revisions boundary, and safe support information.