Best for
- Teams that want precise control over which database operations an AI can perform, rather than open arbitrary SQL execution
- Scenarios needing a unified MCP setup across multiple database engines
M
MCP Toolbox for Databases
Official
Google's official database MCP toolbox — define AI-accessible database tools via config
GitHub source repository ↗
74FMRS · B
Source and config reviewed
Officially maintained by Google; the config-driven design allows finer-grained permission control than a fixed-tool-list database MCP, but security depends heavily on how tools.yaml is written. The tool list varies by configuration, so no fixed tools field is listed. This review is a static check of source and docs, not an actual connection test.
Read the scoring and verification method →An open-source MCP server officially maintained by Google for connecting AI assistants to databases. Unlike database MCP servers with a fixed tool list, MCP Toolbox is config-driven: a `tools.yaml` file defines exactly which SQL queries are exposed as tools (name, parameters, SQL statement), grouped into toolsets. It also ships ready-to-use `--prebuilt=<database>` toolsets (e.g. postgres/mysql) for a quick start without hand-writing config.
Tools
The tool list has not been reviewed yet.
Setup
1) Quick start: `npx -y @toolbox-sdk/server --prebuilt=postgres --stdio` with the matching database connection env vars gives you a prebuilt tool set.
2) Custom: write a `tools.yaml` defining specific SQL tools and toolsets, run the Docker image `us-central1-docker.pkg.dev/database-toolbox/toolbox/toolbox` in Streamable HTTP mode with the config file mounted.
claude_desktop_config.json
{
"mcpServers": {
"toolbox-postgres": {
"command": "npx",
"args": ["-y", "@toolbox-sdk/server", "--prebuilt=postgres", "--stdio"]
}
}
}
Fit and risk
Not for
- Lightweight cases that just want to run a few ad-hoc SQL queries without maintaining a tools.yaml config (a simpler single-database MCP may be a better fit)
Required permissions
- Database credentials (username/password/connection string) are supplied via env vars or config
- A tool's actual permission is whatever SQL statement is defined in tools.yaml — designed for least privilege, but misconfiguration can still over-expose access
Risks and side effects
- If tools.yaml defines SQL statements that allow unconstrained writes or deletes, the AI could accidentally modify data
- The prebuilt toolsets (--prebuilt) favor convenience and may expose broader query capability than a specific business actually needs — use a custom tools.yaml in production
Troubleshooting
- Prebuilt toolset fails to connect: check that the matching database's env vars (e.g. connection string) are set correctly
- Custom config not taking effect: confirm the path passed to --config or --config-folder is accessible inside the container
- Streamable HTTP connection times out: check port mapping and firewall settings
Use cases
Let an AI assistant run pre-reviewed, read-only queries instead of executing arbitrary SQL
Define different-permission toolsets for different agents/apps
Provide one unified AI access point across multiple database types (Postgres, MySQL, SQLite, etc.)
Supported clients
Claude CodeFull support
Gemini CLIFull support
ZedFull support
AntigravityFull support