Three well-named, read-only tools with clear descriptions (avg 156 chars, within baseline 194). All tools have complete input schemas with proper JSON Schema structure and type definitions. search_notes includes helpful constraints (limit 1-25). However, output schemas are entirely undocumented, LLMs cannot predict response structure. Parameter descriptions are minimal (e.g., 'Natural language or keyword query' lacks format guidance). No error recovery hints or actionable error messages. Missing tool annotations (readOnlyHint). Composition is sound: tools chain logically (search → read → list). No security issues detected (read-only, no secrets).

• Document output schemas for all three tools. Example: search_notes returns {passages: [{path, line, heading, score, text}], total_count}. read_note returns {content: string, path, last_modified}. list_notes returns {documents: [{path, chunks, headings}]}.
• Add readOnlyHint: true to all three tool schemas to signal safety to clients and enable filtering by destructiveness.
• Enhance parameter descriptions with constraints: 'query: Natural language or keyword query (max 500 chars, any language).' 'path: Relative path from index root (no ../ traversal, forward slashes only).'
• Add error recovery hints to descriptions: 'If no results, try broader keywords or call list_notes() to explore available documents.' 'If read_note fails with FileNotFoundError, verify the path from search_notes output.'
• Document the BM25 ranking algorithm and score range in search_notes description so LLMs understand result ordering and confidence.