Loading ToolBench
Read-only PostgreSQL analytics agent exposed as an MCP server
Server provides 6 read-only PostgreSQL analytics tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are terse (10-80 chars, well below the 194-char baseline), lack WHEN/WHY context, and omit dependency hints. Parameter descriptions are minimal. Output schemas are undocumented, LLMs cannot plan downstream calls or extract structured data reliably. No error handling guidance, no recovery paths, no validation messaging. Tools follow verb_noun naming but lack composition guidance (e.g., which tool to call first for a complete analysis). Security is sound (read-only role validation at startup), but tool definitions do not reflect this assurance in descriptions.
Active/idle/idle-in-txn session counts plus longest running transaction.
Index usage stats — index_scan / tup_read / size — per index, sorted by scans ASC.
Run EXPLAIN (ANALYZE, BUFFERS, VERBOSE) against a query. Query is never executed.
Size summary at level: database | schema | table. Defaults to table.
Top slow queries from pg_stat_statements. sort_by: mean_time | total_time | calls.
Last vacuum / autovacuum / analyze per user table, with age.
Output schemas undocumented. Tools return dicts/lists but LLMs cannot see field names, types, or structure. Prevents downstream tool chaining and forces LLMs to guess at response shape.
Descriptions are terse (10 - 80 chars, vs 194-char baseline) and lack WHEN/WHY context. E.g., 'Index usage stats, index_scan / tup_read / size, per index, sorted by scans ASC' tells WHAT but not WHEN to call it or how it relates to other tools.
No error handling guidance. Tools may fail (e.g., pg_stat_statements not enabled, permission denied) but return no recovery hints. LLMs cannot self-correct or suggest next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Parameter descriptions are minimal or absent. E.g., 'sort_by' in slow_queries has description 'Sort order: mean_time, total_time, or calls' but no guidance on when to use each. 'limit' lacks range constraints (1 - 1000?).
No tool composition guidance. Descriptions do not hint at dependencies (e.g., 'Call slow_queries first to identify candidates, then query_plan to analyze'). LLMs must infer the workflow.