Loading ToolBench
An MCP server that helps optimize PostgreSQL database performance by identifying slow-running queries, analyzing query execution plans, recommending indexes, suggesting query rewrites, and analyzing database structure.
Five tools with consistent naming (verb_noun pattern) and basic descriptions, but critical gaps in schema completeness and parameter documentation. All tools accept secret_name/region_name for AWS credential injection (good security practice), but descriptions lack actionable context for LLM selection. Output schemas are entirely undocumented, LLMs cannot plan downstream calls or extract structured data. Error handling is minimal (generic try/catch returning string messages). No parameter constraints (enums, ranges, formats) despite opportunities (e.g., region_name should be an enum). Descriptions average ~120 chars, within acceptable range, but lack WHEN/WHY guidance. Tools are read-only (good), but this is not declared in descriptions. No tool annotations (readOnlyHint, idempotentHint) present.
Analyze the database structure and provide insights on schema design, indexes, and potential optimizations.
Analyze a SQL query and provide optimization recommendations.
Get index recommendations for a specific query based on execution plan analysis.
Identify slow-running queries in the database.
Suggest optimized rewrites for a SQL query based on detected anti-patterns and performance issues.
Output schemas completely undocumented. All tools return plain strings; LLMs cannot parse structured results or chain calls. No field definitions, no pagination info, no result count.
Parameter descriptions lack actionable constraints. region_name accepts any string; should be enum (us-west-2, us-east-1, etc.). min_execution_time and limit lack min/max bounds. No format guidance for query parameter.
Tool descriptions do not declare read-only nature or when to use each tool vs. others. No guidance on prerequisites (e.g., pg_stat_statements extension for get_slow_queries). Descriptions are generic and do not help LLM selection.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Error handling returns plain strings with no recovery guidance. Example: 'Error analyzing database structure: {str(e)}' gives LLM no actionable next step. No error classification (retryable vs. user-fixable vs. fatal).
No tool annotations (readOnlyHint, idempotentHint) present. All tools are read-only and idempotent, but this is not declared in schema. LLMs cannot infer safety properties.