Single tool with minimal schema and description. execute_sql has a basic 2-property schema (query string, required) but lacks critical safety features: no parameter description beyond the name, no output schema documentation, no error handling guidance, no input validation constraints (length, pattern), and no mention of destructive consequences. Description is 54 chars, below the 194-char baseline for production tools. No pagination, no result limits, no idempotency guarantees. SQL injection risk is unmitigated at the tool interface level.

• Add explicit output schema to execute_sql: document that results are returned as CSV (header row + data rows), include field names, row count, and error format. Example: {type: 'object', properties: {columns: [string], rows: [[string]], rowCount: number, error?: string}}
• Add parameter description to 'query': 'SQL query to execute (SELECT, INSERT, UPDATE, DELETE, SHOW, DESCRIBE). Max 10000 chars. Avoid DROP, TRUNCATE, ALTER unless explicitly confirmed.'
• Implement result limits: cap SELECT results at 100 rows by default, add optional limit parameter (1 - 1000), return total_rows and has_more flag for pagination.
• Add tool annotations: mark execute_sql with destructiveHint=true (since it can INSERT/UPDATE/DELETE), add readOnlyHint=true variant for SELECT-only queries, or split into execute_sql_read and execute_sql_write.
• Enhance error messages: categorize errors as retryable (connection timeout, lock wait) vs user-fixable (syntax error, permission denied) vs fatal (database offline). Return actionable guidance: 'Syntax error near line 5. Check column names and table references.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry