HTB-CLI has 10 tools with complete input schemas and descriptions. Naming follows verb_noun convention (get_, list_, search_, submit_). Descriptions are present (avg ~120 chars) but lack actionable context for LLM selection, they state WHAT but not WHEN or WHY. Parameters are typed and described, but lack enums for constrained values (e.g., 'os', 'difficulty', 'category' accept free-form strings instead of enums). Output schemas are not documented, LLMs cannot predict response structure. Error handling returns generic strings without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions (READ_ONLY vs WRITE). Composition is sound, each tool has one responsibility and output IDs chain to downstream tools.

• Add output schema documentation for all tools. For list_machines, document: {machines: [{id, name, os, difficulty, rating, points, state, user_owned, root_owned}], page, total_pages, total}. LLMs need to know what fields to extract.
• Convert 'os', 'difficulty', 'category' parameters to enums. E.g., os: enum[linux, windows, freebsd, solaris], difficulty: enum[easy, medium, hard, insane]. Prevents hallucinated invalid values.
• Add tool annotations via rmcp's tool macro. Mark get_* and list_* with readOnlyHint=true. Mark submit_challenge_flag and start_challenge with destructiveHint=true. Agents need to know which operations are safe to retry.
• Enhance error messages with recovery guidance. Instead of '.map_err(|e| e.to_string())', return structured errors: {error: 'Challenge not found', suggestion: 'Try search() to find the challenge ID first'}. Enables agent self-correction.
• Expand descriptions to 80-150 chars with WHEN/WHY context. E.g., 'search' → 'Search for machines, challenges, or users by name or keyword. Use this to discover resources before calling get_machine_info or get_challenge_info. Returns up to 20 results per category.'

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

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