Loading ToolBench
A stdio MCP server exposing the Database tool (per-project external database connections) to agent CLIs. Provides read-only and read-write access to registered databases with connection management, schema introspection, and SQL query execution.
Five tools with clear verb-noun naming (db_*, all action-oriented). Descriptions are well-written (100-200 chars), explaining WHAT, WHEN, and prerequisites. Input schemas present with typed parameters and descriptions. However, output schemas are not documented in the provided source, critical for LLM planning. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint). db_execute is destructive but lacks confirmation/dry-run pattern. Parameter descriptions are good but some lack format constraints (e.g., 'sql' param has no length/complexity limits).
List the current project's registered database connections (id, name, engine, host, database, read_only). Call this first — every other db_* tool needs a connection_id from here. An empty list means the operator has not configured any database for this project.
Run ONE mutating SQL statement (INSERT, UPDATE, DELETE, DDL) against a WRITABLE connection. This CHANGES THE TARGET DATABASE — be certain of the statement, prefer a WHERE clause you have verified with db_query first, and never guess table names. Fails on connections the operator marked read-only or without the db:write scope. One statement per call; no transaction control.
Run ONE read-only SQL statement (SELECT, EXPLAIN, SHOW, VALUES, TABLE, or a non-mutating WITH). Executes inside a READ ONLY transaction with a statement timeout — mutating statements are rejected; use db_execute for those. One statement per call.
Introspect a connection's structure. With only connection_id: list schemas. With schema: list that schema's tables and views. With schema + table: full table metadata (columns, primary key, indexes, foreign keys).
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., what fields does db_connections_list return? What structure does db_schema return for table metadata?).
db_execute is destructive (INSERT, UPDATE, DELETE, DDL) but lacks confirmation/dry-run pattern. Agents can accidentally corrupt databases. No idempotent hint or confirmation request mechanism.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe tools from dangerous ones without reading descriptions carefully.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Read rows from one table with paging, sorting and simple filters — no SQL needed. Results are row-capped; check "truncated".
db_query and db_execute 'sql' parameters lack format constraints. No length limits, complexity warnings, or injection guidance. LLMs could pass arbitrarily large or malicious SQL.
Error handling descriptions missing. No guidance on retryability, user-fixable vs fatal errors, or recovery steps. E.g., what should the LLM do if a connection is read-only or a table doesn't exist?