Loading ToolBench
MCP server for PostgreSQL database operations - query, explore schemas, and analyze tables
PostgreSQL MCP server demonstrates solid foundational quality with consistent naming conventions (verb_noun pattern), complete parameter descriptions, and clear risk classifications. However, it has significant gaps in output schema documentation, insufficient error handling guidance, and weak parameter validation constraints. 13 out of 15 tools lack documented return types. Parameter descriptions are adequate but lack detail on ranges, format constraints, and dependencies. The server uses proper JSON Schema structures but omits important constraints like min/max for numeric fields and enum declarations where applicable. Security posture is reasonable (no secrets in parameters, write operations gated behind configuration) but lacks explicit audit trail documentation.
Describe the structure of a table including columns, types, and constraints.
Get the definition and columns of a view.
Execute a write SQL statement (INSERT, UPDATE, DELETE). WARNING: This tool modifies data. Available only when writes are enabled globally or for the selected database.
Get the execution plan for a SQL query (EXPLAIN).
Get database and connection information.
List all constraints for a table (PK, FK, UNIQUE, CHECK).
List the databases this server is configured to reach, by alias, with their host, database name, whether writes are allowed, and which one is the default. Credentials are never returned. Call this first when the user mentions a database by name, then pass the alias as the "database" argument of any other tool.
Output schemas are completely undocumented. No tool response formats are specified. LLMs cannot predict what fields to expect, forcing them to reason about structure in an unpredictable way and complicating downstream tool chaining.
Parameter descriptions lack format constraints and ranges. 'sql' parameter has no guidance on statement size limits, timeout expectations, or forbidden patterns. 'schema' parameter omits valid schema names and whether it supports wildcards. 'limit' parameters (if any pagination exists) lack min/max specifications.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List all functions and procedures in a schema.
List all indexes for a table.
List all schemas in the PostgreSQL database.
List all tables in a specific schema.
List all views in a schema.
Execute a SQL query against the PostgreSQL database. This tool is READ-ONLY by default. Use the "execute" tool for write operations.
Search for columns by name across all tables.
Get statistics for a table (row count, size, bloat).
No error recovery guidance. Tools lack descriptions of failure modes (connection timeouts, permission denied, table not found, schema mismatch). LLMs receive errors with no context on what to try next or how to self-correct.
Discovery tools (list_*, describe_*) lack chaining context. They do not document what structure they reveal or when to call them in sequence. E.g., should LLM call list_schemas() before list_tables()? Should describe_table() be called to understand data before query()? Chains are implicit.
Result limits not enforced or documented. No pagination documented for list_* tools. If a schema contains millions of tables, list_tables() could return unbounded results, exhausting context window. Descriptions omit result count limits.
Destructive tools (execute) lack confirmation or dry-run support. The 'execute' tool modifies data but offers no preview-before-commit, dry-run, or confirmation step. A hallucinating LLM could trigger catastrophic deletes.
Database parameter is optional across all tools but has no default behavior documented. When 'database' is omitted, does the server use the first configured connection, a pre-selected default, or error? Ambiguity forces LLMs to guess or always provide the parameter.