SimpleBackups MCP: Your Backups in Your AI Assistant

A backup fails at 03:00. The alert reaches Slack, and the person who reads it first opens the dashboard, finds the job, opens the run history, reads the error, decides whether it is the database or the tunnel, and then goes looking for the last run that worked. That sequence takes ten minutes on a good day, and most of it is navigation rather than thinking. The SimpleBackups MCP server collapses it into one question, asked in the tool you already have open.

It is out of private beta today and open to every SimpleBackups account.

What the MCP server actually is

The Model Context Protocol is an open standard for letting AI assistants call tools in external systems. An MCP server publishes a set of tools; a client such as Claude, Cursor, or Codex discovers them and calls them on your behalf.

Ours is a remote server, so there is nothing to install and nothing to keep updated. You point your client at https://mcp.simplebackups.ai/mcp, approve an OAuth prompt in your browser, and your assistant gains a set of tools scoped to one team in your account. Authentication is OAuth 2.1 with Dynamic Client Registration, so there are no API keys to paste into a config file and no tokens sitting in your dotfiles.

The tools cover four jobs: seeing the state of your backups, understanding why one failed, controlling when runs happen, and preparing a restore.

Connect the MCP server to Claude, Cursor, or Codex in a minute.

Read the installation guide →

What you can do with it

The plain version is that you ask, in words, for the thing you would otherwise click through five screens to find.

See the state of everything. get-backups-overview returns account health in a single call: how many backups exist, how many are failing, which ones have gone quiet. get-backup-runs-timeline builds a per-day status grid across many backups at once, which is the view nobody wants to assemble by hand when an auditor asks for thirty days of evidence.

Any backups failed in the last 7 days?

Draw me a status grid of all my production backups for the last 14 days.

Investigate a failure properly. find-failing-backups narrows to what broke, get-backup-logs returns the run history, and get-run-output pulls the actual stdout and stderr from the run so the assistant reads the same error you would read on the server.

Why did backup #28491 fail last night? Show me the error.

Has this one failed before, or is tonight the first time?

Manage sources and destinations. list-servers and list-storages return your connected servers, databases, and storage destinations with their connection status and usage. No credentials are ever returned. Storage access keys, SSH private keys, and database passwords stay inside SimpleBackups.

Control when runs happen. run-backups triggers on-demand runs, pause-backups and resume-backups handle the maintenance window you did not plan for. All three ask you to confirm before they execute.

Trigger the staging database backup now, I'm about to deploy.

Pause every MySQL backup for the next hour, I'm doing maintenance.

Prepare a restore. restore-prep assembles the restore for a given run and returns instructions specific to that backup type. The server prepares; you run the commands. We deliberately did not build a tool that lets a model restore over a live database on its own.

MCP or the API: which one is for what

We already have a REST API, and the MCP server does not replace it. They answer different kinds of question.

	REST API	MCP server
Shape of the work	Deterministic, repeated, written once	Conversational, exploratory, different every time
Who calls it	Your CI pipeline, your onboarding script, your cron	You, through an AI assistant
Typical use	Trigger a backup before every deploy	Work out why last night's backup broke
Auth	Bearer token you manage	OAuth 2.1, no keys to store
Failure mode you care about	A 500 in a pipeline	A wrong answer in a chat window

A rule of thumb that has held up: if you would write it down as a runbook step, use the API. If the runbook step is "investigate", use the MCP.

The two also compose. Your pipeline triggers backups through the API on every deploy, and when one of those runs goes red, you ask your assistant what happened.

The private beta, and what it changed

We ran the MCP server as a private beta for several months before opening it up, which was the right call, because the most useful thing we shipped came out of it.

Nicolai at Peanut App reported that when a backup failed, his assistant could see that it failed but not why. The error excerpt the server returned was an internal bookkeeping string, not the error the backup process had actually produced. Technically correct, practically useless: you learned there was a problem and then went to the dashboard anyway.

We shipped get-run-output in response. It fetches the real stdout and stderr lines from the run. In Nicolai's case the answer turned out to be a typo in a Postgres pre-script:

ERROR: column "pg_wal_replay_pause" does not exist

One line, sitting in the output the whole time. The difference between an assistant that says "this backup is failing" and one that says "this backup is failing because your pre-script calls a column that does not exist" is the difference between a tool you check and a tool you trust.

That is the part of a private beta that matters. Not the sign-ups, the moment somebody tells you the thing you built is answering the wrong half of the question.

Two of our beta users offered to say something publicly:

"We used the Simple Backups MCP to troubleshoot a pesky backup that kept failing. It helped uncover a configuration issue that we made. It would have taken way more time to troubleshoot this issue without the MCP."

Jason Siffring, Owner, Surprise Highway

"The SimpleBackups MCP integration makes debugging failed backups incredibly fast. Getting the exact error reason directly within the AI assistant saves us a lot of time when troubleshooting."

Nicolai Dalsgaard, Peanut App

Both describe the same job, and it is the one we optimized for: shortening the distance between a failed run and the reason it failed.

What it will not do

Backups are the thing you fall back on when everything else went wrong, so an AI assistant with a connection to them needs clear limits. Ours are:

• No credentials leave SimpleBackups. Not to the client, not to the model, not in any tool response.
• No delete tool exists. Nothing exposed over MCP can remove a backup, a run, or a stored archive.
• No unattended writes to your data. Restores are prepared and handed to you as instructions. The server never runs them against your database.
• Actions confirm first. Triggering, pausing, and resuming all prompt you before they execute.
• One team per connection. A token is scoped to a single team, and you revoke any connection from Settings, MCP in your dashboard.

Connecting it

Claude Code takes one command:

claude mcp add --transport http simplebackups https://mcp.simplebackups.ai/mcp

Then start Claude Code, type /mcp, and approve the browser prompt.

For Claude Desktop and claude.ai, add a custom connector under Settings, Connectors, and paste the same URL. Cursor and Codex take the URL too, as does any client supporting the streamable-http transport. The per-client steps are in the MCP server documentation, and the full tool reference is in the API docs.

Try it

If you already run backups with us, connecting takes about a minute, and the first question worth asking is the boring one: anything failing right now? You will either get a reassuring answer or find something you did not know about, and both are useful. The MCP server page covers what it does and the scenarios it handles.

We are still shaping this. get-run-output exists because one person told us what was missing, and the same door is open now that everyone can use it.

FAQ