Single tool 'query_postgres' has a basic description but critical gaps in schema documentation, parameter descriptions, and error handling. The tool accepts arbitrary SQL strings with no input validation, poses SQL injection risks, and lacks output schema documentation. Description is minimal (67 chars) and does not explain when to use the tool, what it returns, or prerequisites. No parameter description for the 'query' field itself. Error handling returns raw exception strings to the LLM, providing no recovery guidance.

• Add a detailed parameter description for 'query': 'SQL SELECT query string (read-only; no INSERT, UPDATE, DELETE, or DROP allowed). Max 5000 chars. Use parameterized queries to prevent injection.'
• Document the output schema: 'Returns {"rows": [<row_object>, ...], "row_count": <int>} where each row_object is a dict with column names as keys and values as strings, numbers, booleans, or null.'
• Implement input validation: reject non-SELECT queries, enforce a max result limit (e.g., 100 rows), and use parameterized queries or query parsing to prevent SQL injection.
• Improve error handling: categorize errors (e.g., 'syntax_error', 'connection_error', 'timeout') and return actionable messages like 'Syntax error in query. Check column names and table names.' instead of raw exceptions.
• Add pagination support: accept 'limit' (1 - 100, default 20) and 'offset' parameters, and return 'total_rows' and 'has_more' in the response so the LLM can fetch large result sets incrementally.