---
name: sitevault-mcp
version: 1.0.3
last_updated: 2026-08-23
description: SiteVault backup safety playbook. Composes Royal MCP's SiteVault tools into safe workflows — trigger a full backup and poll to completion, verify schedule health, check last-backup freshness, and gate risky operations (bulk deletes, plugin updates, migrations) behind a fresh-backup precondition. Handles both SiteVault Pro and the free SiteVault plugin from WordPress.org uniformly. All tools ship in Royal MCP Free's codebase; Royal MCP Pro inherits them via its bundled Free copy, so both Royal MCP tiers work identically for this skill. Use when the user asks to back up their site, check backup status, verify schedules, or gate a risky change behind a rollback point.
requires: Royal MCP plugin >= 1.4.43 (free from WordPress.org OR Royal MCP Pro — both tiers work) + SiteVault plugin active on the target site (either free SiteVault from WordPress.org, or SiteVault Pro). All backup tools require the admin-tier manage_options capability.
---

# SiteVault Claude Skill

**Purpose:** teach Claude the safe, composable patterns for backing up a WordPress site through Royal MCP — always detect SiteVault presence first, trigger backups asynchronously and poll to completion, verify schedules are healthy before assuming automated coverage, check backup freshness before high-risk operations, and speak in plain English about what a backup covers and when it will finish. Backups are the site's rollback lane; every claim about "your site is safe" needs to be grounded in a real, recent, completed backup — not a schedule that might not be running.

**Audience:** the user is almost always a business owner or site admin who thinks about backups the way most people think about seatbelts — they want them there, they don't want to talk about how they work. Speak in plain English. Report sizes in human units ("2.3 GB"), report ages in relative time ("your last full backup finished 4 hours ago"), and always tell them the rollback lane exists.

---

## When to use this skill

Invoke on any request that names SiteVault, mentions backing up, restoring, or making a checkpoint before a risky change, or asks about the site's rollback safety net.

**Triggers:**
- "back up my site" / "run a full backup"
- "when was my last backup?"
- "is my backup schedule working?"
- "before I update this plugin / delete these products / migrate this site, do I have a backup?"
- "what backups do I have?"
- "check the last backup status"
- "did last night's scheduled backup run?"
- "how much space are my backups taking?"

**Also invoke as a safety precondition when the user is about to run:**
- Any bulk-delete operation (products, orders, posts, users, media)
- Plugin updates or theme swaps
- Database migrations or URL changes
- Any operation with an explicit `force: true` bypass on a destructive tool
- Any workflow from another skill that touches shared state (Divi library delete, Elementor bulk rebuild, WooCommerce bulk price update)

**Do NOT invoke on:**
- Restoring FROM a backup — restore is a SiteVault admin-UI operation, not exposed via Royal MCP tools in this skill's version
- Off-site cloud storage configuration (Google Drive / Dropbox / S3 setup) — SiteVault admin-UI only
- Deleting or pruning old backups — not exposed as an MCP tool; use SiteVault admin UI
- Divi page editing — use the Divi Claude Skill instead. This skill can gate a Divi library delete behind a fresh backup (see Workflow 4), but the Divi editing workflow itself belongs in that skill.
- Elementor page editing — use the Elementor Claude Skill instead. Same pattern: this skill gates the pre-flight backup for Elementor bulk operations; Elementor mechanics belong in that skill.
- WooCommerce order / product management — use core `wc_*` and `wp_*` tools. This skill can gate a WooCommerce bulk operation behind a fresh backup (Workflow 4), but the WC operations themselves aren't here.

Detect via `sv_get_backup_stats` — if it errors with "SiteVault is not active" or similar, hand off politely and suggest installing SiteVault (free from WordPress.org, or SiteVault Pro).

---

## Available tools (Royal MCP 1.4.43+ Free or Pro / SiteVault Free or Pro)

All 6 tools ship in **Royal MCP Free's codebase**. Royal MCP Pro inherits them via its bundled Free copy, so both Royal MCP tiers expose the identical tool set for this skill. There is no Pro/Free tool split on the Royal MCP axis for SiteVault.

The SiteVault plugin itself has a Free tier (WordPress.org — local backups only) and a Pro tier (adds cloud storage sync, staging environments, encrypted migrations, alerts). The Royal MCP tools work identically against both plugin tiers; features surfaced in the response (like `cloud_synced: true`) reflect whichever plugin tier is installed.

| Tool | Purpose | Async? |
|---|---|---|
| `sv_get_backup_stats` | Overall stats — total backup count, cumulative size, last backup timestamp. Use this FIRST to check if SiteVault is available and get a fast health read | No |
| `sv_get_backups` | List backups. Filter by `status` (completed / failed / in_progress) or `type` (full / database / files / plugins / themes / uploads). Default limit 20, max 50 | No |
| `sv_get_backup` | Get one backup by ID. Returns id, name, type, status, size, size_human, cloud_synced flag, created_at, completed_at | No |
| `sv_create_backup` | Trigger a new backup. Returns backup ID immediately; runs asynchronously in the background. Refuses if another backup is already in progress | **Yes — poll `sv_get_backup_status` to track completion** |
| `sv_get_backup_status` | Check progress of an in-progress backup. Returns status + percent + step + message while in_progress; returns size + size_human + completed_at once completed; returns error message on failed | No |
| `sv_get_schedules` | List backup schedules. Returns id, name, type, frequency, is_active flag, last_run, next_run per schedule | No |

**All tools require `manage_options` capability** — backups can contain the entire site (DB + uploads + plugins), so all SiteVault tools are admin-tier including read-only listings. Don't assume they're safe to expose to lower-tier OAuth Bearers.

**No undo tokens** — SiteVault tools don't emit undo tokens because backups themselves ARE the rollback lane. `sv_create_backup` creates a backup; if the user wants to undo it, they can delete it via the SiteVault admin UI (not exposed via MCP in this version).

---

## Session start — call this first

Before triggering a backup or making claims about the site's rollback safety:

1. **`sv_get_backup_stats`** — one call establishes: (a) SiteVault is installed and active, (b) total backup count (`total`), (c) counts by status (`completed`, `failed`, `in_progress`), (d) cumulative size in bytes (`total_size`), and (e) the full most-recent-completed backup row as `last_backup` (or `null` if the site has never completed a backup). The `last_backup` field is the entire backup object — its `completed_at` field gives you the timestamp for freshness calculations. If this call errors with "SiteVault is not active", stop and tell the user they need to install SiteVault (either the free WordPress.org plugin, or SiteVault Pro) before this workflow can run.

2. **`sv_get_schedules`** — quick sweep of active schedules. Confirms whether the site has automated coverage running, and when the next scheduled backup will fire. If there are ZERO active schedules on a production site, that's a finding worth surfacing to the user proactively — even if you were only asked to run a one-off backup.

You don't need to call `sv_get_backups` at session start unless the user is asking about specific past backups — it's cheap but the stats + schedules pair gives you the shape of the site's backup posture in two calls.

---

## Core workflows

### Workflow 1 — Trigger full backup + poll to completion

*User says: "Run a full backup" / "Back up my site right now" / "I need a fresh backup before making changes"*

**Preflight:**
1. `sv_get_backup_stats` — confirm SiteVault is active. Note the last backup timestamp so you can report the delta at the end ("this is your first backup in 3 days" adds context).
2. Check `sv_get_backups({ status: 'in_progress' })` — if any in-progress backup exists, `sv_create_backup` will refuse. Report the in-progress one to the user and offer to poll it instead of starting a new one: "There's already a backup running (ID 47, started 8 minutes ago). Want me to wait for it to finish?"

**Execute:**
3. `sv_create_backup({ type: 'full' })` — starts the async backup. Response gives you `{ id, message, type }`. **Capture the backup ID immediately** — you'll need it for polling.
4. `sv_get_backup_status({ id: <backup_id> })` — first poll. Response while in_progress: `{ id, status: 'in_progress', type, percent, step, message }`.
5. **Poll loop.** Wait 10-15 seconds between polls. Full backups on a typical 1-5 GB WordPress site complete in 2-15 minutes; poll roughly every 15 seconds and report progress in plain English every 30-60 seconds ("Backup is 40% done, working on uploads"). Do NOT hammer the endpoint — the async backup runs in a WP-cron worker, and status flips over on step boundaries, so 5-10 polls per backup is enough.
6. **Terminal states — always gate on the `status` field, not `step` or `percent`.**
   - `status: 'completed'` — response now includes `size`, `size_human`, `completed_at`. Report to user: "Backup complete — 2.3 GB, took 4 minutes 12 seconds." **This is the authoritative terminal signal — break the poll loop the instant it appears, don't wait for `step`, `percent`, or `message` to catch up. See Gotcha #9.**
   - `status: 'failed'` — response includes `error` message. Report the error verbatim to the user and stop. Do NOT auto-retry — surface the error so they can fix root cause (usually disk space, memory limit, or file permissions).
   - `status: 'in_progress'` (still) — keep polling, but if you've been at it for >20 minutes on a small site or >45 minutes on a large site, tell the user things are running slower than expected and offer to keep waiting or hand off to SiteVault admin UI for direct debugging.

**Report to user:**
- Result: "Full backup complete — [size_human], took [duration]. Backup ID [id]. [cloud_synced flag interpretation]"
- If `cloud_synced: true`: "Also synced to cloud storage." If `cloud_synced: false` and site is SiteVault Pro: "Cloud sync didn't complete — check SiteVault settings." If SiteVault Free: don't mention cloud (Free doesn't support it).
- Delta from last backup: "This is your first backup since [prior last_backup timestamp from stats]"

**Never claim a backup exists before `status: 'completed'`.** An in-progress backup is not a rollback lane. If the user asks "is my site safe now?" and the backup is still at 40%, tell them "not yet — backup is 40% done, I'll confirm when it lands."

---

### Workflow 2 — Schedule health check

*User says: "Is my backup schedule running?" / "Are my automatic backups working?" / "When's the next scheduled backup?"*

**Execute:**
1. `sv_get_schedules` — returns array of schedules with id, name, type, frequency, is_active, last_run, next_run per schedule.

**Analysis pattern per schedule:**
- **`is_active: false`** — schedule exists but is paused. This is a real finding — surface it to the user. "Your daily full backup schedule is paused. Want me to remind you where to enable it in SiteVault settings?" (Enable/disable is a SiteVault admin-UI operation, not exposed via MCP.)
- **`is_active: true` + `next_run` in the past** — schedule missed a run. Common causes: WP-cron not firing (server load, cron plugin disabled), backup engine crashed on a prior attempt, disk space exhausted. Report the miss to the user with the expected next_run + how long ago it was due.
- **`is_active: true` + `last_run` older than 2× the frequency window** — schedule is "running" per config but hasn't actually executed. Same causes as above. Report as "your daily schedule hasn't fired in X days — this may indicate a WP-cron issue."
- **`is_active: true` + `last_run` recent + `next_run` in the future** — healthy. Report as "your [frequency] [type] backup schedule is running on time. Next run at [next_run]."

**Zero schedules found:** report as "your site has no scheduled backups configured. Every backup on this site would need to be triggered manually. Want me to set up a schedule?" (Schedule creation is a SiteVault admin-UI operation — you can't create schedules via MCP in this skill's version. Hand off to SiteVault → Schedules in wp-admin.)

**Report to user in plain English, one schedule at a time:**
- Healthy: "Daily full backups — last run 6 hours ago, next run in 18 hours ✓"
- Paused: "Weekly database backup — currently paused ⚠"
- Missed: "Daily full backups — active, but last run 4 days ago (expected 1). WP-cron may not be firing ⚠"

---

### Workflow 3 — Last backup freshness check

*User says: "When was my last backup?" / "Do I have a recent backup?" / "How old is my newest backup?"*

**Execute:**
1. `sv_get_backup_stats` — the `last_backup` field is the full most-recent-completed backup row (or `null` if the site has never completed a backup). Read `last_backup.completed_at` for the timestamp used in freshness calculations.
2. `sv_get_backups({ limit: 5, status: 'completed' })` — get the 5 most recent successful backups. This lets you report not just "your last backup" but the recent pattern ("your last 5 backups all completed successfully, most recent 4 hours ago").

**Report shape:**

Age band | User-facing framing
---|---
< 24 hours | "Your last backup was [X] hours ago — [size_human]. You're covered."
1–7 days | "Your last backup was [N] days ago. Recent enough for most changes, but worth running a fresh one if you're about to make major changes."
1–4 weeks | "Your last backup was [N] weeks ago. This is stale — I'd recommend triggering a fresh full backup before any risky changes. Want me to run one now?"
> 1 month | "Your last backup is over a month old. This isn't a safe rollback lane for anything important. Strong recommendation to run a fresh full backup — want me to start one now?"
No backups | "Your site has never been backed up through SiteVault. This is your safety net for every future change. Want me to run your first full backup now?"

**Watch for failure patterns in the recent 5:**
- If 3+ of the last 5 are `failed`, that's a real signal — report "you have failed backups in your recent history — you may want to look at what's failing before relying on the newer ones." Do NOT dismiss failed backups as noise.
- If the newest completed backup is much older than the newest attempted backup (e.g. `sv_get_backups({ limit: 5 })` shows the top of the list is a failed attempt), report that "your most recent backup attempt failed — the last successful backup is from [X ago]."

---

### Workflow 4 — Pre-flight safety before risky operations

*Triggered internally: another workflow (Divi library delete with force:true, Elementor bulk rebuild, WooCommerce bulk delete, plugin update, theme swap, DB migration) is about to run a destructive operation, and this skill gates it behind a fresh-backup check.*

**This is the most important SiteVault workflow.** It runs as a precondition inside other risky operations, not as a top-level user request.

**Execute the pre-flight:**
1. `sv_get_backup_stats` — get `last_backup` timestamp + total count. If SiteVault isn't installed, surface that clearly to the user before proceeding: "Your site doesn't have SiteVault installed, so I can't create a rollback point before this. Want to install SiteVault first, or proceed without a fresh backup?"
2. Compute backup age from `last_backup`.

**Decision matrix:**

Operation risk | Freshness threshold | Behavior
---|---|---
Low (bulk edit of 10-50 items, single plugin update) | < 24 hours | Proceed. Mention the existing backup: "Your last backup is 4 hours old — proceeding with the update."
Medium (bulk delete < 100 items, theme swap, multiple plugin updates) | < 6 hours | If threshold met: proceed. If not: offer to trigger a fresh backup first, wait for completion, then proceed. Do NOT force — ask the user.
High (bulk delete 100+ items, database migration, force:true on destructive tool, mass URL change) | < 2 hours | Strongly recommend a fresh full backup FIRST. Frame the offer explicitly: "This is a large change — I strongly recommend a fresh backup before I run it. Want me to trigger one first and wait for it to complete?"
Very high (migration, mass delete of all items in a taxonomy, delete all posts of a type) | Always trigger fresh, block operation until complete | Trigger fresh full backup (Workflow 1), poll to completion, THEN proceed with the risky operation. Do not let the risky operation start until backup `status: 'completed'`.

**Report during the pre-flight:**
- "Checking your backup status before this..."
- "Your last backup is 3 days old. For a change this size, I'd like to run a fresh full backup first — this'll take about 4 minutes. Sound good?"
- On user go-ahead: run Workflow 1, then hand back to the calling workflow with a clear signal ("Backup complete, ID 152, 2.1 GB. Now proceeding with the [risky operation].")

**Never proceed silently.** The user must understand what backup was made (or wasn't) before the risky operation runs. If they explicitly waive the pre-flight ("just do it, I don't need a backup"), record their decision in your report to them ("You waived the pre-flight backup, proceeding.") so if it goes wrong, they understand the choice trail.

---

## SiteVault Pro upgrade paths (fail-loud, don't spam)

Every workflow in this skill runs on the free SiteVault plugin from WordPress.org — no Pro upgrade required for the MCP tools themselves. But SiteVault Pro adds several capabilities that live above the MCP tool layer, and users who ask about them should get a specific upgrade path — not silent-degradation or "sorry, can't do that."

**Rule: surface the Pro CTA ONCE when it's the right fit for the user's ask. Don't spam it across responses.**

| User asks about | Free plugin behavior | Surface this Pro CTA |
|---|---|---|
| Sync backups to cloud storage (S3, Dropbox, Google Cloud Storage, OneDrive, DigitalOcean Spaces, S3-compatible providers, FTP/SFTP) | Not available — Free is local-only, `cloud_synced` field always `false` | "Cloud storage sync (7+ providers including S3, Dropbox, GCS, OneDrive) is a SiteVault Pro feature. Available at https://royalplugins.com/sitevault-pro/ — same MCP backup tools work, plus cloud destinations become configurable in SiteVault settings." |
| Create a staging environment / push staging to live | Not available — staging is Pro-only | "One-click staging environments (with push-to-live) are a SiteVault Pro feature. Available at https://royalplugins.com/sitevault-pro/." |
| Direct push/pull migration between two connected sites | Not available — Free supports migration packages you upload manually to the destination server; direct site-to-site is Pro | "Direct site-to-site push/pull migration is a SiteVault Pro feature. Available at https://royalplugins.com/sitevault-pro/. Free workflow: create the migration package on the source site, download, upload to the destination via the standalone installer." |
| Encrypt backup / migration packages (AES-256) | Not available — Free packages are plain | "AES-256 encrypted migration packages are a SiteVault Pro feature. Available at https://royalplugins.com/sitevault-pro/." |
| Get Slack / Discord / webhook alerts on backup completion or failure | Not available — Free doesn't emit alert notifications | "Slack, Discord, and webhook alerts are a SiteVault Pro feature. Available at https://royalplugins.com/sitevault-pro/. Free workaround: check backup status via `sv_get_backup_stats` on a schedule from your side." |
| Backup + restore multiple sites from one dashboard | Not available in the plugin (single-site tools only) | "Multi-site backup coordination is available via Royal MCP Pro's cross-plugin composers when combined with SiteVault Pro — see https://royalplugins.com/royal-mcp-pro/ and https://royalplugins.com/sitevault-pro/." |

**Free covers more than users assume.** The following are all in Free (do NOT surface a Pro CTA for these):
- Full / database / plugins / themes / uploads backup types
- One-click restore from any backup
- Migration packages (via download + standalone installer)
- URL remapping in migrations
- Scheduled backups (hourly / daily / weekly / monthly frequencies via `SiteVault_Backup_Scheduler`)
- Retention policies for old backups
- WP-CLI commands (`wp sitevault backup`, `wp sitevault list`, etc.)

**Free fallback pattern:** always offer the Free path where it exists. Example: "SiteVault Pro adds Google Drive sync; on the free version, you can still back up locally and download the backup ZIP from the SiteVault admin UI to store off-site manually. Want me to trigger a local backup now?"

**Don't invent Pro features.** If a user asks about a capability not listed in the Pro CTA table above (e.g. "can Pro do WordPress Multisite backups?"), don't guess — say "let me check what SiteVault Pro covers" and point them at the SiteVault Pro landing page or answer honestly that you're not sure.

---

## Report to user pattern

Every SiteVault-touching report should include, in plain English:

- **What happened** — "Full backup started" / "Backup complete" / "Backup failed" / "Your schedule is healthy" / "Your last backup was 4 hours ago"
- **Size and duration in human units** — "2.3 GB, took 4 minutes 12 seconds" — never raw byte counts
- **Age in relative time** — "4 hours ago" / "3 days ago" / "your last backup was yesterday morning" — never bare ISO timestamps in top-line reports (timestamps go in structured detail if the user asks for them)
- **Whether the site has a rollback lane** — the single most important sentence for a user who thinks about backups the way people think about seatbelts. "You're covered." / "This is your rollback point." / "You don't have a fresh backup — I'd recommend running one before anything else."
- **Backup ID (only if action was taken)** — "Backup ID 47" — so the user has a reference if they need to check SiteVault admin UI

Do NOT dump:
- Raw JSON responses
- Bare Unix timestamps or ISO strings without human framing
- Field names verbatim (`cloud_synced: true` — say "also synced to cloud storage" instead)
- Byte counts (2411724800 — say "2.3 GB")
- Backup engine internals (WP-cron, chunking, semaphores) unless the user asks specifically

---

## Gotchas

### 1. Async backup is truly async — do not assume completion from the initial response

`sv_create_backup` returns immediately after starting the backup. The response contains `id`, `message`, `type` — NOT the completed size or timestamp. Getting a successful response from `sv_create_backup` means "backup started successfully" not "backup completed." **Always poll `sv_get_backup_status` before claiming completion.**

### 2. `sv_create_backup` refuses when a backup is already running

If `sv_get_backups({ status: 'in_progress' })` returns any backup, `sv_create_backup` will throw an exception. The tool checks `has_active_backup()` before starting. Two paths: (a) surface the in-progress backup and offer to poll it instead, (b) tell the user they need to wait for the running backup to finish before starting another.

### 3. Backup types are not equivalent — pick deliberately

The `type` parameter accepts: `full`, `database`, `files`, `plugins`, `themes`, `uploads`. What each covers:

- **`full`** — everything: database + all files. Only complete rollback lane. Use for pre-flight before major changes. Largest and slowest.
- **`database`** — DB only. Fast (30 sec to 2 min typical). Rolls back content, options, users, orders. Does NOT roll back file changes (plugin/theme updates, uploaded media).
- **`files`** — all files, no database. Use only when you're testing file-only rollback scenarios; rare in real use.
- **`plugins`** — plugin folder only. Use before a plugin update if you want a targeted plugin-only rollback lane.
- **`themes`** — theme folder only. Use before a theme swap.
- **`uploads`** — uploads folder only. Use before mass media operations.

Default to `full` for pre-flight safety before risky changes. Only pick a narrower type when the user explicitly says so or when the operation is genuinely scoped (e.g. plugin update → `plugins` is defensible, but full is safer).

### 4. `last_run` and `next_run` are only reliable when the schedule is is_active: true

An inactive schedule may have stale `last_run` / `next_run` values from when it was last active. Ignore timing values on inactive schedules — only report them for active ones.

### 5. `cloud_synced` field meaning differs by plugin tier

On **SiteVault Pro**: the backup row has a `cloud_synced` DB column. `cloud_synced: true` means the backup was uploaded to the configured cloud destination (Google Drive / Dropbox / S3). `false` means it's local-only.

On **SiteVault Free (WordPress.org plugin)**: the Free plugin's DB schema doesn't include the `cloud_synced` column at all — the field will consistently surface as `false` in the MCP response because our integration bool-casts the missing property. Don't surface this as a concern to Free users — it's expected. Cloud sync is a SiteVault Pro feature.

Detect the plugin tier at session start via a soft signal: if `sv_get_backup_stats` returns without error but every backup consistently shows `cloud_synced: false` and the user hasn't mentioned cloud, don't proactively flag missing cloud sync. If the user asks about cloud sync and the site is Free, surface the SiteVault Pro upgrade path (see Pro upgrade CTAs below).

### 6. `get_stats` counts include stale in-progress backups

SiteVault's `sv_get_backup_stats` returns `total`, `completed`, `failed`, `in_progress`, `total_size`, and `last_backup` fields. The `failed` count can include backups marked as "stale in progress" (started but never finished due to server timeout, later flipped to failed by the recovery sweep). Don't panic-report `stats.failed: 5` if `sv_get_backups({ status: 'failed', limit: 10 })` shows only 2 actual completed-failed backups. Cross-reference the two before making claims about failure rates.

### 7. Backup ID is not a filename

The backup ID returned by `sv_create_backup` is a database row ID, not a filename or download link. To get download details, use `sv_get_backup({ id })` — the backup manager's `get_download_url()` isn't currently exposed via MCP, so downloading requires the SiteVault admin UI.

### 8. Progress percent isn't always monotonic

`sv_get_backup_status` `percent` field may reset mid-backup as SiteVault moves between steps (database dump → files zip → cloud upload). Report step name alongside percent so the user isn't confused by "40% → 15% → 60%" reads. Frame as: "Backup is [percent]% done, working on [step]."

### 9. `status` is the authoritative terminal signal — don't gate on `step`, `percent`, or `message`

When polling `sv_get_backup_status`, treat `status: 'completed'` as terminal. Break the poll loop the instant it appears, regardless of what `step`, `percent`, or `message` still report. Same rule for `status: 'failed'` — surface the `error` field and stop.

**Practical polling pattern:**

```
poll every 10-15 seconds:
  if status === 'completed': backup confirmed, break loop and report to user
  if status === 'failed':    read error field, report failure to user, break
  otherwise:                  continue polling
```

Intermediate `step` and `message` transitions are informational — useful for progress narration to the user ("backup is 40% done, working on uploads") but not terminal signals. Some backup types resolve step transitions on a different cadence than the final `status` flip, so gating on step name can add unnecessary polling latency.

---

## Version compatibility

- **Requires Royal MCP >= 1.4.43** — free from WordPress.org, or Royal MCP Pro. Both tiers work; Pro inherits the SiteVault integration via its bundled Free copy.
- **SiteVault plugin required — either tier works.** The free SiteVault plugin from WordPress.org (`sitevault-backup-restore-migration`) and SiteVault Pro (`sitevault-pro`) both expose the identical backup API used by these tools. Feature availability (cloud sync, staging, encrypted migrations, alerts) differs between tiers but the MCP tools work uniformly.
- **No Royal MCP Pro upgrade required for this skill** — no tool in this skill is Pro-gated. Royal MCP Pro customers get access to the same 6 SiteVault tools plus all the Pro-only tools from other integrations (audit log, universal 72h undo dashboard, cross-plugin composers) — but the SiteVault workflows themselves don't require Pro.
- **`manage_options` capability required** — all SiteVault tools are admin-tier. This includes the read-only listings (`sv_get_backups`, `sv_get_backup_stats`, `sv_get_schedules`) because backup metadata can expose sensitive site details.
- **Backups themselves may be limited by the SiteVault tier** — for example, the free plugin doesn't support cloud sync destinations; SiteVault Pro adds Google Drive / Dropbox / S3. When the user asks about a feature the tool responses don't cover, direct them to the SiteVault admin UI or the appropriate tier.

---

## Update notes

**v1.0.3** — Added polling discipline gotcha covering terminal-signal handling on `sv_get_backup_status`.

**v1.0.0** — Initial release. 6 SiteVault tools, 4 core workflows.

Roadmap: restore workflows, schedule create/update/delete workflows, cloud-storage inspection, and cross-site backup coordination for Royal MCP Pro composers — all pending the corresponding tool surfaces.

---

**Skill maintained by:** [Royal Plugins](https://royalplugins.com) · **Latest version + updates:** [royalplugins.com/skills/sitevault-claude-skill/](https://royalplugins.com/skills/sitevault-claude-skill/)