Server exposes 7 read-only tools with basic schemas and descriptions. All tools have names starting with action verbs (list_, get_, search_, symptom_lookup) and non-empty descriptions (range 50 - 180 chars). Input schemas are present with type declarations. However, descriptions lack LLM-optimized guidance on WHEN to use each tool vs. alternatives, parameter descriptions are minimal (e.g., 'Topic name' without enum values), and output schemas are not documented. No error handling guidance, no recovery paths. Naming is clear but generic ('get_readme', 'get_script', 'get_cheatsheet' could be more specific about content type). Tool composition is sound, each does one thing, but descriptions do not explain dependencies or sequencing (e.g., 'call list_topics first to orient').

• Convert topic name parameters to formal JSON Schema enums: {"type": "string", "enum": ["01-hardware", "02-disk-io", "03-network-io", "04-memory", "05-performance", "06-app-debugging", "07-network-debug"]} instead of listing values in description text.
• Document output schemas for all tools. E.g., list_topics returns {"topics": [{"name": string, "description": string}]}, search returns {"results": [{"file": string, "line_number": integer, "snippet": string}], "total": integer}.
• Add WHEN-to-use guidance to descriptions: 'Call list_topics first to see available topics. Then use get_readme for full documentation, list_scripts to see scripts in a topic, or search() to find content by keyword across all topics.'
• Include error recovery hints: 'If topic not found, call list_topics() to see valid options. If search returns no results, try a broader keyword or use symptom_lookup() for symptom-specific searches.'
• Clarify the distinction between search() (grep across READMEs and script headers) and symptom_lookup() (search symptom table rows) in both descriptions so LLMs know which to call for different query types.