BetterDB MCP
BetterDB Monitor
BetterDB MCP server: the agent reads Valkey and Redis metrics, slow commands, hot keys and anomalies and investigates incidents from stored history
- 1,311 ★ on the repository
- Last commit
Broad access
Why this level
- `add_connection` and `test_connection` take database login details, and `remove_connection` deletes connections
- `cache_approve_proposal` applies a threshold or time-to-live change to a production Valkey immediately
- Slow command and client logs reach the agent's chat with whatever they record
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add mcp/betterdb-monitorDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- `add_connection` and `test_connection` take database login details, and `remove_connection` deletes connections
- `cache_approve_proposal` applies a threshold or time-to-live change to a production Valkey immediately
- Slow command and client logs reach the agent's chat with whatever they record
This is third-party code. Review the repository files before installing.
What it does
The `@betterdb/mcp` server connects an agent to BetterDB Monitor, which stores the history of Valkey and Redis: the slow command log, client activity, latency and access control events. The agent picks a database with `list_instances` and `select_instance`, and `get_health` returns a status summary: memory fragmentation, hit rate, replication lag and client count. From there it reads `get_slowlog` and `get_commandlog`, hot keys through `get_hot_keys` and cluster nodes through `get_cluster_nodes`. The server has 60 tools in several groups. Analytics projects when memory, operations per second or CPU will hit a ceiling. The vector search group shows index health and `FT.SEARCH` latency. The group for AI application observability lists OpenTelemetry traces and correlates them with the live database state. Connection tools let the agent add, test and remove database connections. A separate group works with semantic and agent caches. The agent proposes a threshold or time-to-live change, and the proposal stays advice until it is confirmed through `cache_approve_proposal`.
Who it is for. For developers and operations engineers who run Valkey or Redis in production and want to investigate slow queries and uneven load straight from Claude Code or Cursor.
Good fit when
- Latency rose overnight and the log on the database itself has already been overwritten: the monitor keeps the slow command history
- One cluster node carries more load than the others, and you need to find it and its hot keys
- You want to know how many days until memory or CPU hits a ceiling: `get_forecast` covers it
- You need to investigate failed logins and client access through the access control audit log
- An AI app's semantic cache misses often, and you want to see why from traces and the similarity distribution
Not a fit when
- You need to read and change the data inside keys: `redis-mcp-server` handles strings, hashes, streams and JSON
- The database is older than the supported versions: the monitor targets Valkey 8.0 and newer and Redis 6 and newer
- You can neither run a monitor nearby nor connect a cloud one, because the server shows nothing without it
- You need anomalies, latency regressions or the largest keys and the Pro tier is not enabled
Example request
Connect to BetterDB and tell me which commands were slowest in the last hour and whether our production Valkey has any hot keysMCP
- Transport
- stdio
- Authentication
- key is optional
Environment variables
BETTERDB_URL- Monitor address, `http://localhost:3001` by default
BETTERDB_TOKENsecret- Token from Settings, MCP Tokens: required in the cloud, optional when self-hosted
BETTERDB_INSTANCE_ID- A preselected database so `select_instance` is not needed
BETTERDB_TELEMETRY- The value `false` turns off sending records of tool calls
Limitations
- The server measures nothing itself: it needs a running BetterDB Monitor, cloud or self-hosted, or the `--autostart` flag, which makes the server start a monitor on its own. Node.js 20 or newer is required.
- Some tools belong to the Pro tier: anomalies, latency regressions, the largest keys and SLA breach fields. The monitor gives some of these away free during early access.
- On a self-hosted monitor without a token, the read tools work anonymously, and writing needs an admin token. A token is mandatory in the cloud. Tokens cannot manage members or other tokens.
- Every tool call sends the monitor a record with the tool name, success, duration and error. The `BETTERDB_TELEMETRY=false` variable turns it off.
- The `@betterdb/mcp` package is MIT-licensed. In the main repository the `proprietary/` directory has its own license and the documentation is CC BY-SA 4.0.
How to disable. Remove the `betterdb` entry from the client's MCP settings, and in Claude Code run `claude mcp remove betterdb`. A monitor started with `--persist` keeps running: stop it with `npx @betterdb/mcp --stop`, or stop the container with `docker stop betterdb`.
FAQ
How do I connect the server to Claude Code and my own monitor?
Add an entry with the command `npx`, the argument `@betterdb/mcp` and the `BETTERDB_URL` variable. For the cloud the address looks like `https://<your-workspace>.app.betterdb.com` and a token from Settings, MCP Tokens is required. A self-hosted monitor does not need one.
What does the `--autostart` flag do?
The server starts and manages a local monitor itself. `--persist` keeps the monitor running after exit, `--port` changes the port, `--storage` picks `sqlite` or `memory`, and `--stop` stops a monitor started earlier.
What does `get_forecast` predict?
The tool projects four metrics: `opsPerSec`, `usedMemory`, `cpuTotal` and `memFragmentation`. The result includes the estimated time to reach the ceiling.
Can the agent change cache settings on its own?
The `cache_propose_*` tools only create a proposal and write nothing to Valkey. The change is applied when `cache_approve_proposal` confirms it. A proposal can be rejected, or its value edited at approval with `cache_edit_and_approve_proposal`.
Is plain Redis supported?
Yes, Redis 6 and newer. The monitor detects the database type from the `INFO` response. `get_commandlog` and `get_slot_stats` work only on Valkey 8 and newer.
Where does the monitor keep its history?
The first-run wizard picks the storage: SQLite, PostgreSQL or memory. Settings are saved to `~/.betterdb/config.json`.
Discussion
No questions or reviews yet.
Related
MCP serversDatadog's official managed MCP server: logs, metrics, traces and incidents right in your agent
A single-container web dashboard for monitoring and controlling a fleet of 1C MCP servers: status, indexing progress, VRAM and license checks
An MCP server for Prometheus: the agent runs PromQL queries, discovers metrics and checks scrape targets
Grafana MCP Server
Grafana MCP server
Grafana's official MCP server: dashboards, Prometheus and Loki queries, alerts and incidents straight from the agent
Self-hosted MCP server for running commands on remote servers over SSH, with tokens and roles
An agent runs servers through a catalog of declared actions: policy decides what runs and what waits for a person
README in short
The repository front page is about the monitor itself: a quick start through Docker, Helm and `npx`, the feature list, a table of interfaces (web, MCP, Prometheus, REST), supported databases and environment variables for production. The MCP server has its own page in `packages/mcp` with client setup, variables, arguments and tables of all tools by group. The repository contains the monitor source, API tests, a Helm chart, documentation and a benchmark.