Loading ToolBench
Universal MCP server for connecting LLMs to MySQL databases with safe, read-only query execution and comprehensive schema introspection.
SQL Bridge MCP presents well-structured tool definitions with comprehensive descriptions and detailed input schemas. All 6 tools are explicitly registered in src/handlers/tools.ts with clear verb-noun naming, descriptions spanning 100-200+ characters, and full JSON Schema definitions. However, output schemas are not documented, the tool definitions show input schemas but lack structured output documentation, forcing LLMs to infer response structure. Error handling is present but generic (McpError with ErrorCode). Parameter descriptions are strong (explaining limits, constraints, validation rules), but some lack concrete format/constraint guidance. Tool composition is excellent: each tool has a single responsibility, names are action-oriented, and chaining is supported through consistent parameter naming (e.g., 'table' parameter across describe_table, sample_data).
Get the full column-level schema of a specific table, including column names, data types, nullability, key constraints (PRI/UNI/MUL), default values, and comments.
Get the complete database schema — all tables with every column's name, type, nullability, key, default value, and comment. Also includes row counts and a generation timestamp.
List all tables in the connected MySQL database. Returns each table's name, approximate row count, and comment.
Execute a SQL SELECT query or a natural language question against the connected MySQL database. For natural language questions, returns the database schema so you can construct a SELECT query. For SQL queries, validates and executes them safely with parameterized limits. Only SELECT statements are permitted — INSERT, UPDATE, DELETE, DROP, and all other write operations are blocked.
Retrieve a small set of sample rows from a table to preview its data structure, content, and value formats.
Output schemas not documented. Tool definitions specify inputSchema but provide no structured documentation of response types, fields, or data types for return values. LLMs cannot infer response structure and must rely on implicit knowledge or trial-and-error.
No pagination support documented. query_database accepts a 'limit' parameter (max 500) but no 'offset', 'page', or 'cursor' parameters. Tools returning lists should offer pagination; without it, agents cannot iteratively fetch all results and may exhaust the context window on large datasets.
Error handling is generic. Tools catch errors and throw McpError with ErrorCode but provide no recovery guidance or context about what went wrong. Descriptions lack error conditions (e.g., 'If table not found, try list_tables()' or 'Invalid SQL syntax will return error code X').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Get live server health metrics: connection pool status (total/active/idle), rate limiter state, process uptime in seconds, and Node.js memory usage (rss, heapUsed, heapTotal).
No confirmation step for potentially dangerous operations. query_database blocks write operations (INSERT, UPDATE, DELETE, DROP), but there is no dry-run or confirmation mechanism. If validation logic is bypassed or a novel attack vector emerges, there is no safety gate.
Parameter format constraints stated in descriptions but not in JSON Schema. The 'table' parameter includes a regex pattern (^[a-zA-Z_][a-zA-Z0-9_]*$) and maxLength in schema, which is good. However, the description relies on human-readable text ('alphanumeric and underscores only, max 64 chars') rather than fully leveraging the schema's pattern field. Descriptions should reinforce, not duplicate, schema constraints.