Single tool 'query_postgres' has critical deficiencies. Description is present but minimal (89 chars, below 194-char baseline). Input schema exists but lacks proper JSON Schema structure, only a bare string type with minimal description. No output schema documented. No error handling guidance. No parameter validation rules or constraints. Tool accepts arbitrary SQL, creating SQL injection risk. No pagination, result limits, or structured output guidance. Naming is acceptable (verb_noun form) but tool is dangerously underspecified for production use.

• Add explicit output schema: document that 'rows' is an array of objects with typed fields (string, number, boolean, null). Specify how dates, decimals, and special types are serialized.
• Implement parameterized queries using psycopg2 placeholders (%s) to prevent SQL injection. Accept 'query' and 'params' separately, or use a safer query builder.
• Add 'limit' and 'offset' parameters (default limit=20, max=1000). Return total_count and has_more in response to enable pagination.
• Enhance error messages: categorize as 'invalid_query' (user-fixable), 'connection_error' (retryable), or 'timeout' (retryable). Include the invalid query snippet and suggestion to check syntax.
• Expand parameter description to 100+ chars: explain format, constraints, and examples of valid queries. State that only SELECT is allowed (if true) and that results are read-only.