Cloudback MCP Server - Manage your backups from Claude, Cursor, and VS Code

@harshchandgotia Two good questions.

Guardrails: the main one is that the MCP server only manages configuration - it never runs backups, restores, or touches backup data. On top of that, every call is scoped to one account (one API key each), bulk edits have no wildcard (the assistant lists the exact definition IDs first, and unknown IDs are rejected), schedule, storage, and retention are set by name not raw ID, and every write is a tool call your client approves before it runs. All changes land in the audit log.

What we left out on purpose: restore, on-demand backup runs, and deleting backup definitions - the irreversible ones stay in the dashboard behind a human. Same for creating storage, which means handling credentials, and creating or deleting retention policies - the assistant can apply existing named policies, not invent or remove them. Read freely, edit config safely, and keep restore and anything that touches backup data out of chat.

@romeo_ciobanu Appreciate it - the "compounds over time" point is exactly the bet. On Bitbucket: it's not in Cloudback today, so it's not in the MCP surface yet either (the server covers what Cloudback backs up - GitHub, GitLab, Azure DevOps, and Linear). The upside is the MCP server rides on top of that platform support, so the day Bitbucket lands it shows up here automatically. Noted the ask - real demand like this is what we weigh when picking the next platform.

@blah_mad Good question, and the right risk to poke at. Bulk changes aren't a wildcard. The assistant has to pull the exact definitions first, so you see the current settings and which IDs will change, and update only touches those IDs. Each call is scoped to one account, and the apply is a normal MCP tool call your client surfaces for approval - with the account, IDs, and new values - before it runs. And every change lands in Cloudback's audit log, so there's a full record of what was applied, when, and by whom. A one-step before/after diff across all definitions isn't there yet - today that view comes from the List call before the write.

@tang_weigang This is exactly the right framing, and most of that list is how it's already built. Read-only inspection and mutating tools are separate, every call is scoped to one account with bulk edits limited to explicit definition IDs (no wildcard), and your client shows each write - account, IDs, and new values - for approval before it runs. Every change lands in the audit log with what was touched and when. On restore and delete specifically: those aren't exposed through MCP at all. The server only manages configuration - it can't restore, run, or delete backup data. The irreversible actions stay in the dashboard behind a human, which is the "useful but never casually powerful" line you're drawing.

@vidur_saini Thanks - that's exactly the surface we built it for. It's early, so we won't pretend we have usage stats yet, but by design it leans inspection-first: you have to list the definitions before you change them, so people naturally start with "what's not backed up?" or "which repos have no retention policy?" The bulk config changes are the payoff once they spot the gap.

@anand_thakkar1 Thank you for the question! We use API keys for each account you connect to MCP.

@yannikga Listing the definitions first is really enough here - you see the exact set and count before anything runs, so the scope is whatever you filtered, not a guess. And a wrong scope can't run away: each account has its own API key, so a bulk change only ever touches that one account. On top of that, Cloudback sends instant backup-status notifications - so if a change ever left a backup failing, you'd know right away, not at edit time.