An MCP server providing tools for PostgreSQL database connections, queries, and data visualization with natural language SQL generation
This server exhibits significant quality gaps across naming, descriptions, schemas, and error handling. While 8 tools are registered with basic schemas, most lack adequate descriptions for LLM guidance. Tool naming is inconsistent (some verbs missing). Parameter descriptions are sparse or missing entirely. No structured error handling or recovery guidance. No output schemas documented. Several tools show signs of inferred definitions rather than explicit registration. The server mixes unrelated concerns (PostgreSQL introspection, hotel booking) without clear composition patterns. No security annotations, permission gates, or audit trails visible.
Book a hotel by setting its booked status to true.
Cancel a hotel booking by setting its booked status to false.
Returns sample data from a specified table with configurable limit.
Returns the schema of a table including column names and data types.
Returns a list of all user-defined tables in the database.
Search for hotels by location.
Search for hotels by name pattern.
Missing output schemas. No tool documents what fields it returns or how downstream tools should consume the response. LLMs cannot plan multi-step operations without knowing response structure.
Inadequate parameter descriptions. Many parameters lack guidance on expected values, formats, or constraints. E.g., 'limit' in get-sample-data has a description but no range bounds (1-1000?). 'table_name' and 'location' lack format hints.
No error handling or recovery guidance. Code shows generic exception handling (e.g., HTTPException 500 in mcp_fastapi/server.py) with no actionable error messages. LLMs receive 'Database connection failed' with no guidance on retry, fallback, or user action.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 24 | - | v1 |
Update hotel booking dates (check-in and/or check-out dates).
Tool definitions split across multiple files with inconsistent patterns. PostgreSQL tools (list-all-tables, get-table-schema, get-sample-data) in server/app.py; hotel tools scattered across mcp_fastapi/hotel_agent_ver1.py and google-adk/hotel_agent.py. No single tool registry or canonical registration visible.
Unsafe SQL in get-sample-data. Code shows f"SELECT * FROM {table_name} LIMIT %s", table_name is user-supplied and not validated. Vulnerable to SQL injection. Use parameterized query or whitelist tables.
No idempotency or confirmation for write operations. Tools 'book-hotel', 'cancel-hotel', and 'update-hotel' modify state but have no dry-run, confirmation, or idempotency token. Agents retrying on ambiguous failures risk duplicate bookings.
No permission checks or audit trails. Write operations (book-hotel, cancel-hotel, update-hotel) accept a 'user_id' parameter but do not verify the user has authority to book/cancel. No logging of who performed what action when.
Mismatch between tool documentation and implementation. Tool descriptions are minimal (20-50 chars), failing to answer WHAT, WHEN, or WHY. E.g., 'Search for hotels by name pattern' does not explain case sensitivity, partial match behavior, or required vs optional fields.
Composition issue: 8 tools operate on unrelated domains (database schema introspection + hotel bookings) without clear separation or precedence rules. LLMs cannot reason about tool selection when the server mixes metadata discovery (list-all-tables) with domain operations (book-hotel).