keyless-web-search-mcp

Автономный MCP stdio-сервер: два инструмента без ключей — web_search поверх собственного пула движков (Bing, 360, Baidu, Google, Naver, Yandex, DuckDuckGo) и web_fetch (анонимный чтение HTTP(S)-страниц). Каждый поиск использует не более двух рабочих движков, направляет приоритеты по умолчанию в зависимости от языка запроса, добирает неудачные или нерелевантные движки в рамках ограниченного бюджета попыток, ранжирует результаты по релевантности, объединяет их и дедуплицирует по каноническому URL. Самодостаточный каталог, без шага сборки, не является частью пакетной системы harness — перемещайте куда угодно.

Зачем это нужно

Встроенный в harness web_search (провайдер DeepSeek) требует DEEPSEEK_API_KEY и отправляет каждый запрос в облако DeepSeek. Этот сервер — альтернатива, удобная для локальных моделей: без ключей, без вендорского поискового API, работает в сетях материкового Китая и Гонконга (Bing/360/Baidu с материковых линий, Bing/360/Naver/Yandex с протестированной гонконгской линии; DuckDuckGo недоступен ни с одной из них).

web_fetch существует по той же причине на стороне чтения: веб-профиль подключает поисковый провайдер, но не подключает fetch-провайдера, поэтому встроенный инструмент web_fetch (даже если пресет его включает) завершается ошибкой WEB_PROVIDER_UNAVAILABLE при каждом вызове. Этот инструмент вместо этого читает полное содержимое страницы через тот же сервер без ключей.

Related MCP server: Heventure Search MCP

Запуск

npm install --cache ./.npm-cache   # deps: @modelcontextprotocol/sdk, zod
node index.js                      # speaks MCP over stdio
npm test                            # run deterministic ranking/fallback tests

Быстрая проверка без клиента:

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"0.0.1"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | node index.js

Установка в Claude Code

Установите его для текущего пользователя, чтобы каждый проект Claude Code мог его использовать. При регистрации сервера укажите оба пути в абсолютном виде; это избавит от зависимости от рабочей директории оболочки или PATH в дальнейшем:

claude mcp add --transport stdio --scope user web-search-self -- "$(command -v node)" "/absolute/path/to/keyless-web-search-mcp/index.js"
claude mcp get web-search-self

Используйте --scope local, чтобы ограничить его текущим проектом, или --scope project, чтобы записать общий .mcp.json. Claude Code хранит пользовательские и локальные регистрации в ~/.claude.json; определения MCP-серверов не должны находиться в settings.json.

После регистрации claude mcp list должен показать web-search-self как подключённый. Инструменты появятся как mcp__web-search-self__web_search и mcp__web-search-self__web_fetch.

Инструменты

web_search

web_search({ query, count?, maxSources?, engines? })

Политика двух источников. Когда engines не указан, пул выбирается по языку запроса: для китайского сначала идут 360/Baidu/Bing; для английского — Bing/Google/Naver/360, чтобы бюджет из четырёх попыток сохранял рабочие запасные варианты в протестированных сетях материкового Китая и Гонконга. Явный список engines остаётся приоритетным. Кандидаты выполняются ограниченными параллельными раундами; движок занимает слот источника только после того, как вернёт разбираемые результаты, прошедшие консервативную лексическую фильтрацию релевантности. Неудачные, заблокированные, пустые или нерелевантные движки добираются в пределах бюджета попыток и бюджета сборщика, а диагностика выводится в строке «Engine note». Результаты ранжируются по пересечению с запросом с небольшой поправкой на качество источника: очевидные признаки репостов и контент-ферм понижаются, а сигналы официальных сайтов, документации, образования и GitHub получают преимущество, при этом обычные сайты не блокируются жёстко. Объединение остаётся круговым чередованием (1-й от движка A, 1-й от B, 2-й от A, …), а дедупликация по каноническому URL удаляет фрагменты, распространённые отслеживающие параметры и безопасные различия www..

Результат: нумерованный список title [engine] / реальный URL назначения / сниппет. Очистка ссылок по движкам: ссылки-трекеры Bing декодируются локально (параметр u в base64); 360 читает атрибут data-mdurl; Baidu читает атрибут mu блока (прямой URL, с одним best-effort redirect GET только для устаревших обёрток link?url=); у Naver и Yandex заголовки содержат прямой URL в якоре; обёртки Google /url?q= разворачиваются; трекеры DuckDuckGo /l/?uddg= разворачиваются. Бюджеты проб на движок: 10 с (Bing, Baidu), 8 с (360, Naver, Yandex), 5 с (Google, DuckDuckGo) — все выполняются параллельно, поэтому раунд занимает столько времени, сколько его самый медленный участник.

web_fetch

web_fetch({ url, maxChars? })

Анонимное чтение публичного веба, без учётных данных: браузерный User-Agent, не более пяти редиректов, 20 секунд реального времени на заголовки и тело, тело ответа обрезается ровно на 5 МБ. Каждая начальная и промежуточная цель проверяется после разрешения DNS; loopback-адреса, частные, link-local, операторский NAT (CGNAT), зарезервированные, multicast и локальные имена хостов отклоняются для предотвращения SSRF в машину или облачные metadata-сервисы. HTML преобразуется в видимый текст (script/style/noscript/svg/head/iframe/canvas/form отбрасываются, границы блоков становятся переводами строк, <title> переносится в заголовок); текстовые, JSON и XML медиатипы проходят с декодированием сущностей с использованием объявленной кодировки, а бинарные медиатипы отклоняются. На выходе — статусный заголовок: status, конечный url (после редиректов), content-type, признак усечения — затем содержимое. Ответы с кодом не из диапазона 2xx возвращают начало тела плюс примечание (403/429 интерпретируются как бот-проверка или пейволл), никогда не сфабрикованную страницу.

Движки и их статус

Проверено в 2026-07 с трёх линий (более ранней линии материкового Китая, линии Shanghai Telecom и линии дата-центра Hong Kong Zenlayer):

Сознательно не включены в пул: Sogou — делает 302 на sogou.com/antispider/, тот же класс IP-стены, что покрывает Baidu. Также просканированы и отклонены с гонконгской линии: Mojeek (отдаёт страницу с капчей), Ecosia (403 "Ecosia Firewall"), MetaGer (редиректит на страницу без результатов), а также Yahoo/Brave/Qwant/Startpage/goo.ne.jp (TCP-недоступны и с материковых, и с гонконгской линий).

Стена Google: что было испробовано

Ответ 200 с этого IP — не блокировка, а промежуточная страница JS-челленджа (~90 КБ обфусцированного/зашифрованного JavaScript; путь без JS — это meta-refresh в тупик). Стена состоит из двух слоёв:

1. JS-челлендж (вычислительный) — после декодирования он вычисляет proof-значение и устанавливает куки SG_SS (срок действия 5 минут), затем перезагружается. Этот слой решаем вне браузера: запуск скриптов страницы в обычном Node.js с лёгким DOM-шимом (хранилище куки, navigator, Image, document) завершил вычисление, и полученная куки SG_SS была один раз принята — Google ответил 200 и выдал доверенные куки NID/AEC, которые он иначе никогда не отправляет на этот IP.

2. Слой паттернов сессии (поведенческий) — последующие обычные HTTP-запросы, включая точную копию собственного потока перезагрузки скрипта (emsg=SG_REL + соответствующий sei, куки, объединённые в jar, браузерные заголовки), эскалируют до стены аномалий google.com/sorry 429. Этот слой оценивает всю сессию (TLS/HTTP2-отпечаток, темп запросов, смесь методов), чему стек Node.js на OpenSSL/undici не соответствует.

Клиентские рычаги, которые были протестированы и не изменили ответ слоя 1: параметр gbv=1, прогрев куки, полные заголовки браузерного отпечатка, поток retry/enablejs, вход через /m, UA текстовых браузеров/кнопочных телефонов/IE6/старых Android, поддельный UA Googlebot (Google проверяет его), куки CONSENT, POST-отправка (405), альтернативные TLD и ссылка «click here» emsg=SG_REL без куки. Альтернативы через Google-прокси также были недоступны или заблокированы из этой сети: Startpage и Qwant не отвечают по таймауту, Mojeek отдаёт страницу с капчей, Ecosia отдаёт 403.

Вывод: слой 1 решаем в Node.js (продемонстрировано); слой 2 — нет, из не-браузерного сетевого стека. Единственные надёжные пути к Google с этой машины — прокси с чистым IP или реальный браузерный контекст (headless Chromium); оба находятся в том же слое IP/паттернов трафика, который скрейпер не может честно обойти, а повторные проверки рискуют расширить окно аномалии IP — поэтому этот сервер не пытается их использовать. Google остаётся запасным движком, который активируется в сетях, где он отдаёт обычную HTML-выдачу.

Подключение к DeepSeek Harness

Добавьте в ваш cordis.yml (MCP-мост горячо перезагружает эту запись):

- id: mcp-search
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: search
    transport: stdio
    command: node
    args: ['/absolute/path/to/keyless-web-search-mcp/index.js']

Затем модель видит инструменты как mcp__search__web_search и mcp__search__web_fetch.

Ограничения

• Качество поиска эвристическое: лексическая релевантность обрабатывает явно не по теме результаты и китайские n-граммы; внутренние страницы поисковых систем исключаются; сигналы контент-ферм/репостов только корректируют порядок, а не являются универсальной оценкой доверия. Релевантный результат не является доказательством правильности его утверждений — выполняйте fetch и перекрёстно проверяйте важные факты.

• Скрейпинг, а не API: изменения вёрстки могут сломать парсер; сбой громкий («no parseable organic results»), никогда не фабрикуется. Парсеры Google и DuckDuckGo написаны по документированной структуре SERP и не могут быть проверены вживую из этой сети — настраивайте их при первом реальном ответе их движков.

• Контроль частоты запросов: оба публичных движка терпят нерегулярное использование; интенсивные запросы привлекают бот-челленджи.

• Запрос покидает машину и уходит к используемым движкам (это цена поиска без ключей); при ограничении на два источника максимум два из них видят запрос за один поиск.

• Fetch — это ридер публичных страниц без ключей, а не браузер или интранет-клиент: JS-рендеренный контент для него невидим (тот же класс ограничения, что и у поисковых парсеров); страницы, которые отдают 403/429 анонимным клиентам, сообщаются, а не обходятся. Локальные/частные/зарезервированные сетевые адреса намеренно блокируются, включая адреса редиректов.