Loading ToolBench
MCP server for querying PostgreSQL and MySQL databases
This server has complete input schemas for all 5 tools and descriptions present for each tool and parameter. However, the descriptions are generic and lack LLM-optimization guidance about when to call each tool or what happens as a side effect. Parameter descriptions are minimal (often just restating the parameter name). The tool set itself is logically sound but lacks depth in guiding agent behavior. Output schemas are not documented anywhere in the code. Error handling is minimal, the code shows try/catch blocks but no guidance to the LLM on recovery steps. Parameter descriptions do not specify constraints (format, range, enum values where applicable). Overall, this is a functional baseline implementation that would benefit significantly from richer descriptions and output documentation.
Connect to a PostgreSQL or MySQL database. Parameters can be provided directly or loaded from environment variables. If no parameters are provided, will use environment variables (DB_TYPE, DB_HOST, DB_PORT, DB_DATABASE, DB_USER, DB_PASSWORD, DB_SSL). For PostgreSQL: POSTGRES_HOST, POSTGRES_PORT, etc. For MySQL: MYSQL_HOST, MYSQL_PORT, etc.
Get schema information for a specific table
Disconnect from the current database
Execute a SQL query on the connected database. Returns query results.
List all tables in the connected database
Output schemas not documented. LLMs cannot see what fields execute_query, list_tables, and describe_table return, forcing them to guess at downstream tool input mapping.
execute_query description lacks actionable guidance. It says 'Execute a SQL query on the connected database. Returns query results.' but does not indicate: (a) what happens on syntax error, (b) whether parameterized queries are required to prevent injection, (c) what the result structure looks like, or (d) when to call list_tables/describe_table first.
connect_database description is verbose (250+ chars) but does not explain: (a) what happens if a connection already exists, (b) whether credentials can be passed in the tool call or must use env vars, (c) the precedence order (env vars override params or vice versa), or (d) how to verify the connection succeeded before calling execute_query.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
execute_query 'params' parameter has no type constraint on array items. Schema declares items as type: ['string', 'number', 'boolean', 'null'] but does not validate that positional parameters match the query placeholders. LLMs may pass misaligned arrays.
No permission gates or scope declarations on dangerous tools. execute_query can issue DROP TABLE, DELETE, or other destructive commands. No tool description warns of this or requests user confirmation. Pattern: permission-gate not applied.
Error messages visible in code are generic. Example: 'Unknown tool: {name}'. LLMs receive no guidance on what to do next (e.g., 'Available tools are: connect_database, execute_query...'). Pattern: recovery-guide not applied.
connect_database password parameter is required to be a string with no description of format, length limits, or special character handling. LLMs may pass invalid values; error handling is opaque.
list_tables and describe_table have empty property objects in inputSchema, no documentation of structure, yet 'required' is an empty array. This is correct (no params required) but the description does not explain what happens if the database is empty or if there are no tables.