This is a client application, not an MCP server. It consumes MCP tools (tavily-search, search) from external servers but does not define or register its own tools. The two tools listed are proxied from Tavily and DuckDuckGo MCP servers; their definitions originate elsewhere. Tool definitions are inferred from usage in mcp_client.py, not explicitly registered in this codebase. Descriptions are generic ('Search tool from Tavily MCP server...'), under 20 chars of actionable detail. Input schemas show only a 'query' string with minimal description. No output schema documented. No error handling guidance, no parameter constraints, no idempotency hints.

• Clarify that this is a client application consuming external MCP servers, not an MCP server itself. If the goal is to expose a unified search interface, wrap it in a proper MCP server with explicit tool registration.
• For each search tool, write a 50 - 150 character description explaining: what it searches (web, academic, news?), when to prefer it over alternatives, and what structure it returns. E.g., 'Search the web using Tavily. Returns ranked results with titles, URLs, and snippets. Use for current events and real-time data.'
• Add parameter constraints: query length (e.g., 1 - 500 chars), required vs. optional, and examples of good queries. Document any API rate limits or result limits.
• Document the output schema: what fields does each search result contain? Are results paginated? What is the maximum number of results returned? Include this in tool descriptions and in code comments.
• Enhance error handling: catch specific exceptions (timeout, rate limit, API error) and return actionable messages. E.g., 'Tavily API rate limit exceeded. Retry in 60 seconds or use search_duckduckgo instead.'