clum-mcp has well-structured tool definitions with complete JSON schemas and consistent descriptions. All 9 tools have input schemas with typed parameters and descriptions. However, descriptions are brief (10-50 chars) and lack actionable context for LLM selection. Parameter descriptions are minimal, many lack guidance on format, constraints, or when to use them. Error handling and recovery guidance are absent. Output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions (READ_ONLY vs WRITE). Naming is clear and verb-driven (list_, get_, exec, push_, pull_, forward_, etc.), following conventions well.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. E.g., 'List all hosts registered in the bridge registry. Returns host names, connection status, and last-seen timestamp. Call this first to discover available targets before exec or push_file.'
• Add tool annotations: mark exec, push_file, forward_port with destructiveHint=true; mark list_*, get_*, pull_* with readOnlyHint=true. This enables safer agent planning and prevents accidental destructive operations.
• Document output schemas for all tools. E.g., list_hosts returns {hosts: [{name: string, status: 'online'|'offline', last_seen: ISO8601}], total: number}. This lets LLMs chain tools correctly.
• Enhance parameter descriptions with constraints and examples. E.g., timeout_secs: 'Command timeout in seconds (1-3600, default 300). Increase for long-running operations; decrease to fail fast on hung commands.'
• Add error handling guidance. E.g., exec should document: 'Returns exit_code and stderr. If exit_code != 0, the command failed, check stderr for details. Retryable errors (timeout, connection reset) are marked retryable=true.'