Three tools with clear action verbs and basic schemas, but significant gaps in parameter descriptions and output documentation. All tools have descriptions (10-100 chars), but descriptions are generic and lack context for LLM selection. Input schemas present with types and defaults, but parameter descriptions are minimal (e.g., 'The search query string' lacks format/constraint guidance). No output schema documented. Error handling absent, no recovery guidance or categorization. Tools are read-only and well-scoped, but lack the depth expected for production use.

• Document output schema for all tools. Example: 'Returns {status: string, query: string, answer?: string, documents: [{id, text, metadata}], latency: {retrieval_ms, reranking_ms, generation_ms}}'.
• Expand parameter descriptions with constraints and guidance. E.g., 'top_k (1-20, default 3): Number of documents to retrieve. Use 3-5 for quick answers, 10-20 for comprehensive research.'
• Clarify tool selection criteria. E.g., answer_query: 'Use when you need a synthesized answer. Use search_documents if you only need raw documents without synthesis.'
• Add error handling with recovery guidance. Wrap _post_json calls in try-except, categorize errors (timeout, not_found, invalid_query), and return actionable messages like 'Query too long (max 500 chars). Try a shorter query or use search_by_metadata with filters.'
• Pass metadata filters to the backend. Modify search_by_metadata to send category and filetype to /search endpoint instead of filtering client-side.