fatwang2/search2ai

What it solves

AI agents and chat clients need up-to-date search and page content, but relying on a single provider means being at the mercy of rate limits, timeouts, and outages. search2ai lets you configure multiple search and extraction services and automatically falls back to the next one when a provider fails, so your application gets consistent results without hardcoding provider logic.

How it works

The project provides several integration paths: a local MCP server (stdio) for AI clients, a standalone HTTP service, a JavaScript/TypeScript library, and mountable Hono routes. You configure provider keys or URLs via environment variables, and define fallback chains per operation (search, news, crawl). When a request comes in, the gateway tries providers in order, returns the first successful response, and reports warnings for failures. Results are normalized to a common structure (title, url, snippet, optional date and content). An optional chat proxy lets model providers that support tool calling perform web searches during conversations. There are also compatibility endpoints that let existing SDKs (e.g., for Exa, Tavily, SearXNG) point at this gateway with minimal changes.

Who it's for

Developers building AI assistants, agents, or any app that needs web search or page extraction. It's especially useful if you want to switch or combine providers, or if you need a self-hosted endpoint that works with MCP-capable clients like Claude Desktop or Cursor.

Highlights

• Normalized results across providers: title, url, snippet, optional date/content.
• Supports search, news, and page extraction (crawl) depending on configured providers.
• Choose your providers freely; unconfigured ones are never auto-enabled.
• Fallback chains with per-operation ordering, in-memory and Cloudflare KV caching.
• Multiple integration styles: MCP, HTTP API, JS/TS library, Hono mount.
• Compatibility endpoints for existing API clients (SearXNG, Exa, Tavily, Search1API, Firecrawl single-page).