14 tools with basic schemas and minimal descriptions. Most tools lack parameter descriptions entirely (e.g., config, instructions have empty input {}). Descriptions are generic and under 100 chars. No output schemas documented. No error handling guidance. Tool names follow verb_noun pattern (get_*, execute_*) but descriptions do not explain WHEN to use each tool or what distinguishes similar ones (e.g., execute_reader vs execute_nonquery). No pagination support visible. Security-sensitive tools (execute_nonquery, execute_routine, add_row) lack confirmation/dry-run patterns. Baseline: 549 production tools average 194 chars description + 72 chars per param; this server averages ~50 chars description, 0 chars per param.

• Add parameter descriptions to all tools. E.g., 'schema: Name of the database schema (e.g., public, dbo). Required.' and 'tableName: Name of the table within the schema. Required.'
• Document output schemas for all tools. E.g., get_tables returns [{table_name: string, schema: string, row_count: int, created_at: ISO8601}]. Include pagination if applicable.
• Add confirmation/dry-run support to execute_nonquery, execute_routine, and add_row. E.g., add a 'dry_run: boolean' parameter that returns the query plan without executing, or require explicit 'confirm: true' for destructive operations.
• Expand tool descriptions to 100-200 chars explaining WHEN to use each. E.g., 'execute_reader: Executes a SELECT query and returns results as a structured table. Use this for read-only queries. Returns up to 1000 rows; use pagination for larger result sets.'
• Add error handling guidance. E.g., 'If the query fails, the error message will include the SQL syntax error or constraint violation. Common fixes: check table/column names exist, verify data types match, ensure foreign key constraints are satisfied.'