Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. rag_index has a single required parameter with minimal description; code_search has two parameters but lacks detail on output structure. Neither tool description explains error handling, prerequisites, or recovery paths. Descriptions are adequate length (60-80 chars) but lack actionable context for LLM selection. No tool annotations (readOnlyHint/destructiveHint). Parameter descriptions are sparse, 'Search query' and 'Number of top results' lack format constraints, valid ranges, or examples of what constitutes a good query. Output schemas are not documented in the tool definitions, forcing LLMs to infer result structure. Risk annotations (WRITE, READ_ONLY) are present but not integrated into descriptions.

• Document output schemas for both tools. Example: rag_index returns {success: bool, file_count: int, index_size_mb: float, error?: string}. code_search returns {results: [{file: string, score: float, snippet: string}], total_matches: int}.
• Add parameter constraints to code_search: top_k must be 1 - 100 (default 5); query must be 1 - 500 characters; explain tokenization (whitespace-split, case-insensitive).
• Clarify rag_index behavior: 'Walks directory recursively, chunks code by function/class boundaries, builds a new BM25Okapi index (overwrites any existing index at the same path). Idempotent, safe to call multiple times.'
• Add error recovery guidance: 'If rag_index fails with permission error, ensure the process has read access to the directory. If code_search returns no results, try a shorter query or broader keywords.'
• Add tool annotations to schemas: rag_index with destructiveHint=true (overwrites index), code_search with readOnlyHint=true (no side effects).