Server defines 8 tools with basic descriptions and input schemas. All tools are read-only, which is good for safety. However, descriptions are generic and lack LLM-optimization guidance (e.g., 'Execute read-only SQL queries' doesn't explain WHEN to use this vs describe_table). Parameter descriptions are minimal or absent. Output schemas are not documented. No error handling guidance. Tool naming is clear (verb_noun pattern), but composition could be tighter, execute_sql, list_tables, describe_table, get_schema_overview, and get_table_sample all operate on the same database resource and could benefit from clearer differentiation in descriptions.

• Document output schemas for all tools. E.g., 'Returns: {rows: [{col1: string, col2: int, ...}], rowCount: int}' for execute_sql. This enables LLMs to plan chained calls and extract IDs for follow-ups.
• Expand tool descriptions to 50-200 chars with clear differentiation. E.g., execute_sql: 'Run custom SELECT queries when you need specific data not covered by describe_table or get_table_sample. Returns raw rows.' vs describe_table: 'Get column names, types, and constraints for a table. Use this to understand schema before writing SQL.'
• Add parameter constraints and ranges. E.g., 'limit (integer, 1-1000): Maximum rows to return. Defaults to 20.' This prevents LLMs from passing absurd values.
• Add error handling guidance in tool descriptions. E.g., 'If the query times out, try limiting the result set or adding WHERE clauses. If syntax fails, check column names with describe_table first.'
• Consider consolidating database discovery tools. Offer a single 'explore_database' tool that accepts a mode parameter (list_tables, describe_table, sample_data) to reduce cognitive load on the LLM.