dbx

What It Does

dbx is a cross-platform database client (desktop, Docker, web, CLI) written in Rust, supporting 70+ databases from a single 20 MB binary with no Java runtime and no bundled Chromium. For AI agents it ships two relevant surfaces: a Model Context Protocol server (@dbx-app/mcp-server, a small Node launcher over a platform-specific Rust binary) and a CLI skill (skills/dbx/SKILL.md for @dbx-app/cli). The MCP server exposes 12 tools that let a coding agent list connections, browse tables, describe schemas, run SQL, run Redis commands, and open tables in the desktop UI, all behind a DBX-managed access policy that is read-only by default. It targets developers who want their AI coding assistant to inspect and query databases through the same connections they already manage, without hand-copying credentials into agent config.

The Good

The MCP server works end to end against a real database. This is the core claim and it holds. After npm install @dbx-app/mcp-server (2 packages, 0 vulnerabilities, 2 seconds), the native binary completed the MCP 2025-06-18 initialize handshake, listed 12 tools, accepted a SQLite connection added through dbx_add_connection, and returned correct query results. A SELECT name, email FROM users WHERE active = 1 came back with Ada Lovelace and Alan Turing, which is exactly what was in the test database. The schema describe tool returned column names, types, primary key flags, and nullability. This is not a stub that starts and crashes on first contact.

The read-only-by-default safety model is real and verified. A DROP TABLE users sent through dbx_execute_query was rejected with Error [SQL_BLOCKED]: High-risk SQL is disabled in DBX MCP settings. The policy has three tiers (Read only, Data read/write, Full access) managed in DBX Settings, reloaded for every request, and the legacy DBX_MCP_ALLOW_WRITES env var can only narrow policy, never widen it. MongoDB mutations require a verifiably effective filter unless Full access is on. Aggregation stages like $out and $merge are classified as high-risk writes. For agent database access, where a hallucinated DELETE is the worst-case scenario, this fail-closed default is the correct design.

The database breadth claim checks out. The "70+ databases" headline is verifiable in the repo: 35 SQL dialect YAML files under plugins/dialects/ (sqlite, postgres, mysql, clickhouse, oracle, dameng, kingbase, gaussdb, and 27 more) plus 45 JDBC driver directories under agents/drivers/. The dbx doctor command confirms 10 database types run with direct native execution (postgres, mysql, sqlite, redis, and compatible engines) while 52+ require the desktop bridge or a JDBC agent. No other single MCP server GearScope has tested covers this many databases.

The Rust core is built on the official MCP SDK and is size-optimized. The MCP crate depends on rmcp 2.2.0 (the official Rust MCP SDK), and the release profile sets lto = true, opt-level = "s", and strip = true, which is why the binary lands at 16 MB. The server.json registry manifest targets the 2025-12-11 MCP schema with npm stdio transport, so it registers correctly in MCP directories.

The SKILL.md is well-structured and safety-conscious. The bundled skills/dbx/SKILL.md opens with a prerequisite check (dbx doctor), lists commands with --json as the default, includes an error-code table (CONNECTION_NOT_FOUND, SQL_BLOCKED, DBX_NOT_RUNNING), documents multi-step workflows (explore then query, generate context then help write SQL), and has a "Common Pitfalls" section whose first entry is "Never add --allow-writes unless the user explicitly confirms." That is the right tone for a skill that drives a database.

The Bad

There are no Hermes or OpenClaw install docs. The README and the MCP server README mention Claude Code, Cursor, and Windsurf by name and show .mcp.json examples, but Hermes Agent and OpenClaw appear nowhere in the repo (zero grep hits). The server is a standard MCP stdio process, so it works with any MCP client including Hermes once you write the config yourself, but a Hermes user gets no guidance. Given that GearScope's audience runs Hermes, this is the most noticeable ecosystem gap.

The documentation lags the code in small but real ways. The MCP server README says "10 MCP tools" in its feature list and tool table, but tools/list returns 12: dbx_open_session and dbx_close_session (stateful query sessions that preserve USE/SET across calls) are exposed but not documented in the tool table. The version story is also split: the desktop app is at v0.5.73 while the npm packages (MCP server and CLI) are at v0.4.51, and the MCP serverInfo reports 0.4.51, so a reader cross-referencing the GitHub latest release (v0.5.73) against the npm version sees different numbers with no explanation in the install docs.

Two of the twelve tools require the desktop app to be running. dbx_open_table and dbx_execute_and_show (open a table or show a query result in the DBX desktop UI) return "DBX is not running" if the desktop application is closed. For a headless server or CI agent with only the MCP server installed, these two tools are dead weight. The other 10 tools work standalone for direct-execution databases, but the tool list does not advertise this dependency.

The open issue count is high for the project's age. At 1,054 open issues against 12,951 stars (an 8.1% issue-to-star ratio), the tracker is dense. The project is only three months old (created 2026-04-29) and ships multiple times per day, so some of this is fast-moving beta traffic, but it means the issue queue is not a reliable signal for what is broken versus what is a feature request.

DuckDB needs a separate driver install even through MCP. The MCP binary bundles the DuckDB sidecar client but not the DuckDB engine, so a DuckDB connection fails until you install the engine through DBX Driver Manager. This is documented, but it is a friction point for a database that is increasingly common in agent data workflows.

Smoke Test Results

Testing ran on the host (macOS 26.5.2, aarch64, Node 24.13.1, npm 11.8.0). The npm MCP server package was installed into an isolated directory and the native Rust binary was exercised over stdio using a custom JSON-RPC 2.0 client. A sample SQLite database (users and orders tables, three rows) was created with Python's sqlite3 module before the test.

Run A. Fresh sandbox, no deps preinstalled

$ git clone --depth 1 https://github.com/t8y2/dbx.git
PASS - cloned, 3027 files (excl .git), 114 MB

$ cd /tmp/dbx-test && npm init -y && npm install @dbx-app/mcp-server
PASS - added 2 packages in 2s, 0 vulnerabilities (mcp-server + mcp-darwin-arm64)

$ node node_modules/@dbx-app/mcp-server/bin/dbx-mcp-server.js --verify-platform
PASS - exit 0 (platform binary resolves and is executable)

$ file node_modules/@dbx-app/mcp-darwin-arm64/bin/dbx-mcp
PASS - Mach-O 64-bit executable arm64, 16 MB

Pass rate: 4 of 4. The npm install pulls the platform-specific Rust binary automatically through optionalDependencies. No Cargo, no Python, no C toolchain required.

Full fresh log →

Run B. Server starts and tools respond

$ initialize {protocolVersion: "2025-06-18", clientInfo: gearscope-test v1.0.0}
PASS - serverInfo: dbx v0.4.51, capabilities.tools: true, protocol 2025-06-18

$ notifications/initialized
PASS - accepted (no response expected)

$ tools/list
PASS - 12 tools: dbx_add_connection, dbx_close_session, dbx_describe_table,
 dbx_execute_and_show, dbx_execute_query, dbx_execute_redis_command,
 dbx_get_schema_context, dbx_list_connections, dbx_list_tables,
 dbx_open_session, dbx_open_table, dbx_remove_connection

Pass rate: 3 of 3. This is the canonical install-correctness verdict for an MCP server. The server starts, completes the handshake, and advertises its tool catalog.

Full with-deps log →

Tools respond

$ dbx_add_connection {name: "test-sqlite", db_type: "sqlite", host: "/tmp/dbx-test/sample.db"}
PASS - Connection "test-sqlite" added (id: 95390ad9-...)

$ dbx_list_connections {}
PASS - markdown table: test-sqlite | sqlite | /tmp/dbx-test/sample.db | port 0

$ dbx_list_tables {connection_name: "test-sqlite"}
PASS - orders (BASE TABLE), users (BASE TABLE)

$ dbx_describe_table {connection_name: "test-sqlite", table: "users"}
PASS - id (PK) INTEGER, name TEXT, email TEXT, active INTEGER

$ dbx_execute_query {connection_name: "test-sqlite", sql: "SELECT name, email FROM users WHERE active = 1 ORDER BY name"}
PASS - Ada Lovelace | ada@example.com, Alan Turing | alan@example.com (2 rows, 0ms)

$ dbx_execute_query {connection_name: "test-sqlite", sql: "DROP TABLE users"}
FAIL (correctly) - Error [SQL_BLOCKED]: High-risk SQL is disabled in DBX MCP settings.

$ dbx_get_schema_context {connection_name: "test-sqlite"}
PASS - compact schema dump, 238 chars (token-optimized)

Functional pass rate: 7 of 7. The DROP TABLE "failure" is the intended behavior and counts as a pass for the safety claim. Real queries return real rows, metadata is accurate, and write protection fires.

Full functional log →

What the runs tell you

The runs say the MCP server is the real product surface for agents, not a marketing checkbox. Install is two seconds, the handshake is clean, and the tools return correct data against a live database. The only thing the smoke test could not exercise is the desktop bridge (52+ database types that route through the DBX desktop app) and the JDBC agent path, both of which need their respective runtimes. For the 10 direct-execution databases (SQLite, Postgres, MySQL, and compatible), the server is fully functional standalone.

Setup Walkthrough

1. Install the MCP server: npm install -g @dbx-app/mcp-server (or use npx -y @dbx-app/mcp-server with no global install).
2. Add it to your MCP client config. For a generic stdio client:

 {"mcpServers": {"dbx": {"command": "npx", "args": ["-y", "@dbx-app/mcp-server"]}}}

1. Point it at your DBX data directory if the desktop app is not installed in the default location: set DBX_DATA_DIR to the folder containing dbx.db.
2. For a standalone SQLite or Postgres connection with no desktop app, call the dbx_add_connection tool from your agent with db_type, host, and credentials. The connection persists in DBX storage.
3. Verify with dbx doctor (from @dbx-app/cli) to confirm which database types support direct execution versus the desktop bridge on your platform.

Post-install gotcha: do not install with npm install --no-optional, because the platform binary ships as an optional dependency and the launcher will fail to find it. Linux requires glibc (Alpine/musl is unsupported). DuckDB requires a separate engine install through DBX Driver Manager.

Alternatives

1. googleapis/mcp-toolbox - the official Google MCP server for databases with 47 source connectors and a skills-generate subcommand. Prefer it when you want a pure server-side database MCP with no desktop client and first-class Google Cloud database support.
2. github/github-mcp-server - the official GitHub MCP server. Not a database tool, but the same "official vendor MCP server with a managed policy" pattern; useful as a reference for how a first-class MCP server documents its Hermes/Claude/Cursor install paths.
3. Direct sqlite3 / psql in the agent shell - for a single local database, letting the agent run sqlite3 or psql directly is simpler than an MCP server. Prefer dbx when you need connection management, write-protection policy, or multi-engine breadth that a raw CLI does not give you.