Skip to content

Conversation

@NormallyGaussian
Copy link

@NormallyGaussian NormallyGaussian commented Nov 12, 2025

Summary

Adds Parallel web search as an alternative to Tavily and exposes both as separate tools.

Design Decision: Separate Tools

We expose tavily_search() and parallel_search() as separate tools rather than a unified interface because:

Different Input Signatures:

  • Tavily: query: str - single search query
  • Parallel: queries: list[str], objective: str | None - multi-query with optional goal

Different Output Formats:

  • Tavily: Includescontent field (string), relevance score and query
  • Parallel: Includes excerpts field (array of markdown strings), publish_date, and search_id

Different Use Cases:

  • Tavily: Single-query search with topic filtering ("general", "news", "finance")
  • Parallel: Multi-query research optimized for LLM synthesis

Normalizing into one interface would lose functionality or create a confusing API.

Implementation

  • Conditionally registered based on API keys
  • Tavily still takes priority when both keys are set
  • Separate approval configs for each tool

Testing

Added some tests; they all pass. I also tested manually with the Parallel API key enabled.

image

Breaking Changes

None. Existing web_search() maintained as backward-compatible wrapper which still uses Tavily.

@eyurtsev
Copy link
Collaborator

@NormallyGaussian we're holding off on additional integrations for now until we expose a proper way to configure the integrations. I'll keep the PR open and will ping here once ready

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants