Loading ToolBench
Production-grade AI PostgreSQL MCP Server
Server has 12 well-named tools with clear verb-noun patterns (list_tables, describe_table, execute_select, etc.). Descriptions are present and reasonably detailed (avg ~150 chars), exceeding the 10-char minimum. However, input schemas are INFERRED from docstring parameters rather than explicitly visible in JSON Schema format in the source code provided. Parameter descriptions exist in docstrings but lack formal type constraints (enums, min/max). Output schemas are not documented. Error handling is mentioned in code comments but recovery guidance is not visible in tool definitions. Security considerations (SQL injection prevention in execute_select) are implemented but not declared in tool metadata.
Answer a free-form business question by generating and running the appropriate SQL query, then interpreting the results in plain language. Combines real database data with LLM reasoning.
Count the number of rows currently in a table.
Describe a table's structure: its columns (name, type, nullability, default) and its foreign key relationships.
Execute a read-only SELECT query against the database and return the resulting rows. Only SELECT statements are permitted — any INSERT, UPDATE, DELETE, DDL, or multi-statement query is rejected. Results are capped at 100 rows unless the query includes its own LIMIT clause.
Explain what a SQL query does in plain language.
Find tables related to the given table, directly or indirectly, by traversing foreign key relationships. Depth 1 means directly connected via a FK; depth 2 means connected through one intermediate table, and so on.
Input schemas not explicitly visible in JSON Schema format. Tool definitions use Python docstring parameters, but formal JSON Schema with type constraints (enums, min/max, patterns) is not shown in source code. This forces LLMs to infer parameter types from docstring text alone.
Output schemas not documented. Tools return structured data (list[str], dict, list[dict], int) but the shape of returned objects is not formally specified. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Generate a SQL SELECT query from a natural-language question, grounded in the actual database schema. Returns SQL text only — does not execute it. Review the query (or pass it to execute_select) before running it.
List just the columns of a table (name, data type, nullable, default value), without foreign key info.
List all tables in the connected PostgreSQL database.
Suggest performance optimizations for a SQL query, considering the actual schema (indexes, relationships, etc).
Search all table and column names in the database for a keyword. Useful when you don't know the exact table/column name but know roughly what you're looking for (e.g. "email").
Generate a concise executive overview of the entire database: what kind of business it represents, its scale, and anything notable about its structure.
No pagination support visible. execute_select caps results at 100 rows but offers no limit/offset parameters or cursor-based pagination. Large result sets risk context window exhaustion.
Error handling guidance not visible in tool definitions. Comments mention safeguards (single-statement check, forbidden keywords) but tool descriptions do not tell LLMs what to do if a query fails or a table is not found.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. All tools are read-only but this is not declared in metadata, forcing LLMs to infer safety from descriptions alone.