AgenticLakehouse exposes three tools with significant definition gaps. The tool schemas are partially visible but lack depth in parameter documentation. Two tools (tavily_search, retrieve_docs) have minimal but present descriptions; one (databricks_mcp_tools) is delegated to an external server with no direct schema visibility in this codebase. Parameter descriptions are sparse or absent. No output schemas are documented in the visible code. Error handling patterns are not evident. The server relies heavily on LangChain adapters and external tool providers, limiting direct quality assessment.

• Add explicit output schemas for all three tools. Minimum: document what fields are returned (e.g., for tavily_search, return [{title, url, snippet, source}, ...]). LLMs use schemas to plan chained calls.
• Expand tavily_search description to 80 - 150 chars: 'Search the public web for current information. Returns ranked results with title, URL, and snippet. Use when retrieve_docs lacks recent data or topic is outside training data. Does NOT search internal documents.'
• Expand retrieve_docs description to 80 - 150 chars: 'Query the internal knowledge base (vector-indexed documents). Returns ranked results with title, content snippet, and source. Use for organizational policies, documentation, or domain-specific knowledge. Limited to indexed data.'
• For retrieve_docs, clarify what is indexed (e.g., 'company policies, technical docs, past incidents') and when to fall back to tavily_search (e.g., 'when retrieve_docs returns <3 results or low confidence').
• Add limit and offset/page parameters to both search tools, with documented defaults (e.g., limit=10, offset=0). Return total_count in response so LLM knows if more results exist.
• Add error handling documentation: 'If tavily_search times out after 5s, try a shorter query or use retrieve_docs instead. If retrieve_docs returns 0 results, fall back to web search.'
• Rename databricks_mcp_tools to something more specific (e.g., query_lakehouse_sql, execute_spark_query, or scan_lakehouse_table) based on the actual operations it exposes. If it really exposes multiple disparate operations, split into smaller tools.