WordPress Backup Plugin MCP that checks the archive still exists.

Which backup plugin gives an agent the most to work with

The four supported plugins keep records of very different quality, and that decides how much an AI agent can honestly tell you. The module table cannot show it, because the same three ability names answer for all of them; what changes is the evidence behind each answer.

• UpdraftPlus keeps the richest history: a file list and a size per entity (database, plugins, themes, uploads, others) for every set, with files and database on separate schedules. Its weak spot is the verdict. Only the latest job records success or failure, so every older set reads result unknown. It is also the only plugin where a Pro start can choose full, database-only or files-only.
• Duplicator gives an exact state for every build, old or new, because each row carries a status number for complete, still building, failed or cancelled. Its free edition has no schedule and no server-side start, so the agent can confirm a build a person ran and never begin one. Duplicator Pro, and Duplicator releases older than its current rewrite, are not read.
• BackWPup is organised around jobs, and results come from each run's log header, error and warning counts included. Logs outlive archives, so only runs written to a local folder are checked against the disk; runs sent to remote storage are counted but marked unverified. Pro can start jobs BackWPup schedules through WP-Cron, not jobs started by link.
• All-in-One WP Migration keeps no records at all beyond the finished .wpress files in its backups folder, so each export is dated by when it finished and a failed one leaves no trace. A file counts only when the plugin's own archive check passes. Pro can start a full export: GoBuildWP runs the plugin's own export steps on the server in short WP-Cron slices instead of relying on the plugin's requests to itself. It starts one at most once an hour and only when the disk has room for about twice the newest export, because the free plugin never deletes an export and has no schedule.

Picking for a site an agent will maintain

If the plugin is not chosen yet, decide which gap you can live with: unknown verdicts on older UpdraftPlus sets, a person in wp-admin for every Duplicator build, BackWPup taking its own log's word for off-site copies, or All-in-One WP Migration exports piling up on the same server as the site. For an agent that should hold a risky change until a backup exists and then start one itself, UpdraftPlus or a WP-Cron BackWPup job is the workable pair. For a site where every backup is a deliberate human act before a migration, Duplicator's exact build states are enough.

One site, two backup plugins: how the answers combine

Agencies often inherit sites where a host-installed backup plugin sits next to the one the client chose. backup-status reads every supported plugin that is active, answers per provider, and then names the newest successful backup across all of them. That summary is convenient and easy to misread: a successful Duplicator build from this morning satisfies it even while the UpdraftPlus job that ships copies off-site has been failing for a week.

Read the per-provider lines, not only the headline. Ask the agent to report each plugin's last success separately and to flag any provider whose last job failed. On GoBuildWP Pro the Require a fresh backup setting also accepts any active provider, so the same caution applies to it: the gate proves a recent backup exists somewhere on the record, not that the one you would restore from is current.

What an agent never receives from a backup plugin

Every answer is limited to times, results, contents, sizes, storage names, labels and error or warning counts. Archive paths and file names, download links, job nonces and storage credentials are never read into a result, and the abilities need an account with the manage_options capability. That ceiling is deliberate: an agent that cannot see where an archive lives cannot fetch it, copy it or pass it on, which matters when the archive holds the whole user table.

It also means some checks stay with a person. Confirming that a remote copy really sits in Google Drive, S3 or on an FTP server means opening that service yourself, and restores happen in the backup plugin's own screen. The backups reference lists the fields each ability returns.

A pre-change backup check to paste into any client

This prompt works whichever of the four supported plugins is installed, because it asks for evidence rather than a plugin-specific action: “Before I change anything, report backup status for every backup plugin on this site. For each, give the last successful backup in site time, what it contained, its size against the set before it, and whether the archive was checked on disk or taken from the plugin's record. Tell me if the database was missing from the newest successful set.”

Then judge the answer against the change you are about to make:

• A database-only backup covers a bulk post edit or a settings change, not a plugin or theme update that replaces files.
• A set much smaller than the one before usually means an entity was skipped or a job was cut short. Look at it before relying on it.
• Queued or running is not a backup. Read status again until the plugin records a result; if a queued job never moves, check whether WP-Cron runs on the site.
• An archive marked deleted or unverified needs a person to check the storage before any change you could not undo.
• Rehearse an actual restore on a staging copy from time to time. No status read proves an archive restores cleanly.

Where this sits next to updates and undo

A backup check is the first half of a safe change. The safe updates workflow builds on it, and the change ledger and rollback covers undoing a GoBuildWP write, which is a separate and narrower tool than restoring a backup: rollback reverses one recorded change, a restore puts back the whole site as it was.