Loading ToolBench
An MCP server for PostgreSQL AI-powered performance tuning with HypoPG support
pgtuner_mcp demonstrates solid definition quality with comprehensive tool schemas, detailed descriptions, and proper use of tool annotations. All 8 tools have explicit schema definitions with typed parameters and descriptions. Most tools include actionable descriptions explaining prerequisites and constraints. However, several tools lack output schema documentation, some parameter descriptions could be more precise about constraints and error conditions, and error handling guidance is minimal. The ToolHandler base class shows good pattern discipline (abstract base, annotation support, validation helpers), but several tools have parameter descriptions that reference defaults or constraints without formal schema constraints (e.g., top_n should have enum validation but relies on description).
Inspect shared_buffers contents using pg_buffercache extension. Returns top-N relations by pages cached, % of shared_buffers, dirty page counts, and avg usagecount. Requires pg_buffercache.
Analyze table bloat using the pgstattuple extension. Note: This tool analyzes only user/client tables and excludes PostgreSQL system tables (pg_catalog, information_schema, pg_toast). This focuses the analysis on your application's custom tables. Uses pgstattuple to get accurate tuple-level statistics including: - Dead tuple count and percentage - Free space within the table - Physical vs logical table size This helps identify tables that: - Need VACUUM to reclaim space - Need VACUUM FULL to reclaim disk space - Have high bloat affecting performance Requires the pgstattuple extension to be installed: CREATE EXTENSION IF NOT EXISTS pgstattuple; Note: pgstattuple performs a full table scan, so use with caution on large tables. For large tables, consider using pgstattuple_approx instead (use_approx=true).
Inspect TOAST storage for tables: per-column storage strategy, compression method (PGLZ vs LZ4 on PG14+), and TOAST relation size. Recommends LZ4 for EXTENDED columns on PG14+ when current is PGLZ.
Perform a comprehensive database health check. Note: This tool focuses on user/client tables and excludes PostgreSQL system tables (pg_catalog, information_schema, pg_toast) from analysis. Analyzes multiple aspects of PostgreSQL health: - Connection statistics and pool usage - Cache hit ratios (buffer and index) - Lock contention and blocking queries - Replication status (if configured) - Transaction wraparound risk - Disk space usage - Background writer statistics - Checkpoint frequency Returns a health score with detailed breakdown and recommendations.
No output schema documentation for any tool. While all tools accept structured input, none explicitly document the shape of returned data (field names, types, nesting structure). LLMs cannot plan downstream tool calls or extract needed data without knowing response structure.
Parameter constraints documented in descriptions but not formally in JSON Schema. E.g., analyze_buffer_cache top_n has 'max 100' in description and minimum/maximum in schema (good), but analyze_toast_storage top_n only has it in description. lint_query and lint_workload severity_threshold use enum in schema (good pattern) but others lack this rigor. Inconsistency increases LLM error rate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Run EXPLAIN on a query, optionally with hypothetical indexes. This tool allows you to see how a query would perform with proposed indexes WITHOUT actually creating them. Requires HypoPG extension for hypothetical testing. Use this to: - Compare execution plans with and without specific indexes - Test if a proposed index would be used - Estimate the performance impact of new indexes Returns both the original and hypothetical execution plans for comparison.
Get AI-powered index recommendations for your database. Analyzes your query workload (from pg_stat_statements) and recommends indexes that would improve performance. Uses a sophisticated analysis algorithm that: 1. Identifies slow queries and their access patterns 2. Extracts columns used in WHERE, JOIN, ORDER BY, and GROUP BY clauses 3. Generates candidate indexes (single-column and composite) 4. If HypoPG is available, tests indexes without creating them 5. Uses a greedy optimization algorithm to select the best index set Note: This tool focuses on user/client tables only and excludes system catalog tables (pg_catalog, information_schema, pg_toast). The recommendations consider: - Query frequency and total execution time - Estimated improvement from each index - Index size and maintenance overhead - Avoiding redundant indexes
Statically lint a SQL query for anti-patterns using a pglast AST visitor. Pure-static, no DB call. Detects SELECT *, implicit casts, OR-of-equals, non-sargable LIKE, unbounded SELECT, NOT IN nullable, function-on-indexed-col.
Pull top-N queries from pg_stat_statements and lint each. Findings are ranked by severity x calls x mean_time so the worst-offending pattern appears first.
Error handling and recovery guidance absent. Tools like get_index_recommendations and explain_with_indexes mention dependencies (HypoPG extension, pg_stat_statements) but do not document what to do if missing. No error classification (retryable vs fatal) or recovery action guidance provided.
analyze_toast_storage has nullable table_name parameter (optional) but description does not explain schema-wide scan behavior clearly. When table_name is null, does it scan all tables, apply min_table_size filter, or require explicit schema filtering? The interaction between table_name=null and top_n is undocumented.
Tool annotations present (readOnlyHint=true across all tools, correctly set in schema) but tool descriptions do not always make side-effect behavior explicit. E.g., explain_with_indexes with analyze=true 'executes the query', state clearly in description that this is read-only execution, not a permanent operation. This is documented in annotations but should be reinforced in text.