Server has 5 tools with explicit schemas and descriptions. Naming follows verb_noun convention (check_, validate_, restore_, verify_, get_). Descriptions are present and contextual (avg ~150 chars), meeting baseline minimums. However, parameter descriptions are sparse or generic, most lack detail on format, constraints, or valid ranges. Output schemas are undocumented; LLMs cannot predict response structure. Error handling is minimal; tools return text blobs without structured guidance. Security concern: connection_string parameter exposes PostgreSQL credentials in tool calls, violating secret-injection pattern. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels.

• Move connection_string from tool parameter to server-side environment variable (e.g., SUPABASE_CONNECTION_STRING). Accept only project_ref and let the tool resolve credentials internally. This prevents secrets from entering agent traces.
• Add output schema documentation to each tool. Example for restore_backup: 'Returns {success: boolean, duration_ms: number, rows_affected: number, error?: string}'. This enables LLM response parsing and tool chaining.
• Enhance parameter descriptions with format constraints. Example: 'file_path: Absolute or relative path to .sql backup file (must exist, not gzipped, <1GB)'. Add enums or regex patterns where applicable.
• Declare tool risk levels via annotations in index.ts: add destructiveHint: true to restore_backup, readOnlyHint: true to check_prerequisites and verify_restoration. This guides agent safety reasoning.
• Implement structured error responses: return {success: false, error_code: 'MISSING_PSQL', error_message: '...', recovery_steps: ['Install psql via...', 'Verify with psql --version']} instead of plain text. Categorize errors as retryable, user-fixable, or fatal.