MCPg demonstrates strong definition quality with 8 well-named tools, comprehensive descriptions, and explicit JSON schemas for all parameters. All tools follow verb_noun naming conventions (get_, describe_, list_, run_). Descriptions are detailed and contextual (average ~180 chars), exceeding the baseline. All parameters include type definitions and descriptions. However, output schemas are not explicitly documented in the source code provided, and some tools lack error handling guidance. The tool suite is well-composed with clear single responsibilities and strong parameter documentation including optional database targeting.
Describe a PostgreSQL schema including its tables, views, indexes, and constraints.
Return a high-level summary of what mcpg can do, organised into capabilities, along with per-tool descriptions and schemas.
Describe a PostgreSQL table including columns, indexes, constraints, and statistics.
For a tool that exists on the server, return its description, input schema, output schema, and bucket metadata. For an unknown name, return registered=false plus a did_you_mean suggestion list.
Return the MCPg server version, access mode, transport, database connection status, and PostgreSQL `wal_level` / `effective_wal_level` (the latter is `None` on PG ≤ 18 where the GUC doesn't exist; on PG 19+ a divergence between the two indicates a reload is still pending).
List all configured databases (primary and read-only secondaries).
Output schemas not documented. While input parameters are well-defined with types and descriptions, the tools do not explicitly document their return value structures. LLMs need to know what fields to expect from each tool to plan downstream calls and extract relevant data.
run_update lacks guidance on error recovery and has a generic description. The tool modifies state (UPDATE/DELETE/INSERT) but the description does not clearly explain consequences or recovery steps for failed operations. No indication of which errors are retryable vs. fatal.
run_select and run_update do not document pagination or result limiting behavior. If SELECT queries return large result sets, there is no indication of how results are capped or paginated. This risks context window exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2025-06-18+ | v2 |
Execute a SELECT query against PostgreSQL and return results as rows.
Execute an UPDATE, DELETE, or INSERT query against PostgreSQL.
SQL injection risk not explicitly addressed. While the server likely uses parameterized queries internally, the tool descriptions do not mention this security property or advise users on safe SQL construction. LLMs may pass untrusted SQL directly.
Confirmation/dry-run pattern absent for destructive operations. run_update (INSERT/UPDATE/DELETE) is a destructive tool with no dry-run, confirmation, or idempotency hint. Agents may execute dangerous queries accidentally.