The server defines 7 tools with schemas and descriptions present, but quality is inconsistent. Tool naming follows verb_noun conventions (search, get, list, chat) which is good. However, descriptions vary widely in quality, some are detailed and action-oriented (kms_chat with emoji and token management details), while others are generic (kms_get_stats, kms_list_documents). Most critical gaps: output schemas are NOT documented anywhere in the source code. The kms_chat tool's description mentions 'automatically optimizes for token limits' but no output structure is specified for LLMs to parse. Parameter descriptions are present but sparse (e.g., kms_get_stats has only one parameter with a 50-char description). Error handling exists at the HTTP layer (McpError thrown on failed KMS requests) but provides minimal recovery guidance, errors like 'KMS API request failed: 500 Internal Server Error' give the LLM no actionable next step. The code shows enrichSearchResultsWithFullContent logic that fetches full document content, but no documentation of this behavior in the tool descriptions themselves. Average tool description length is ~180 chars (within baseline 194), but descriptions lack specificity about WHEN to use each tool vs. another (e.g., kms_search vs kms_intelligent_search vs kms_multimodal_search are confusing without clear differentiation). Baseline violation: ~40% of tools lack parameter count documentation; kms_multimodal_search has 4 parameters with only 3 documented in full detail.

• Document output schema for every tool. For search tools, return: {results: [{id, title, relevance_score, content_preview, source_type}], total_count, next_cursor}. For kms_chat, return: {response: string, sources_used: [...], token_usage: {input, output}, search_strategy_applied: string}. For kms_get_document, return: {id, title, content_text, transcription, metadata: {...}, created_at, updated_at}.
• Rename or differentiate the three search tools. Suggestion: keep kms_search as basic vector similarity (when you have a simple keyword query); rename kms_intelligent_search to kms_search_with_analysis (when you want detailed query breakdown and routing); rename kms_multimodal_search to kms_search_visual_content (when searching images/video frames). Update descriptions to say: 'Use this when [specific condition] vs. [other tool].'
• Add actionable error messages. Wrap KMS API errors with recovery hints: 'Threshold 0.8 too high, no results found. Try lowering threshold to 0.5 or using kms_intelligent_search for query reformulation.' For 404 on documentId, return 'Document not found. Use kms_list_documents to discover available documents.' For 500, return 'KMS service unavailable (retryable). Wait 5 seconds and retry.'
• Expand kms_get_stats and kms_list_documents descriptions to 100-150 chars. Explain WHEN to call: 'Get stats to understand KMS coverage (e.g., how many documents indexed, average document size) before bulk searches.' 'List documents to discover available content and filter by type before querying.'