Critical failures across all dimensions. Three tools with destructive/sensitive operations expose passwords as plaintext parameters (violates pattern:secret-injection). Descriptions are minimal (10-50 chars, well below 194-char baseline). No input validation guidance, no error recovery hints, no output schemas documented. executeQuery lacks authentication but has no description of access controls. Tool names are verb-based but lack clarity on risk levels. No parameter constraints (enums, ranges, formats). This server is unsuitable for production use without major redesign.

• Move password parameter to server-side configuration (environment variable or Spring properties). Inject credentials at runtime, never expose in tool params. Update tool signatures to remove 'password' entirely.
• Expand descriptions to 150 - 250 chars. Example: 'executeRawSql: Execute arbitrary SQL statements (INSERT, UPDATE, DELETE, DDL). Use when executeQuery or executePreparedSql cannot express the operation. Returns affected row count or query results as JSON array. Requires admin password.'
• Document output schemas for each tool. Example: 'executeQuery returns {success: boolean, rows: [{column1: string, column2: number, ...}], rowCount: number, executionTimeMs: number}'.
• Add parameter constraints: 'sql' must be non-empty string; 'params' array elements must match placeholder types (string, number, boolean); 'clause' must not contain DROP, TRUNCATE, or ALTER keywords.
• Add error recovery guidance: 'If query fails with "column not found", call executeQuery with correct column names. If permission denied, verify database user has required grants. Syntax errors: check SQL for typos and reserved keywords.'