Skip to content

feat: add Tavily as middle-tier search provider alongside Exa - #3

Open
tavily-integrations wants to merge 1 commit into
elad12390:mainfrom
Tavily-FDE:feat/tavily-migration/exa-provider
Open

feat: add Tavily as middle-tier search provider alongside Exa#3
tavily-integrations wants to merge 1 commit into
elad12390:mainfrom
Tavily-FDE:feat/tavily-migration/exa-provider

Conversation

@tavily-integrations

Copy link
Copy Markdown

Summary

Adds Tavily as a configurable search provider that slots in between Exa and SearXNG in the auto provider chain. When Exa is unavailable or quota-exhausted, the system now tries Tavily before falling back to SearXNG.

This is an additive change — all existing Exa functionality and SearXNG fallback behavior is preserved.

Changes

New file: src/searxng_mcp/tavily.py

  • TavilySearcher class with has_api_key() guard and async search() method
  • Uses AsyncTavilyClient from tavily-python SDK
  • Returns standard SearchHit objects, consistent with Exa and SearXNG searchers

Modified: src/searxng_mcp/server.py

  • Import and instantiate TavilySearcher
  • In unified_search() auto dispatch: added Tavily availability check between Exa and SearXNG
  • Added "tavily" as a valid explicit provider option

Modified: src/searxng_mcp/config.py

  • Added TAVILY_API_KEY environment variable

Modified: pyproject.toml

  • Added tavily-python>=0.5.0 to dependencies

Dependency changes

  • Added tavily-python>=0.5.0

Environment variable changes

  • Added TAVILY_API_KEY — set to enable Tavily search provider

Notes for reviewers

  • Exa remains the highest-priority provider in auto mode; Tavily only activates when Exa is unavailable or exhausted
  • The "tavily" provider value can also be used explicitly via SEARCH_PROVIDER=tavily
  • exa.py is untouched per the migration plan

Automated Review

  • Passed after 1 attempt(s)
  • Final review: The exa-provider migration unit correctly implements Tavily as a middle-tier fallback between Exa and SearXNG in the 'auto' provider chain. The TavilySearcher class is well-structured and follows the existing ExaSearcher pattern. The fallback logic in unified_search is correct for all provider modes ("exa", "tavily", "searxng", "auto"). All four files listed in the migration plan are addressed. The Tavily SDK usage (AsyncTavilyClient, response parsing via response.get("results", []), parameter names) is accurate. A few minor issues exist but none are blocking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant