Single tool with minimal definition quality. execute_sql has a basic schema with one required parameter (query: string), but lacks critical safeguards for a destructive operation. Description is generic (34 chars, below 50-char baseline for clarity). No parameter constraints, no output schema documentation, no error recovery guidance. Tool accepts arbitrary SQL including DELETE/DROP without confirmation, dry-run, or permission checks. No idempotency markers. Resource implementation shows SQL injection vulnerability in read_resource (line: `SELECT * FROM {table} LIMIT 100` with unsanitized table name). Logging present but does not compensate for missing safety patterns.

• Add parameterized query support or query validation to prevent SQL injection. Whitelist allowed operations (SELECT, INSERT, UPDATE) and reject DELETE/DROP/TRUNCATE unless explicitly enabled.
• Document output schema: specify that SELECT queries return CSV-formatted text with headers, non-SELECT queries return row count. Include example output in description.
• Implement error classification: return structured errors with category (e.g., 'syntax_error', 'permission_denied', 'timeout') and actionable recovery hints (e.g., 'Check query syntax' or 'Try search_tables() to list available tables').
• Add a dry_run parameter (boolean, default false) to execute_sql. When true, parse and validate the query without executing it. This prevents accidental destructive operations.
• Enhance parameter description: 'SQL query to execute on Dameng database. Supports SELECT, INSERT, UPDATE. Use search_tables() first to discover available tables. Queries are executed immediately, use dry_run=true to validate without executing.'

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

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