Loading ToolBench
Read-only MCP server for PostgreSQL database access with support for SQL execution and database object discovery
Strong foundation with clear naming, comprehensive descriptions, and well-structured input schemas. Both tools follow verb_noun conventions and include detailed parameter documentation. Output schemas are documented in descriptions. However, error handling lacks actionable recovery guidance, and some parameter constraints could be more explicit in descriptions rather than relying on schema alone. Tool composition is appropriate (two distinct, single-responsibility tools). The server demonstrates good intent around read-only safety and progressive disclosure patterns.
Execute read-only SQL query against PostgreSQL database. Only SELECT, WITH, EXPLAIN, SHOW, ANALYZE queries are allowed. Results are automatically limited to prevent overwhelming responses. Args: sql: SQL query to execute Returns: JSON object with: - rows: Array of result rows - count: Number of rows returned - total_count: Total rows before truncation - truncated: Whether results were truncated - execution_time_ms: Query execution time Examples: - "SELECT * FROM users LIMIT 10" - "SELECT COUNT(*) FROM orders WHERE status = 'pending'" - "EXPLAIN ANALYZE SELECT * FROM products WHERE price > 100" Errors: - "Read-only mode: ..." if query contains write operations - "Query timeout exceeded" if query takes too long - "Database error: ..." for SQL syntax errors
Search and list database objects with progressive disclosure. Supports searching schemas, tables, columns, indexes, and procedures. Use detail_level to control amount of information returned. Args: object_type: Type of object (schema, table, column, index, procedure) pattern: SQL LIKE pattern (% = any chars, _ = single char) schema: Filter to specific schema (optional) table: Filter to specific table (for columns/indexes) detail_level: Amount of detail (names, summary, full) limit: Max results (1-1000) Returns: JSON object with: - objects: Array of matching database objects - count: Number of objects returned - has_more: Whether more results available - object_type: Type of objects returned - detail_level: Level of detail returned Examples: - object_type="table", pattern="user%" -> tables starting with "user" - object_type="column", schema="public", table="users" -> columns in users table - object_type="index", detail_level="full" -> all indexes with statistics
Error handling lacks recovery guidance. Errors like 'Read-only mode: ...' and 'Query timeout exceeded' are named but do not guide the LLM toward next steps (e.g., 'Try a simpler query' or 'Check query syntax'). Pattern: recovery-guide expects actionable next steps, not bare error messages.
pg_execute_sql lacks explicit parameter constraints in the schema. The description states 'SELECT, WITH, EXPLAIN, SHOW, ANALYZE queries are allowed' but the input schema shows only type='string' with a basic description. JSON Schema could enforce a regex pattern or custom validation to reject non-SELECT statements client-side, improving fail-fast behavior.
pg_search_objects 'pattern' parameter defaults to '%' (match all) without explicit guidance on performance. Returning all objects in a large database could overwhelm context. Description should clarify: 'Use pattern='%' only if limit<50; prefer specific patterns (e.g., 'user%') to avoid large result sets.'
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Output schemas documented in descriptions but not in formal JSON Schema response blocks. While descriptions cover 'rows', 'count', 'total_count', 'truncated', 'execution_time_ms', a formal response schema in the tool definition would improve clarity for tool composition and validation.
No explicit permission scope declarations. Tools are read-only, but they do not declare scopes like 'read:database_metadata' or 'read:data'. This limits least-privilege agent configuration and audit trail clarity.