Loading ToolBench
MCP server for SQL database connectivity and query execution across multiple database drivers (MySQL, PostgreSQL, BigQuery, Oracle, SQLite, Aerospike, Firebase)
mcp-sqlkit provides 4 well-structured database tools with mostly complete schemas and descriptions. All tools have input schemas with proper types and descriptions. Tool names follow verb_noun convention (dbQuery, dbExec, dbListConnections, dbSetConnection). However, descriptions are embedded as markdown files (not shown in source excerpt), making inline assessment difficult. Parameter descriptions are present and reasonably detailed. Output schemas are inferred from struct definitions in code. The server demonstrates solid fundamentals but lacks some LLM-optimized polish: descriptions lack depth guidance on when to use which tool, no explicit error recovery hints, no pagination pattern documented, and sensitive parameter handling (secretURL, secretKey) needs explicit warnings about secret injection patterns. Risk annotations (READ_ONLY, WRITE) are present at tool level but not expressed as modern toolAnnotations (readOnlyHint, destructiveHint). Composition is clean, each tool has single responsibility. Tool chaining is enabled: dbSetConnection returns callbackURL for OOB flows, dbListConnections returns connector names that feed into dbQuery/dbExec.
Execute SQL statement (INSERT, UPDATE, DELETE, DDL) and return affected rows count
List all available database connectors in the caller's namespace
Execute SQL query and retrieve results from a database connector
Register or update a database connector with connection details and optional out-of-band secret elicitation
Sensitive parameters (secretURL, secretKey) exposed in tool input schema. MCP spec and production baselines require server-side secret injection via environment or vault, never tool parameters. Agent traces log all parameters, secrets will leak into logs and prompt history.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not present in schema. Risk metadata exists in feature flags (READ_ONLY, WRITE) but should be expressed as modern MCP 2026-07-28 toolAnnotations for LLM safety and proper planning.
Descriptions lack LLM-optimized guidance on when to use each tool. dbQuery vs dbExec distinction is clear, but no guidance on: when to call dbListConnections first, how OOB secret elicitation works for dbSetConnection, error recovery paths. Descriptions should be 50-200 chars with actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 63 | - | v1 |
No pagination pattern documented for query results. dbQuery accepts 'sql' but no documented limit parameter. Large result sets risk blowing context window. Should support limit/offset and return total count or next_cursor.
Error responses not documented. buildErrorResult() exists but no schema or guidance on error structure, categorization (retryable vs fatal), or recovery hints. LLM cannot act on bare error codes.
args parameter in dbQuery and dbExec is 'type: array' with minimal description. No guidance on parameter binding, SQL injection prevention, or how array elements map to query placeholders. Production tools document this explicitly.
dbSetConnection has interdependent parameters (driver choice determines which of host/port/project/db apply). No documented dependency matrix or conditional parameter logic. LLM may pass invalid combinations.
Output schema for dbListConnections not shown. Inferred from code as ListOutput struct, but structure (fields, types, pagination) not documented in provided source. Cannot verify against pagination baselines.