Server exposes 15 well-named Helm tools with consistent verb_noun naming (helm_release_*, helm_install_*, etc.). All tools have descriptions (10 - 200 chars, within baseline 194 avg). Input schemas are present and typed for all tools. However, output schemas are NOT documented, responses are dumped as JSON strings without field-level documentation, forcing LLMs to parse unstructured text. Parameter descriptions are minimal (5 - 15 chars typical); many lack format/constraint guidance. Error handling is generic (@tool_errors decorator) with no recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). Destructive tools (uninstall, rollback) require confirmation strings but lack dry-run support.

• Document output schemas for all tools. Define field names, types, and meanings. E.g., helm_release_status should document: {status: string, chart: string, app_version: string, chart_version: string, notes: string}.
• Expand parameter descriptions to 50 - 100 chars. Include format, constraints, and usage hints. E.g., 'namespace: Kubernetes namespace name (alphanumeric + hyphens, max 63 chars; omit for default namespace).'
• Add tool annotations: mark READ_ONLY tools with readOnlyHint=true, WRITE tools with destructiveHint=false, DESTRUCTIVE tools with destructiveHint=true. This enables client-side safety warnings.
• Implement structured error responses with recovery guidance. E.g., 'Release not found: try helm_list_releases() to see available releases' instead of a stack trace.
• Add dry-run support to helm_install_release and helm_upgrade_release (already present via apply=false). Document that apply=false is the safe default and explain when to set apply=true.