Server implements 5 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-60 chars, below the 50-200 char baseline for LLM optimization) and input schemas are present but minimal. omv_shell and omv_call expose dangerous operations (IRREVERSIBLE, WRITE) with no confirmation patterns, dry-run support, or permission gates. Parameter descriptions are sparse or missing entirely (e.g., 'params' in omv_call lacks guidance on valid values). No output schemas documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. Tool naming follows verb_noun convention (good), but descriptions are too terse to guide LLM selection effectively.

• Expand tool descriptions to 100-150 chars. E.g., omv_shell: 'Execute a shell command on the NAS. Use for system administration tasks not available via RPC (e.g., file operations, service restarts). Returns stdout/stderr. Irreversible, confirm before executing.'
• Document output schemas for all tools. E.g., omv_list_services returns {services: [{name: string, description: string}], total: number}. Include this in docstrings or a separate schema file.
• Add parameter descriptions for 'params' in omv_call. E.g., 'Parameters object passed to the RPC method. Structure depends on the method, call omv_list_methods to see available methods and their signatures.'
• Implement confirmation pattern for omv_shell and omv_call. Add a 'dry_run' parameter or require a separate 'confirm_*' tool to execute after preview. Prevents accidental destructive operations.
• Add error categorization and recovery hints. E.g., 'SSH connection failed (retryable). Check SSH_HOST, SSH_USER, SSH_KEY env vars and network connectivity.' or 'Invalid service name. Available services: [list]. Call omv_list_services() to discover.'

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

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