Плавучий быстрый MCP-сервер для многомоторного веб-поиска, написанный на Rust.

##Почему феррис-поиск?

Встроенный веб-поиск Claude Code отлично работает в идеальных сетевых условиях, но на практике многие разработчики сталкиваются с средами, где он ненадежен или недоступен: корпоративные сети, ограниченные регионы, настройки с воздушным зазором или просто нечеткая связь.

В поисках обходного пути я наткнулся на open-webSearch, MCP-сервер Node.js, который маршрутизирует поисковые запросы через несколько систем. Это хорошо решило проблему. Но у меня есть кое-что для Rust — и вращение времени выполнения Node.js только для прокси-сервера нескольких HTTP-запросов показалось мне тяжелее, чем нужно.

Так что я переписал ту же идею в Rust: No Node.js runtime — одиночный автономный двоичный файл, ~8 МБ ** Нижняя задержка** — Rust async I/O, одновременный вентилятор на всех двигателях ** Меньший след ** — незначительное использование памяти Прокси-поддержка — HTTP/SOCKS5 прокси через env var, для сетей, которые в этом нуждаются

Если поиск Клода Кода не работает в вашей среде, это для вас.

Корпоративное и внутреннее использование

Феррис-поиск также является хорошей основой для сценариев внутреннего поиска предприятий.

ferris-search 🦀

A blazing-fast MCP server for multi-engine web search, written in Rust.

Why ferris-search?

Claude Code’s built-in web search works great in ideal network conditions — but in practice, many developers run into environments where it’s unreliable or unavailable: corporate networks, restricted regions, air-gapped setups, or simply spotty connectivity.

While looking for a workaround, I came across open-webSearch, a Node.js MCP server that routes search queries through multiple engines. It solved the problem well. But I have a thing for Rust — and spinning up a Node.js runtime just to proxy a few HTTP requests felt heavier than it needed to be.

So I rewrote the same idea in Rust:

• No Node.js runtime — single self-contained binary, ~8 MB
• Lower latency — Rust async I/O, concurrent fan-out across engines
• Smaller footprint — negligible memory usage
• Proxy support — HTTP/SOCKS5 proxy via env var, for networks that need it

If Claude Code’s search isn’t working in your environment, this is for you.

Enterprise & Internal Use

ferris-search is also a good foundation for enterprise internal search scenarios. Since it’s a standard MCP server written in Rust, you can fork it and add custom search engines that connect to your internal knowledge bases — Confluence, Notion, internal wikis, code repositories, or proprietary document stores.

Some ideas:

• Add an engine that searches your internal Elasticsearch or OpenSearch cluster
• Integrate with your company’s Confluence or GitLab search API
• Connect to a private RAG (Retrieval-Augmented Generation) service
• Route queries to different backends based on query language or topic

With Claude Code as the AI layer and ferris-search as the search backbone, your team gets a local AI coding assistant that can actually find and reference internal documentation — without sending anything to external search engines.

Features

• Multi-engine fan-out — search across multiple engines simultaneously with a single call
• 14 search engines — Bing, DuckDuckGo, Brave, Baidu, CSDN, Juejin, Exa, Firecrawl, Zhihu, LinuxDo, Jina, Tavily, GitHub (repo search), GitHub Code (code search)
• 7 MCP tools — web_search + 6 article/content fetchers
• No API keys required for most engines (Brave, Exa, Firecrawl, Jina, and Tavily require API keys)
• Single binary — ~8 MB, no runtime dependencies
• Proxy support — HTTP/SOCKS5 proxy via env var

Quick Install

Linux / macOS (one-liner)

curl -fsSL https://raw.githubusercontent.com/lispking/ferris-search/main/install.sh | bash

Or from a local clone:

bash install.sh

The script will:

1. Build and install the binary via cargo install
2. Register the MCP server with Claude Code (claude mcp add -s user) if the CLI is found
3. Install Claude Code skills for ferris-search

Windows (PowerShell)