The problem
Search is fragmented in more dimensions than most agent builders account for up front: provider, index, retrieval style (keyword vs. semantic), cost per call, freshness, and public web vs. private corpus. Today, that means picking one provider and living with its blind spots, or maintaining separate integrations against several — one for fast SERP lookups, another for semantic discovery, a third for your own support tickets or product docs — each with its own auth, schema, and failure modes.
A universal toolset
The plan is a small, consistent tool surface an agent calls regardless of what's underneath it:
search_web
search_index
research
fetch
crawl
create_index
add_to_index
list_indexesIllustrative, planned usage — not a live API:
search_web(query="cloud GPU pricing changes 2026", provider="auto", freshness="30d")search_index(query="refund policy for enterprise plans", index="my-docs")Auto-routing
The core idea behind provider="auto" is query → intent → best-fit source: instead of an agent builder hardcoding one provider for every query type, the router picks the source that fits the query's intent, optimizing across quality, cost, latency, and freshness, with automatic fallback if a provider fails or times out.
| Query type | Likely routing category |
|---|---|
| Current news or breaking coverage | Fast, freshness-tuned web search (e.g. Brave, Bing) |
| SERP inspection (rankings, ads, local pack) | Structured Google SERP data (e.g. SerpStack) |
| Semantic or conceptual discovery | Neural/embedding-based search (e.g. Exa) |
| Multi-step research with synthesis | Agent-native search with answer summaries (e.g. Tavily) |
| Private corpus (your own docs, tickets, product data) | Your private index only |
| Private + public context together | Private index plus live web, merged |
Bring your own data
Beyond the open web, the same interface is meant to let an agent search a company's own documents, support tickets, or product data — a private, agent-searchable index you create and populate through the same small tool surface, without standing up separate retrieval infrastructure or exposing that data to a public search index.
Status
This is a pre-launch concept, not a working product. There is no live SearchAPIs MCP router today. What exists today is the SerpStack integration and the SearchAPIs directory content on this site — the unified MCP router described above is what we're building next.
Interested in early access?
Email us and we'll follow up when there's something to try.
Curious how Search MCP servers work today? Read the guide → Or see today's provider comparisons in the providers directory.