Three tools with basic schemas and descriptions, but significant gaps in parameter documentation, error guidance, and LLM-optimized descriptions. All tools are read-only database queries with minimal context. Descriptions are present but generic (10-50 chars). No parameter descriptions for critical inputs like 'table_name' and 'sql'. Error handling returns unstructured error strings instead of actionable recovery guidance. No tool annotations (readOnlyHint, etc.). Tool names follow verb_noun pattern (list_, get_, execute_) but lack specificity about what data they operate on.

• Add parameter descriptions to get_schema and execute_query. E.g., 'table_name: The name of the table to query (string, case-sensitive, must exist in database)' and 'sql: A SELECT query string (max 10000 chars, must start with SELECT, no DDL keywords allowed)'.
• Expand tool descriptions to 100-200 chars explaining WHAT, WHEN, and WHAT IT RETURNS. E.g., 'Returns column names and types for a given table. Call this after list_tables to understand table structure before writing queries.'
• Replace error strings with structured error objects: {"error": "<message>", "type": "validation|not_found|syntax", "recovery": "<hint>"}. E.g., 'Query contains blocked keyword: DROP. Only SELECT queries are allowed. Try removing DROP and rewriting as a SELECT.'
• Add readOnlyHint: true to all three tools in schema to signal to LLM that these are safe to call without confirmation.
• Document output schemas explicitly. E.g., list_tables returns List[str]; get_schema returns List[str] (format: 'column_name type'); execute_query returns List[Dict[str, Any]] (rows as key-value pairs).