Loading ToolBench
Production-grade MCP server that lets any LLM client query a PostgreSQL database through standardised tool definitions.
Server has 4 tools with clear verb-noun naming (list_, describe_, query, execute_). All tools have descriptions (194-char baseline met). Input schemas are present with Zod validation and descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are minimal (e.g., 'The table name to describe' lacks format/constraint hints). Error handling is present but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Missing pagination for list_tables despite potential large result sets.
Show the column definitions, types, and constraints for a specific table.
Execute a write SQL statement (INSERT, UPDATE, DELETE). Only available when ALLOW_WRITE is enabled.
List all tables in the connected PostgreSQL database with schema, row count, and column count.
Execute a read-only SQL query against the database. Only SELECT and WITH statements are allowed.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Baseline: 100% of A+ tools document return types.
list_tables lacks pagination (limit/offset/cursor). Large result sets will blow context window. Baseline: tools returning lists should accept page/limit and return total count.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe vs. risky operations without explicit hints.
Parameter descriptions lack format/constraint hints. E.g., 'The table name to describe' does not specify case sensitivity, allowed characters, or schema qualification (public.table_name vs table_name).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error responses lack recovery guidance. No indication of retryability, user-fixable vs. fatal errors, or suggested next steps (e.g., 'Try search_tables() with a partial name').