This server has clear tool naming and comprehensive input schemas, but suffers from missing output schema documentation and lacks error guidance that would help LLMs recover from failures. Both tools follow the verb_noun naming convention well ('tavily-search', 'tavily-extract'). Input parameters are well-typed with proper enums and defaults. However, the server exposes no documented output schema structure, only an implicit TavilyResponse model that LLMs cannot see. Error handling is generic ('Tavily API error' with no recovery hints). Parameter descriptions are present but some lack format constraints (e.g., 'query' could be more specific about length/character limits).

• Document the output schema for both tools. Define what fields TavilyResponse will contain (query, follow_up_questions, answer, images list with url/description, results list with title/url/content/score/published_date). This allows LLMs to plan what data they can extract.
• Replace generic error messages with actionable guidance. Example: 'Tavily API error (status 429): Rate limit exceeded. Retry after 60 seconds.' or 'Invalid query format. Tavily requires 1-500 character search queries.'
• Add format constraints to the 'query' parameter description: 'Search query (1-500 characters, alphanumeric and common punctuation).'
• Document max_results upper bound in tool description: 'Returns up to max_results results (1-20, default 10). Larger result sets may exceed token limits.'
• Enhance tool descriptions with WHEN-to-use guidance. Example for tavily-search: 'Use this to find current web content about a topic. Use basic search for quick summaries, advanced for deep research. Use news topic for recent events, general for evergreen info.' For tavily-extract: 'Use this after tavily-search to fetch full content from specific URLs.'
• Add parameter relationship documentation. Note that include_image_descriptions only applies when include_images=true, and raw_content is only available with advanced search_depth.