Loading ToolBench
Secure PostgreSQL integration for AI assistants via Model Context Protocol
pg-lens-mcp has well-structured tool definitions with consistent naming (verb_noun pattern: list_, get_, search_, execute_, explain_) and clear descriptions (avg ~120 chars). All 8 tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the source code, LLMs cannot see what fields to expect from responses. Parameter descriptions are adequate but lack format constraints (e.g., no regex patterns, min/max for numeric limits). Error handling is minimal, no recovery guidance or actionable error messages visible. Security is strong (read-only enforcement, no secrets in params), but composition could be tighter (explain_query and explain_analyze are similar; could be unified with a format parameter).
Execute a read-only SQL query. Query runs in a READ ONLY transaction for safety.
Execute a query with EXPLAIN ANALYZE to get actual timing and row statistics. ⚠️ WARNING: This actually executes the query, so it may be slow on large tables.
Get the query execution plan (EXPLAIN) without actually running the query. Useful for understanding how PostgreSQL will execute a query.
Retrieve data from a table with optional structured filtering and pagination.
Get detailed information about a table including columns, data types, and constraints.
List all non-system schemas in the database.
Output schemas not documented. LLMs cannot see what fields list_schemas, get_table_info, get_table_data, execute_query, explain_query, and explain_analyze return. This forces LLMs to guess field names and types, increasing hallucination risk and breaking tool chaining.
No error recovery guidance. Tools like execute_query and explain_analyze can fail (syntax errors, timeouts, permission issues) but provide no actionable error messages or recovery hints. LLMs cannot self-correct.
Parameter constraints missing. get_table_data accepts limit (max 1000) and offset, but no min/max bounds are declared in the schema. column_pattern in search_column lacks length or regex constraints. Format constraints should be in JSON Schema, not just descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
List all tables in the database. Optionally filter by schema.
Find tables containing a column name pattern (case-insensitive search).
explain_query and explain_analyze are near-duplicates. Both accept query, format, and verbose. explain_analyze adds buffers and timing. These should be unified into a single explain_query tool with an analyze boolean parameter to reduce cognitive load and tool selection ambiguity.
No pagination metadata in list_tables and list_schemas. If a database has hundreds of schemas or tables, these tools will return all results, potentially exhausting context. Should accept limit/offset and return a total_count.