BackupsFree + Pro
BackWPup MCP for job runs, their logs and WP-Cron starts
BackWPup thinks in jobs: each one decides what is backed up, where it goes and when it runs. The BackWPup MCP abilities read those jobs and their run logs, in GoBuildWP Free and Pro alike, so an AI client can report which run worked, what errors or warnings it logged, when each job fires next and whether a local archive still exists. Starting a job BackWPup schedules through WP-Cron is Pro.
Did last night's BackWPup job run cleanly? If not, run it again.
wppilot/backup-statusReadThe nightly job's last run ended with warnings, and its next WP-Cron start is tonight.
wppilot/backup-listReadThe run's log header shows two warnings and no errors; the archive went to S3, so it is reported, not confirmed.
wppilot/backup-triggerWriteStarts that job by its job_id now, since it is a WP-Cron job and nothing is running.
wppilot/backup-statusReadOnce the job stops working, reads the new run's result from its fresh log.
- Edition
- Free 2 + Pro 1
- Abilities
- 3
- Requires
- WordPress 6.9+, PHP 8.0+
Data model
Jobs in options, results in log files
BackWPup's jobs are stored in its options, one configuration per job id, including a hidden temporary job that is skipped. A job's type decides its contents (database, files, a plugin list, an XML export) and its destinations can be a local folder, FTP, cloud storage or several at once. Its next start is a WP-Cron event carrying the job id, or nothing when the job is started by link instead.
The outcome of each run is written into the header of that run's log file, which is where the abilities read it from. A plugin-list job produces a text list of installed plugins, not their files, and the contents in an answer say so.
What BackWPup records
Reading BackWPup from its logs
BackWPup writes a run's result into the header of that run's log, and that is where it is read from. Its lastrun option is stored shifted by the site's UTC offset, so times come from the logs, where they are correct, not from the option.
The log outlives the archive. When retention, the Backups screen or a person deletes the archive, the log stays and still says success. For a job whose only destination is a local folder, a run therefore counts only while the archive its log names is still in the folder; otherwise it is reported as deleted and does not satisfy the fresh-backup check.
A run that went to remote storage is still counted, marked archive_verified false, because confirming that copy would mean calling the remote service. When the fresh-backup check relies on such a run, its refusal or pass says so.
Abilities
The backup abilities when BackWPup is the provider
| Ability | What it does here | Undo and limits |
|---|---|---|
backup-statusFree | Per job: the last run with its result, the last successful run, the job currently working if any, and the next WP-Cron start; plus which jobs can be started from here. | Read-only. A folder-only run whose archive has gone is reported as deleted; a run sent to remote storage is counted but marked archive_verified false. |
backup-listFree | Runs newest first, taken from the log headers, with contents, size, destination names and error and warning counts. | Read-only. Archive file names and paths are never returned. |
backup-triggerPro | Starts one job whose activation type is WP-Cron by firing BackWPup's cron action with that job's id; pass job_id when there are several. | Jobs started by link are refused, and so is a second start while one runs or within the cooldown. The job's own settings decide what is backed up; there is no scope. |
Reference: /docs/reference/backups
Shared module across these plugins; do not add this count across them. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Read example: wppilot/backup-status
Discover this ability and its live schema first. The input below illustrates a bounded read from the source declaration; replace the example ID or name with an object returned by your site. It is not a recorded execution result.
| Parameter | Type and meaning |
|---|---|
provider | string, one of updraftplus, duplicator, backwpup, ai1wm. Only this backup plugin. Defaults to every active one. |
{
"provider": "backwpup"
}Input and output schema from the plugin source
1 input field. Required: none; see schema alternatives and runtime validation. Optional parameters can affect response size and object selection.
{
"input": {
"type": "object",
"default": [],
"properties": {
"provider": {
"type": "string",
"enum": [
"updraftplus",
"duplicator",
"backwpup",
"ai1wm"
],
"description": "Only this backup plugin. Defaults to every active one."
}
},
"additionalProperties": false
},
"output": {
"type": "object",
"properties": {
"active_providers": {
"type": "array",
"items": {
"type": "string"
}
},
"supported_providers": {
"type": "array",
"items": {
"type": "string"
}
},
"providers": {
"type": "array",
"items": {
"type": "object"
}
},
"newest_successful_backup": {
"type": [
"object",
"null"
]
}
}
}
}Source: wppilot/includes/kits/backup-status/src/abilities/backup-status.php
A successful read should identify the requested object and expose the structure described by the output schema. Compare it with the native editor before proposing a change. Troubleshoot missing or refused operations.
BackWPup's own AI tools
BackWPup's own MCP support
BackWPup ships MCP support of its own, built on the WordPress MCP Adapter and signed in with an application password, with setup guides for Claude Desktop, GitHub Copilot in VS Code and OpenAI Codex; its WordPress.org listing also mentions WP-CLI for automation. The abilities are named after backup chores: /get-backup-history, /get-backup-logs, /get-backup-health-status, /get-backup-storage-usage, /get-backup-schedules and /get-backup-retention-policy for monitoring, /create-backup to start one, and /validate-backup-configuration, /check-storage-destination, /check-storage-permissions, /analyze-backup-failure and /scan-backup-configuration-issues for troubleshooting. The announcement adds cancelling a running job.
On a site that only runs BackWPup, that is the deeper toolset. Storage checks, retention rules and failure analysis come from the plugin that wrote the backup, and GoBuildWP has nothing comparable. BackWPup's pages do not describe restoring or deleting backups through MCP.
GoBuildWP's backup abilities do a different job: backup-status and backup-list, both in GoBuildWP Free, and Pro's backup-trigger answer the same way for UpdraftPlus, Duplicator, BackWPup and All-in-One WP Migration, so an agent can learn whether a fresh backup exists before a risky change without knowing which plugin made it. With BackWPup they read results from log headers, confirm folder archives are still on disk, start only WP-Cron jobs, and log each start as irreversible.
Worked example
Checking the nightly job before a big change
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
You have a clean or explained run from today. A run whose only copy is remote satisfies the fresh-backup check, but the check's answer says the archive was taken on the log's word.
Read and assess warnings before triggering a backup. Block on unresolved risks or obtain a deliberate owner decision; discovering a warning is not clearance to proceed.
backup-statusThe nightly job's last run ended with warnings, and its next WP-Cron start is tonight.
backup-listThe run's log header shows two warnings and no errors; the archive went to S3, so it is reported, not confirmed.
backup-triggerStarts that job by its job_id now, since it is a WP-Cron job and nothing is running.
backup-statusOnce the job stops working, reads the new run's result from its fresh log.
Limits
BackWPup behaviour to plan around
- A completed vendor job is record evidence, not proof of a usable off-site copy or restoration. Verify queued WP-Cron completion and rehearse the intended files/database restore separately. These abilities do not download, restore or delete backups.
- BackWPup's Run now link starts a job by calling the site over HTTP; it is not used, because whether that request arrived cannot be confirmed.
- A log can still read success after retention or a person deleted the archive. Only folder destinations are checked against the disk.
- Nothing is restored, downloaded or deleted from here.
- Starting a job is logged as irreversible; unwanted archives are removed in BackWPup.
BackWPup as a safety net
Making BackWPup the condition for risky agent calls
GoBuildWP Pro has a fresh-backup gate, off by default, that the site owner can switch on in Settings. While it is on, any call GoBuildWP rates destructive or critical is refused unless an active backup plugin reports a successful backup newer than the chosen age, from one hour up to a week, with a day as the default. On a BackWPup site the answer comes from the same log-header reading described above, so the job the gate relies on is whichever of your jobs last succeeded.
Two details matter for BackWPup in particular. A folder-only run whose archive has since been removed does not count, so aggressive local retention can make the gate refuse even though the log says success. A run sent to remote storage does count, but the gate's answer says the archive was taken on the log's word. If that distinction matters to you, give the job a local copy as well as the remote one so at least one destination can be checked on disk.
The gate fails closed. With it on and no readable provider, destructive calls are refused with a message saying how to get out, rather than allowed because nothing could be checked. The backup abilities themselves are never held, so an agent that hits the gate on a Pro site can start a WP-Cron job with backup-trigger, wait for backup-status to show the run finished, and try again.
Setting up BackWPup jobs so an agent can use them
Most of what limits an agent here is job configuration, and it is decided in BackWPup's own screens. Give the job you want agents to rely on WP-Cron as its start method, because jobs started by link cannot be triggered from GoBuildWP. Make it a database and files job rather than a plugin-list or XML export job, since the contents shown in backup-status are what an owner will read before approving a destructive change. Name it plainly, because the job name is what appears in every answer.
Questions
BackWPup questions
Why won't the agent start my BackWPup job?
On GoBuildWP Free there is no start ability at all; backup-trigger is Pro. With Pro, the job is set to start by link rather than WP-Cron, or a run is already in progress, or one was started through GoBuildWP a few minutes ago. backup-status lists which jobs can be started.
BackWPup says success, so why is the backup reported as deleted?
The log survives the archive. For a job that only writes to a local folder, a run counts only while the archive its log names is still there.
Can the agent tell whether a BackWPup backup reached S3?
It reads what the log says but does not call the storage service, so remote runs are marked archive_verified false.
Which times do BackWPup answers use?
Times come from the logs, in site time and UTC, not from BackWPup's last-run option.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
BackWPup is a separate product; no partnership or endorsement is implied.