Run Your Whole Database Fleet From the Chat, Safely

For a long time the smart move was to keep the LLM far away from production infrastructure. Not because the model was dumb, but because the blast radius was unbounded. Hand an assistant a shell and a database password and the worst case is not a bad suggestion, it is a confident DROP TABLE. So we built the thing that makes the worst case impossible, and then we handed your assistant the keys.

FoundryDB's MCP server now ships 24 tools, enough to run a service from creation to deletion without ever leaving the chat. Provision a PostgreSQL cluster. Take a backup and check the recovery window. Pull your slowest queries, ask the advisor for an index, and apply it. Scale storage, add a replica, set a maintenance window. The whole operational story, spoken to your assistant in plain language. The reason you can actually trust it with that is a three-layer safety model that sits under every single tool: agents propose, the platform brokers, and the destructive paths refuse to fire on a guess.

What you can build now

Connect the server from Claude Code, Claude Desktop, or Cursor and your assistant becomes a fleet operator. The 24 tools map cleanly onto the things you actually do:

• Provision and inspect. create_service (with presets, plus TTL and ephemeral options for throwaway environments), then list_services, get_service, get_service_nodes, get_task_summary, get_metrics, and get_logs to see everything that is running.
• Users and access. list_users, reveal_password, get_connection_string, so the assistant can wire an app up without you copy-pasting credentials.
• Backups and recovery. trigger_backup, list_backups, get_pitr_range, restore_service, list_restore_jobs. Point-in-time recovery is one conversation away.
• Performance. get_query_stats pulls the top queries from pg_stat_statements, list_index_recommendations surfaces the advisor's suggestions, and apply_index_recommendation ships the index for you.
• Scaling and maintenance. scale_service, add_replica, remove_replica, get_maintenance_window, set_maintenance_window, list_pending_advisories.

Picture the workflows this unlocks. "Show me the slowest queries on orders-prod and recommend indexes" is a read-only round trip that changes nothing. "Back up orders-prod before the migration" surfaces the action for you to approve, then runs. "Provision a throwaway PostgreSQL 17 with a 24-hour TTL" spins up a clean environment that cleans itself up. The chat is now a control plane.

The safety model is the feature

Tool count is easy. The hard part, and the part we are proud of, is that none of these tools can hurt you. Three independent layers make sure of it.

Tier one: nothing mutates by accident. Every tool classifies itself, and the check runs before a single byte reaches the FoundryDB API. Read-only tools are unrestricted, look at anything you want, as often as you want. Mutating tools like create_service, trigger_backup, and scale_service require an explicit confirm=true. The assistant cannot quietly set that flag and proceed, because a call without it comes back as a refusal, not an action. That forces the model to surface the move to you in plain language first. The destructive tools, delete_service and restore_service, go further: they require typing the exact service name, the same pattern you already trust for deleting a repository. A near-miss, a confident hallucination of the name, all of them abort with zero side effects.

Tier two: the platform brokers, the model never writes SQL. There is no run_query. There never will be. The cleanest example is apply_index_recommendation: the assistant does not author the DDL, it passes a single recommendation UUID. The platform looks up the stored recommendation, composes the CREATE INDEX CONCURRENTLY statement itself, and runs it through an audited, typed task on the primary. The model picks which recommendation to apply from a vetted list. It does not get to decide what SQL runs. The worst a confused model can do is apply the wrong index from a safe menu, not invent a statement that locks a table.

Tier three: scoped tokens the platform enforces below the server. Tokens carry scopes like services:read, backups:write, and services:admin, ordered read < write < admin and mapped from HTTP methods. Hand your assistant a read-only token and every mutation comes back as a 403 that names the missing scope, no matter what the model tries, no matter whether it set confirm=true. Authorization does not live in the assistant, so the assistant cannot talk its way past it. And every call, allowed or denied, lands in your organization's audit log with the route name and status code. You can reconstruct exactly what your assistant looked at and what it changed.

The three layers are independent on purpose. Tiers stop accidents. Brokering stops arbitrary SQL. Scopes stop everything else, including a compromised or buggy client, because the platform enforces the token regardless of what that client claims.

We ran the whole loop, start to finish

This is not a thought experiment. We drove a full lifecycle from Claude Code on a single service: provisioned a PostgreSQL 17 instance to Running in about 8 minutes, took a backup and confirmed the PITR window opened, seeded traffic and pulled the top queries by total execution time, asked the advisor for index recommendations, applied one through the brokered path and watched it appear in pg_indexes, expanded storage, then deleted the service with the typed-name confirmation. Every step landed in the audit log with its route and status. The index was created by the platform from a recommendation UUID, never by SQL the model wrote.

One command to get started

Add the server to Claude Code and point it at a scoped token:

claude mcp add foundrydb \
  -e FOUNDRYDB_API_URL=https://api.foundrydb.com \
  -e FOUNDRYDB_TOKEN=YOUR_SCOPED_TOKEN \
  -- foundrydb-mcp

A token is the right way to authenticate because it is scope-restricted. Grant it to taste: services:read plus backups:read to observe only, add the write scopes to operate, or admin for full control including delete and restore. One detail worth holding onto: backup, restore, and PITR live in the backups scope family, separate from services. A token with services:admin but no backups scope can delete a service yet cannot trigger a backup, so grant both families deliberately.

Honest about the edges, excited about the direction

We are deliberate about what we did not build. No SQL execution tool, no escape hatch, no way for the model to author free-text statements against your data. That is a choice, and it is the right one. As the tool surface grows, the rule will not change: every mutation goes through a typed task with a known shape, and authorization is enforced by the platform, not the client. The safety model is the product, and it scales with it.

The MCP server is available today. The canonical source is published as foundrydb-mcp at github.com/foundrydb/foundrydb-mcp. Add it to your assistant with a read-only token, point it at a service, and watch how far it gets before the platform stops it. Then loosen the scopes when you are ready to let it operate. Your database fleet just got a new operator, and it cannot break things on a guess. Go run something.