Three tools with basic verb-noun naming (list_, search_, retrieve_) but significant quality gaps. All tools have descriptions, but they are generic and lack actionable context (avg ~50 chars, well below the 194-char baseline). Input schemas are present but minimal: list_sources_tool has empty input {}; search_documents_tool and retrieve_chunks_tool have only 'question' (string) and 'top_k' (integer, default 3) with minimal parameter descriptions. No output schemas documented. No error handling guidance, no parameter constraints (e.g., top_k range), no indication of what fields are returned. Tools lack idempotency hints, permission declarations, and recovery guidance. The handlers.py implementation shows basic functionality but no validation, rate limiting, or error classification.

• Document output schemas for all three tools. Example for search_documents_tool: 'Returns {"question": string, "sources": [string], "chunks": [string]}'. This lets LLMs plan downstream calls and extract the right fields.
• Add range constraints to top_k parameter: 'Number of top results to return (1 - 50, default 3). Larger values increase latency and token cost.'
• Wrap RAG operations in try-except blocks. Catch OpenAI API errors (rate limits, auth failures) and return structured error responses like '{"error": "OpenAI API rate limited. Retry in 60 seconds."}'.
• Expand tool descriptions to 100 - 200 characters. Example: 'Search indexed documents using semantic similarity. Returns matching source files and text chunks. Call this when the user asks a question about the data. Use retrieve_chunks_tool for structured chunk metadata.'
• Add input validation in handlers.py: validate top_k is in range [1, 50], validate question is non-empty, and return clear error messages if constraints are violated.