ugurcl/dbridge-mcp

An MCP server that lets an AI agent query a SQL database in plain language — safely and read-only.
=22.5">
The agent discovers the schema on its own (list_tables, describe_table), then writes and runs a SELECT for whatever the user asks. No hand-written endpoint per question.
Works with **SQLite**, **PostgreSQL**, and **MySQL / MariaDB**.
Why
A raw LLM cannot know what is inside your database, and web search cannot reach private data. dbridge gives the model a guarded door to that data: it can read and answer, but it cannot write, drop, or leak the whole table.
Why dbridge and not another database MCP?
There are many database MCP servers. dbridge is built around one idea — **you should be able to point an AI at a real database without holding your breath** — and that shows up as a combination the single-engine servers don't offer:
- **One server, three engines.** SQLite, PostgreSQL, and MySQL/MariaDB behind the same tools and the same config. Switch databases by changing the connection string, not the tooling.
- **Read-only twice over.** A SQL guard rejects anything but SELECT/WITH *and* every query runs inside a database-enforced READ ONLY transaction — so even a query that outsmarts the guard cannot write.
- **Column-level privacy.** Hide columns from the model entirely, or mask values (a***@site.com) while keeping them queryable. Most servers expose whatever the connection can see.
- **Blast-radius controls.** Row caps enforced over user-supplied LIMITs, per-query timeouts, EXPLAIN-based cost rejection for expensive queries, per-minute rate limits, and a capped connection pool.
- **No native build step.** SQLite uses Node's built-in node:sqlite, so npx -y dbridge-mcp works without a compiler toolchain.
- **Performance insight, not just queries.** column_stats and index_health give the model real cardinality and index-usage data, and test_index simulates an index with hypopg before anyone builds it — so the model's optimization advice is grounded in the actual database instead of guesswork.
If all you need is "run SQL from my agent", plenty of servers do that. dbridge is for pointing an agent at data you actually care about.
Tools
| Tool | Purpose |
| --- | --- |
| list_tables | List every table in the database. |
| describe_table | Return a table's columns, primary key, foreign keys, and row-count estimate. |
| sample_table | Preview the first rows of a table (json/csv/markdown). |
| count_rows | Return the exact row count of a table. |
| run_query | Run a single read-only SELECT / WITH and return rows as json, csv, or markdown. |
| explain_query | Return a query's plan and estimated cost without running it. |
| column_stats | Per-column distinct-value counts and null fractions — is this column selective enough to index? |
| index_health | List indexes with sizes and scan counts, flagging unused, duplicate, and invalid ones. |
| test_index | Simulate a CREATE INDEX without building it and report whether the planner would use it (PostgreSQL, via hypopg). |
| slow_queries | The most expensive recorded statements with call counts and timings (PostgreSQL pg_stat_statements, MySQL performance_schema). |
| get_limits | Report the safety limits in effect (caps, timeouts, hidden/masked columns). |
Resources
| Resource | Purpose |
| --- | --- |
| dbridge://schema | The full schema (every table and its columns) as one JSON document. |
Prompts
| Prompt | Purpose |
| --- | --- |
| optimize | A guided optimization pass: find slow queries, inspect plans and index health, and validate every index recommendation with test_index before suggesting it. |
Requirements
Node.js 22.5+ (SQLite uses the built-in node:sqlite, no native build step).
Install
The published package ships a dbridge-mcp binary, so no clone or build step is needed to use it. Point it at a database with the connection argument: