Backup and Recover MCP Server

The platform/backup-and-recover server exposes Salesforce Backup and Recover operations to AI agents over the Model Context Protocol (MCP). It gives an agent grounded, consequence-aware tools to discover and inspect backups, read the org’s ingestion policy and retention rules, review Backup and Recover audit history, start on-demand backups, and drive the guided restore workflow — all scoped to the calling user’s org.

This server is the single unified home for the full Backup and Recover tool surface. The read/write distinction is expressed per tool through tool annotations rather than through separate servers. Every destructive operation is deliberately kept off the MCP surface.

• Discover and inspect backups, including per-object detail and status
• Read the org’s backup ingestion policy, retention rules, and audit history
• Start an on-demand backup and poll it to completion
• Drive the guided restore workflow: compare two backups, inspect the differences, refine the record selection, and confirm the selection counts
• Review restore results after a restore runs on the non-MCP surface

• API version: v67.0 and later
• Backup and Recover Data and Backup and Recover Files add-on licenses enabled in your org
• Permissions:
  • BackupAndRecoverSuperAdmin permission set for comprehensive access to all Backup and Recover operations
  • Or specific permissions based on operations (see Backup and Recover Next Permissions for details)
  • Object-level and field-level security applies to all operations
• External Client App configured with the mcp_api scope
• MCP client installed and configured with OAuth authentication

For setup instructions, see Set Up Your Org.

• Production: https://api.salesforce.com/platform/mcp/v1/platform/backup-and-recover
• Sandbox/Scratch: https://api.salesforce.com/platform/mcp/v1/sandbox/platform/backup-and-recover

• “Show me the most recent backups for my org and their status.”
• “Start a full on-demand backup and let me know when it finishes.”
• “Compare my two most recent backups and show me what changed on Account and Contact.”
• “Select all Technology-industry Accounts from the compare for restore, then confirm the counts.”
• “Show me the results of the last restore, broken down by object.”

The platform/backup-and-recover server provides 22 tools: 6 backup reads, 1 backup write, 13 recover reads, and 2 recover writes. All tool calls are scoped to the caller’s org. The IDs shown in the examples are illustrative.

Each tool carries annotations that describe its behavior. The hints are set explicitly so that serialized annotations carry concrete boolean values.

The update_selection_records tool overwrites the prior selection but is deliberately not marked destructive, because the selection overlay is preview state, not customer data.

Use these tools to discover backups and read the org’s backup policy, retention rules, and audit history.

Lists backups for the org with optional pagination and sort. Use this first to discover backup IDs.

1{
2  "tool": "get_backups",
3  "parameters": { "pageNumber": 1, "pageSize": 20, "sort": "startTimestamp", "sortDir": "DESC" }
4}

Returns the current state of one backup, including status, counts, and per-object detail. Use this as the polling tool after you start a backup.

1{ "tool": "get_backup_by_id", "parameters": { "backupId": "0Bh000000000001" } }

Returns the per-object breakdown of a backup, with an optional objectType filter and pagination.

1{
2  "tool": "get_backup_objects",
3  "parameters": {
4    "backupId": "0Bh000000000001",
5    "objectType": "Account",
6    "pageNumber": 1,
7    "pageSize": 50
8  }
9}

Returns the current backup ingestion policy, including schedules, exclusions, and file and attachment inclusion.

1{ "tool": "get_latest_policy", "parameters": {} }

Returns the current retention rules, mapping cadence to retention years.

1{ "tool": "get_retention_rules", "parameters": {} }

Returns Backup and Recover audit events, most recent first, paginated.

1{ "tool": "get_audit_events", "parameters": { "pageNumber": 1, "pageSize": 25 } }

Mutating and additive. Starts a new on-demand backup of the configured policy. This tool is asynchronous: it returns a backupId immediately, so poll get_backup_by_id for completion. The object scope is policy-driven — the tool runs the configured policy and doesn’t let the caller choose objects. On-demands are limited to three calls per day, including calls made from the UI or API.

1{ "tool": "enqueue_backup", "parameters": {} }

The response returns a backupId with a queued flag. When the backup isn’t queued, the response includes an enqueueRejectionReason, such as DELTA_REQUIRES_FULL_COMPLETED, SAME_TYPE_AND_CONTENT_ALREADY_QUEUED, or DAILY_ON_DEMAND_LIMIT_REACHED. Then poll:

1{ "tool": "get_backup_by_id", "parameters": { "backupId": "<returned backupId>" } }

Use these tools to list recover activities, inspect compare results, and review restore results.

Lists recover activities (compare, restore, download), most recent first.

1{ "tool": "get_activities", "parameters": { "pageNumber": 1 } }

Returns the state of one restore-with-hierarchy activity. Use this as a polling tool.

1{ "tool": "get_restore_with_hierarchy", "parameters": { "activityId": "<restoreActivityId>" } }

Returns the state of one compare activity, including the from and to backups and the objects in scope. Use this as a polling tool after you create a compare.

1{ "tool": "get_compare_activity", "parameters": { "activityId": "<activityId>" } }

Returns per-object change counts for a compare activity, with an optional searchTerm and pagination.

1{
2  "tool": "get_compare_activity_summaries",
3  "parameters": {
4    "activityId": "<activityId>",
5    "searchTerm": "Account",
6    "pageNumber": 1,
7    "pageSize": 25
8  }
9}

Returns record-selection metadata and preview for a restore activity.

1{
2  "tool": "get_restore_activity_record_selection_metadata",
3  "parameters": { "activityId": "<compareActivityId>" }
4}

Returns selected-for-restore counts split by changed and deleted, for one object.

1{
2  "tool": "get_selection_counts_by_type",
3  "parameters": { "activityId": "<compareActivityId>", "objectName": "Account" }
4}

Returns per-status insert and update result counts for one object on a restore activity.

1{
2  "tool": "get_restore_result_counts",
3  "parameters": { "activityId": "<restoreActivityId>", "objectName": "Account" }
4}

Returns the flat (non-hierarchy) restore rollup plus per-object breakdown.

1{ "tool": "get_restore_activity", "parameters": { "activityId": "<restoreActivityId>" } }

Performs a generic single-activity lookup of any type, for when the activity type is unknown.

1{ "tool": "get_activity", "parameters": { "activityId": "<activityId>" } }

Returns per-node-path deleted and modified counts and preview/restore status.

1{
2  "tool": "get_hierarchy_summary",
3  "parameters": { "activityId": "<activityId>", "nodePaths": ["Account", "Account:Contact"] }
4}

Returns the per-object restore summary (updated, inserted, failed), paginated and filterable.

1{
2  "tool": "get_restore_activity_summary",
3  "parameters": {
4    "activityId": "<restoreActivityId>",
5    "searchTerm": "Account",
6    "pageNumber": 1,
7    "pageSize": 25
8  }
9}

Returns per-record restore results for one object, including new and old IDs, status, and insert or update.

1{
2  "tool": "get_restore_activity_object_results",
3  "parameters": {
4    "activityId": "<restoreActivityId>",
5    "objectName": "Account",
6    "pageNumber": 1,
7    "pageSize": 50,
8    "searchTerm": ""
9  }
10}

Returns per-record results for one node path in a restore-with-hierarchy activity. The type parameter selects the tab: inserted for the hierarchy-tree view, updated for the flat view.

1{
2  "tool": "get_restore_with_hierarchy_results",
3  "parameters": {
4    "activityId": "<restoreActivityId>",
5    "nodePath": "Account:Contact",
6    "type": "inserted",
7    "pageNumber": 1,
8    "pageSize": 50
9  }
10}

Mutating and additive. Creates a compare that diffs two backups. This tool is asynchronous: it returns an activityId immediately, so poll get_compare_activity for completion. Pass "objects": ["all"] to compare every object present in both backups. The activityType parameter defaults to COMPARE (data); use COMPARE_METADATA for a metadata compare.

1{
2  "tool": "create_compare_activity",
3  "parameters": {
4    "fromBackupId": "0Bh000000000001",
5    "toBackupId": "0Bh000000000009",
6    "objects": ["Account", "Contact"],
7    "activityType": "COMPARE"
8  }
9}

Mutating (overwrites the prior selection) and idempotent. Updates which records are selected for restore on a COMPARE activity through batch filter and change expressions. When multiple batches match the same record, the last matching batch wins. The only supported change is fieldName=selectedForRestore with a value of true or false. Re-applying the same payload is idempotent. Passing a RESTORE activity ID returns HTTP 422.

1{
2  "tool": "update_selection_records",
3  "parameters": {
4    "activityId": "<compareActivityId>",
5    "objectName": "Account",
6    "batches": [
7      {
8        "filterExp": [{ "fieldName": "Industry", "operator": "EQUALS", "value": "Technology" }],
9        "changeExp": [{ "fieldName": "selectedForRestore", "value": "true" }]
10      }
11    ]
12  }
13}

The recover tools are designed to be used in sequence. The MCP surface guides a restore up to the selection step; the restore itself runs on the non-MCP surface.

1. Create a compare with create_compare_activity to diff two backups. Capture the returned activityId.
2. Poll the compare with get_compare_activity, then read per-object change counts with get_compare_activity_summaries.
3. Update the selection with update_selection_records to mark records for restore.
4. Confirm the selection counts with get_selection_counts_by_type and get_restore_activity_record_selection_metadata before you restore.

Executing the restore is intentionally not an MCP tool. After you confirm the selection, trigger the restore through the product UI or another non-MCP surface. After a restore runs, review the results with the recover read tools, such as get_restore_activity, get_restore_activity_summary, and get_restore_activity_object_results.

• No destructive tools. Abort backup, upsert policy, and create retention rules aren’t exposed. There’s no MCP confirmation primitive to gate them safely, and narrowing retention or overwriting policy can cause delayed or immediate data loss, so these operations stay off the MCP surface.
• No restore execution, retry, or download. Restore execute, retry, download, and the legacy bulk selection edit aren’t registered for this milestone. The MCP surface guides a restore up to the selection step; execution happens on the non-MCP surface.
• Asynchronous operations and a 30-second response budget. The enqueue_backup and create_compare_activity tools return immediately and don’t wait for completion. Poll for long-running state with get_backup_by_id, get_compare_activity, and get_restore_with_hierarchy. Tools don’t block on a single long-running request.
• The selection tool is COMPARE-only. The update_selection_records tool supports COMPARE activities only. Passing a RESTORE activity ID returns HTTP 422.
• update_selection_records overwrites. It overwrites the prior selection (last matching batch wins) and supports only selectedForRestore=true|false. It’s idempotent, but not marked destructive, because the selection overlay is preview state, not customer data.
• The object scope of enqueue_backup is policy-driven. It runs the configured policy (available in the get_latest_policy tool) and doesn’t let the caller choose objects.

Every Salesforce Hosted MCP transaction runs as the authenticated user, scoped through an External Client App. Object permissions (CRUD), field-level security (FLS), sharing rules, profile permissions, and permission sets all apply. If you can’t perform an action in Salesforce, your agent can’t perform it through the MCP server. The audit trail attributes every action to you.

This server takes a defense-in-depth approach to the restore workflow: every destructive operation is kept off the MCP surface, and the additive and update-selection tools are annotated so that clients can gate them. As a best practice, configure your MCP client to require your approval before it runs a tool that changes data, such as enqueue_backup, create_compare_activity, and update_selection_records.

The Backup and Recover server follows the same practices that apply across all Salesforce Hosted MCP servers. For full guidance, see Security Best Practices and General Best Practices in the guides.

• Standard MCP Servers Reference
• Salesforce Hosted MCP Servers on GitHub