Scoring was not performed

• Add full parameter descriptions to every tool. For each parameter, specify: what it controls, valid values/range, expected format, and whether it's optional. E.g., 'limit: Maximum number of results to return (1 - 100, default 20).'
• Document output schemas for all tools. Include field names, types (string, integer, array, object), and what each field represents. E.g., 'Returns: {results: [{id: string, score: float, content: string}], total: integer, next_cursor?: string}'.
• Expand tool descriptions to 100 - 200 chars. Include: WHAT the tool does, WHEN to use it instead of similar tools, and any prerequisites. Example: 'Search the code database using hybrid BM25+vector search. Use when you need both keyword matches (variable names) and semantic similarity (design patterns). Returns top K snippets by relevance score.'
• Add enum constraint or validation for hybrid_search search_type parameter. Define valid values ('code' | 'config' | 'documentation') in schema or validate in implementation with clear error guidance.
• Implement confirmation or dry-run pattern for clear_collection. Either require explicit confirmation before clearing, or add a 'dry_run' boolean parameter that previews what would be deleted without executing.
• Clarify index_directory behavior: does it skip unsupported files or fail? What are the supported extensions? Does it respect .gitignore? Add this to the tool description.
• Document search_* vs hybrid_search trade-offs. Explain why an agent should use hybrid_search (combines BM25 keyword + vector semantic search) vs dedicated search_code/config/documentation tools (likely vector-only). This helps LLMs reason about tool selection.