Loading ToolBench
Agent-friendly database introspection protocol for Claude Code, Cursor, Copilot. Provides MCP tools for querying database schema, previewing tables, and executing safe read-only queries across PostgreSQL, MySQL, MongoDB, MSSQL, and Prisma ORM.
This server defines 4 tools with explicit schemas and descriptions. All tools follow verb_noun naming conventions (dlp_get_*, dlp_preview_*, dlp_describe_*, dlp_safe_*) and have clear, actionable descriptions (avg 150-200 chars). Input schemas are fully defined with proper JSON Schema type declarations. However, there are notable gaps: (1) no documented output schemas, return structures are inferred from code only, not declared to clients; (2) parameters lack some constraints (e.g., limit in dlp_preview_table should explicitly state 1-20 bounds in description, not just type:number); (3) error handling descriptions are minimal, dlp_safe_query validates input but the description doesn't explain what validation errors look like or how to recover; (4) no tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only; (5) parameter descriptions could be more explicit about format requirements and edge cases. The tools are well-named and address a clear domain (database introspection), but fall short of production-grade polish.
Returns detailed column information for a single table or collection: data types, nullability, primary keys, foreign keys, indexes, default values, and comments.
Returns all tables/collections in the connected database with column names, types, primary keys, foreign keys, and row counts. Call this first to understand the database structure before writing any queries or debug code. Use the schema parameter to filter to a specific schema (e.g. "public") and avoid noise from system schemas.
Returns sample rows from a database table or collection. Default 5 rows, max 20. Long text fields are automatically truncated to 200 characters. Also returns total row count.
Executes a read-only SELECT query and returns results. Rules: must be SELECT only, no INSERT/UPDATE/DELETE/DROP/TRUNCATE allowed, must include a LIMIT clause (max 20 rows enforced server-side). For MongoDB: use JSON filter format with /* collection: name */ comment prefix, e.g. /* collection: users */ {"status": "active"}
Output schemas not documented. Clients cannot infer what fields to expect from tool responses. For example, dlp_get_schema returns {tables: ...} but the structure of 'tables' is not formally declared. This forces LLMs to guess downstream field names and risks failed data extraction.
Parameter constraints not fully described. dlp_preview_table 'limit' parameter accepts type:number but description only says '1-20, default 5', it should state 'Integer in range [1, 20], default 5' in the description text. dlp_safe_query 'query' parameter lacks guidance on max query length, allowed SQL keywords, or error recovery.
Error handling guidance is implicit, not explicit. dlp_safe_query validates queries and returns isError: true for invalid SQL, but the description does not explain what validation failures look like or how to recover. E.g., 'If validation fails, the response will indicate the constraint violated (e.g., missing LIMIT clause). Revise the query and retry.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No tool annotations. All four tools are read-only and safe for repeated invocation, but they lack readOnlyHint and idempotentHint annotations. This prevents clients from optimizing caching and error recovery based on tool properties.
dlp_get_schema schema parameter lacks specificity. Description says 'Filter to a single database schema (e.g. "public" for PostgreSQL, "dbo" for MSSQL)' but does not clarify: (1) Is this case-sensitive? (2) What happens if the schema doesn't exist, error or empty result? (3) Are there system schemas the parameter should exclude by default?
dlp_safe_query description references MongoDB JSON format but provides a code comment example (/* collection: users */) without explaining how the tool detects MongoDB vs SQL databases or what happens if the format is wrong. This creates ambiguity for multi-backend deployments.