Loading ToolBench
PostgreSQL Tuning and Analysis Tool - provides tools for database analysis, query optimization, index recommendations, and health monitoring
PostgreSQL MCP server demonstrates solid definition quality with comprehensive tool descriptions and well-structured input schemas. All 7 tools have clear, action-oriented names (list_, get_, explain_, analyze_) and substantive descriptions (150-500 chars). Input schemas are complete with proper JSON Schema types and descriptions for all parameters. However, there are notable gaps: no output schemas documented, no tool annotations (readOnlyHint), and some parameter descriptions could be more explicit about constraints and error cases. Error handling guidance is largely absent, tools don't indicate what to do on failure. The 'host' parameter pattern across all tools introduces minor naming friction (should be more explicit about when it's required vs optional). Overall, the server follows 40+ of 54 patterns well but misses some critical production patterns around error recovery and output specification.
Analyzes database health. Here are the available health checks: - index - checks for invalid, duplicate, and bloated indexes - connection - checks the number of connection and their utilization - vacuum - checks vacuum health for transaction id wraparound - sequence - checks sequences at risk of exceeding their maximum value - replication - checks replication health including lag and slots - buffer - checks for buffer cache hit rates for indexes and tables - constraint - checks for invalid constraints - all - runs all checks You can optionally specify a single health check or a comma-separated list of health checks. The default is 'all' checks.
Analyze a list of (up to 10) SQL queries and recommend optimal indexes
Analyze frequently executed queries in the database and recommend optimal indexes
Explains the execution plan for a SQL query, showing how the database will execute it and provides detailed cost estimates.
Show detailed information about a database object
No output schemas documented for any tool. LLMs cannot predict response structure, field types, or available downstream references. Forces agents to blindly parse unstructured results.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). All tools are read-only (correct classification) but this is not declared in the schema, forcing LLMs to infer safety from descriptions alone.
'host' parameter is optional but required behavior is conditional (single vs multiple hosts). Description does not explain when it must be provided vs inferred, and error message on missing host will not be user-friendly for LLMs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
List objects in a schema
List all schemas in the database
Error handling guidance missing. Tools do not document what errors are possible, whether they are retryable, or what recovery steps the LLM should take. No error classification (user-fixable vs fatal).
analyze_workload_indexes and analyze_query_indexes descriptions lack context on when to use each. 'dta' vs 'llm' method enum values are undocumented, LLMs cannot determine which to choose.
analyze_db_health 'health_type' parameter description is unclear about what values are valid. Format says 'comma-separated list' but schema shows enum (implying single values only). Constraint mismatch will confuse LLMs.
No pagination support visible for list_schemas and list_objects. If databases contain many schemas or objects, results could exceed context windows. Missing limit/offset parameters.