How to connect Claude, Cursor or Codex to Ivory and let an AI agent troubleshoot PostgreSQL, Redis, MongoDB and more — safely, under your own permissions
It's 3 a.m. Your phone buzzes: replication lag on prod.
You know the drill. Open the laptop. SSH into the first node. patronictl list. Open psql on the leader. Query pg_stat_replication. SSH into the replica. top. df -h. tail the log. Back to the leader. Is something holding a lock? Another query. Copy a PID. Five terminals later, you finally have a picture of what's going on — and you're wide awake for the rest of the night.
Now imagine you type one sentence instead:
"Why is the replica in prod lagging?"
…and an AI agent checks the cluster, reads the lag, looks at the replica's machine, runs the right diagnostic query on the leader and tells you: a long-running transaction on the leader is holding back replay; here's its PID — do you want me to cancel it?
That's what Ivory does now. Let me show you how.
The idea: don't give your AI the keys — give it Ivory
You could give an AI agent SSH access and a database password. Please don't. 🙂
It would have every secret in its context, no idea which cluster is which, and no limits at all — DROP TABLE is just as easy to type as SELECT.
Ivory is an open-source tool to deploy, watch and fix database clusters — PostgreSQL with Patroni, plain PostgreSQL, etcd, Redis, ClickHouse, MongoDB and ZooKeeper. Since v2.1.0 it has a built-in MCP server (Model Context Protocol, the standard way AI agents call tools). So instead of raw access to your infrastructure, the agent gets Ivory:
- It already knows your clusters. Names, nodes, roles, which engine, which keeper — no need to explain your topology.
- It sees only what you allow. An agent sees only the tools its user has permission for. No permission for a switchover? The switchover tool doesn't even exist for it.
- Secrets never pass through it. Passwords and SSH keys stay in Ivory's vault. The agent refers to them by id and never sees them.
- Dangerous tools are labelled. Read-only tools are marked read-only, destructive ones are marked destructive, so your client asks you before running them.
"Show me all active queries" — the agent checks six Postgres nodes, finds a long pg_sleep on one replica and offers to cancel or terminate it
Set it up in two minutes
1. Run Ivory (skip this if you already have it):
docker run -p 80:80 --restart always veegres/ivory
2. Generate a token. In Ivory, open Settings → Integrations → MCP Server. Pick how long the token should live — 1 hour, 6 hours, 1 day, 15 days or 30 days — and press generate.
3. Copy the config for your client. The same screen has a ready-made config for Claude Code, Cursor, VS Code, Codex, Antigravity, IntelliJ IDEA and Claude Desktop, with the endpoint and token already filled in. For Claude Code it's one command:
claude mcp add --transport http ivory http://localhost/api/mcp \
--header "Authorization: Bearer $TOKEN"
That's it. Ask your agent "What clusters do I have in Ivory?" to make sure it works.
10 things to ask your cluster
Here's where it gets fun. These are real prompts that work today, and what the agent does behind the scenes.
1. The morning check
"Check all my clusters and tell me if anything needs attention."
The agent lists every cluster and reads each one's overview: roles, states, lag, pending restarts and warnings. You get one short summary instead of clicking through every cluster. My favourite way to start the day.
2. Why is my replica lagging?
"Why is replica 2 in prod lagging?"
It reads the lag (in the engine's own unit — bytes for Postgres, seconds for Redis and MongoDB, Raft entries for etcd), checks the replica machine's CPU, memory and network, and runs the replication queries on the leader.
3. What is blocking my queries?
"What is blocking queries on the prod leader? Don't kill anything, just explain."
It looks at the active queries and locks and points to the blocker. When you're ready: "Cancel it" — and it uses ivory_query_cancel, or ivory_query_terminate if cancel isn't enough.
4. Is it down, or can I just not reach it?
"Node patroni3 is red. Is it actually down?"
ivory_cluster_check tests every node at once — keeper, machine and database connections — and tells you whether it breaks at the vault, the certificate or the network itself. That's the difference between "the database crashed" and "someone rotated the password".
5. Read the logs for me
"Show me the last errors in the logs of the etcd leader container."
It pulls the last lines of the container log — or any log file on the machine — and summarizes what matters. No ssh, no docker logs, no scrolling.
6. Is the machine OK?
"Is anything else eating CPU on the mongo2 host?"
The agent reads the machine's metrics and process list over SSH, through Ivory. Great for the classic "it's not the database, it's the backup job running on the same box".
7. A planned switchover, done carefully
"I want to switch the leader to node 3. Check that it's healthy and caught up first, then ask me before doing it."
It checks lag and state, explains what will happen, and waits for your go. Ivory even supports scheduling a switchover for later on Patroni: "…and schedule it for 2 a.m."
8. Explain a warning
"Ivory shows a warning on clickhouse2. What does it mean and how do I fix it?"
Ivory has two kinds of warnings: its own (a node that isn't in the cluster, lag past the threshold, an unreachable node) and the ones the engine reports itself (etcd alarms, failed MongoDB heartbeats, stuck ClickHouse replication tasks). The agent knows which is which and explains both.
9. Run the right diagnostic query
"Run the table bloat query on the analytics database and tell me the top 5 tables."
Ivory ships saved diagnostic queries for every engine. The agent can find the right one and run it, so you don't have to remember which pg_stat_* view to join with which.
10. Spin up a test cluster
"Deploy a test Redis cluster on 10.0.0.4 from the single-host template. Use the 'test-ssh' vault for SSH and the 'redis-test' vault for the password."
The agent picks the template and deploys all three nodes — then reports how each node's deploy and initialize steps ended. Credentials are always named by vault, never typed into the chat, so no password ever lands in the agent's context.
Keep it safe: the 3-rule setup
Giving an AI agent power over production deserves a moment of thought. Here's how I set it up:
Rule 1: Give your agent its own user. Create a user in Ivory just for your agent and grant it only view.* permissions. It can diagnose everything and change nothing — the tools that change something simply won't appear in its list. When you need it to act, use a different user with the manage.* permissions you're comfortable with.
Rule 2: Use short-lived tokens. Tokens can't be revoked: Ivory doesn't store them, so a token stays valid until it expires. A 1-hour token for an incident, a 1-day token for a working session. Treat a 30-day token like a password you can't change for a month.
Rule 3: Keep the approval prompts on. Most MCP clients ask before running a tool, and Ivory marks the dangerous ones as destructive. Read before you click "allow" — especially for failover, reinitialize, removing a container and the raw query console.
Some things an agent can never do through Ivory, whatever its permissions: erase data, export backups, or manage vaults, certificates, users and permissions. An agent should never be able to widen its own access.
Tips for better answers
- Name the cluster. "Prod" is better than "my database".
- Ask it to explain before it acts. "Diagnose, don't fix" is a great default.
- Ask for the evidence. "Show me the query you ran and the numbers" keeps the answer honest.
- Chain it. "Check all clusters, then dig into the worst one" works surprisingly well.
Bonus: let AI add your favourite database
Ivory's engines are plugins. If your database isn't supported yet, the repository ships a Claude Code agent called keeper-database-plugin that writes a new plugin — both halves, the tests and the UI wiring — following the project's own checklist. Then open a pull request. 🧩
The point
AI won't replace knowing your databases. But it removes the boring part — the five terminals, the copy-pasted PIDs, the "which host was the leader again?" — and leaves you with the decision. And because it works through Ivory, it does that with exactly the permissions you gave it and nothing more.
Next time your phone buzzes at 3 a.m., try asking first. 😉
If you like the idea, give Ivory a ⭐ on GitHub — it really helps.
Useful links:
Top comments (1)
The "give your AI the keys" anti-pattern is exactly why most teams are terrified of giving agents production access. The permission-scoping approach here is brilliant—if the agent's user only has view.* permissions, the destructive tools literally don't exist in its context. That's the right way to build an MCP server.
The "tokens can't be revoked" caveat is a bit scary, though. Relying on short expiry (1-hour incident tokens) is a smart workaround, but it means if a token leaks, you're in trouble until the clock runs out.
Have you considered adding token revocation to the roadmap, or is the architecture intentionally stateless to avoid storing tokens?