Loading ToolBench
The PostgreSQL MCP server demonstrates solid foundational design with 15 read-only discovery and query tools. All tools have descriptions and clear action verbs (list_, describe_, get_, query, explain_). However, there are systematic gaps in schema documentation, parameter descriptions, and output structure guidance. Input schemas are visible for 6/15 tools (40%, 15 tools specified in the brief). Parameter descriptions are basic but present. No tools declare output schemas explicitly. Error handling is implicit but not documented in tool definitions. The codebase shows good engineering practices (fastmcp, asyncpg, proper async/await) but tool definitions lack the rigor expected for production agent integration.
Check the health status of a PostgreSQL database
Get detailed column information for a table including data types, constraints, and defaults
Get table and column descriptions including comments and documentation
Get the query execution plan for a SQL query
Get SQL syntax help and examples for constructing valid PostgreSQL queries
Get the row count for a table
Get comments and documentation for a table and its columns
List all tables across all accessible databases in the PostgreSQL cluster
Output schemas are not documented. Tools like list_databases, list_all_tables, database_health, and mcp_server_health have no visible schema definitions in the provided brief, making it impossible for LLMs to understand what fields to expect in responses. This forces the LLM to infer structure and risks misaligned downstream tool chains.
Discovery tools (list_databases, list_all_tables) lack explicit pagination parameters (limit, offset). The descriptions do not state whether results are capped or if pagination is required for large clusters. Without pagination guidance, agents cannot safely handle servers with hundreds of databases or tables.
Parameter descriptions lack format and constraint details. For example, 'sql' parameter in query and explain_query tools only states 'SQL query to execute (SELECT queries only)' but does not specify maximum length, forbidden keywords, or explain validation logic. Constraints should be explicit: 'SELECT queries only; maximum 10KB; UPDATE/DELETE/INSERT/DROP forbidden.'
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | 1.25.0+ | v1 |
List all available databases in the PostgreSQL cluster
List all foreign key constraints on a table
List all indexes on a table
List tables in a specific database and schema
Check the health status of the MCP server itself
Execute a read-only SQL query against a PostgreSQL database
Get a sample of rows from a table
No output field naming documented. Tools return result sets and metadata, but descriptions do not specify field names (e.g., does list_tables return 'table_name' or 'name'? does it include 'schema' or 'schema_name'?). Inconsistent or undocumented field names force agents to guess and break chaining, e.g., if describe_table expects 'table' but list_tables returns 'table_name', the agent cannot pass the result directly.
Error handling is not documented in tool definitions. Tools accept user-supplied database, schema, and table names, but descriptions do not explain what happens when a database does not exist, a table is not found, or a query times out. Agents need recovery guidance: e.g., 'Database not found. Call list_databases() to see available databases.'
limit parameter in sample_data lacks bounds. Description states 'Number of rows to sample (default: 10)' but does not specify min/max. If an agent passes limit=1000000, the query could hang or exhaust memory. Explicit bounds (e.g., '1 - 1000, default 10') prevent abuse.
get_query_syntax_help accepts free-form 'topic' parameter with no enum or format guidance. Agents can pass arbitrary strings like 'RANDOM_GIBBERISH' and the tool will likely fail silently. Document valid topics or provide list_syntax_topics tool to enable discovery.
schema parameter in multiple tools (list_tables, describe_table, etc.) is marked optional with 'defaults to public', but this default behavior is not universal across all PostgreSQL deployments and user contexts. If a table exists in 'myschema' but the agent forgets to specify schema and defaults to 'public', the tool will report 'not found' when it actually exists. Document this behavior clearly and recommend agents always explicitly name the schema.