Single tool 'query' has a basic schema and description but lacks depth. Description is 73 chars (below baseline 194), parameter descriptions are minimal, and no output schema is documented. The tool accepts only one parameter (sql: string) with a brief constraint note. No error handling guidance, no pagination support despite potential for large result sets, and no documentation of what fields are returned. The implementation shows good security (read-only validation, timeout handling, connection pooling) but the tool definition itself is underdeveloped for LLM consumption.

• Add a detailed output schema to the tool definition: 'Returns an object with rows (array of objects, each with column names as keys) and message (string, present only if no rows returned).'
• Expand tool description to 150-250 chars: 'Execute read-only SQL SELECT queries against the PostgreSQL database. Returns results as JSON objects with column names as keys. Useful for retrieving data, aggregations, and reports. Queries timeout after 5 seconds. Only SELECT queries are allowed.'
• Add a 'limit' parameter (integer, 1-1000, default 100) to cap result rows and prevent context window exhaustion. Document in description: 'Maximum number of rows to return. Defaults to 100. Use pagination for larger datasets.'
• Document error cases in the tool description: 'Errors: Non-SELECT queries rejected with 'Only SELECT queries allowed.' Connection failures return 'Database unavailable.' Timeouts (>5s) return 'Query timeout.' Invalid SQL returns the database error message.'
• Add a 'timeout_seconds' parameter (optional, 1-30, default 5) to let agents control query duration for long-running analytics without blocking.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry