Three tools with complete schemas and basic descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have descriptions (10-100 chars), but descriptions lack actionable context for LLM selection. Parameters are typed with enums where appropriate, but lack descriptions explaining their purpose and constraints. No output schemas documented. Error handling is minimal, generic error messages provide no recovery guidance. Tools follow verb_noun naming convention but descriptions are too terse to guide LLM reasoning about when to use each tool vs. alternatives.

• Add 50-150 character descriptions to every parameter. Example: 'analysisType: Which aspect to analyze. Use "configuration" to review settings, "performance" for query/index analysis, "security" for access control and encryption checks.'
• Expand tool descriptions to 100-200 chars with WHEN guidance. Example: 'Analyze PostgreSQL database configuration and performance. Call this to review settings, identify bottlenecks, or audit security posture. Returns structured analysis with findings and recommendations.'
• Document output schemas in tool descriptions or as structured examples. Specify: 'Returns {analysis_type: string, findings: [{severity: string, category: string, description: string, recommendation: string}], summary: string}'
• Implement error classification in CallToolRequestSchema handler. Return structured errors: {error: string, category: 'retryable'|'user_fixable'|'fatal', suggestion: string}. Example: 'Connection failed: invalid host. Verify connectionString format: postgresql://user:pass@host:port/db'
• Move connectionString to server-side configuration. Accept a 'database_name' or 'connection_profile' parameter instead, and resolve it to the actual connection string via environment variables or a config file. This prevents credential leakage in logs.