keyless-web-search-mcp

Servidor MCP stdio independiente: dos herramientas sin clave — web_search sobre un grupo de motores autooperados (Bing, 360, Baidu, Google, Naver, Yandex, DuckDuckGo) y web_fetch (lector de páginas HTTP(S) anónimo). Cada búsqueda mantiene como máximo dos motores utilizables, enruta las prioridades por defecto según el idioma de la consulta, rellena motores fallidos o irrelevantes dentro de un presupuesto de intentos limitado, ordena los resultados por relevancia, los fusiona y elimina duplicados por URL canónica. Directorio autocontenido, sin paso de compilación, no forma parte del sistema de paquetes del harness — se puede mover a cualquier lugar.

Por qué existe esto

El web_search integrado del harness (proveedor DeepSeek) necesita DEEPSEEK_API_KEY y envía cada consulta a la nube de DeepSeek. Este servidor es la alternativa amigable para modelos locales: sin claves, sin API de búsqueda de proveedor, funciona en redes de China continental y HK (Bing/360/Baidu desde líneas continentales, Bing/360/Naver/Yandex desde la línea HK probada; DuckDuckGo no es accesible desde ninguna de ellas).

web_fetch existe por la misma razón en el lado de lectura: el perfil web monta un proveedor de búsqueda pero ningún proveedor de fetch, por lo que la herramienta integrada web_fetch (incluso cuando un ajuste preestablecido la habilita) falla en cada llamada con WEB_PROVIDER_UNAVAILABLE. Esta herramienta lee el contenido completo de la página a través del mismo servidor sin claves.

Related MCP server: web-search-mcp

Ejecutar

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

Prueba rápida sin cliente:

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

Instalar en Claude Code

Instálalo para el usuario actual para que todos los proyectos de Claude Code puedan usarlo. Resuelve ambas rutas al registrar el servidor; esto evita depender del directorio de trabajo del shell o del PATH más adelante:

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

Usa --scope local en su lugar para mantenerlo privado al proyecto actual, o --scope project para escribir un .mcp.json compartible. Claude Code guarda los registros de usuario/local en ~/.claude.json; las definiciones de servidor MCP no pertenecen a settings.json.

Después del registro, claude mcp list debería informar que web-search-self está conectado. Las herramientas aparecen como mcp__web-search-self__web_search y mcp__web-search-self__web_fetch.

Herramientas

web_search

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

Política de dos fuentes. El pool se enruta según el idioma de la consulta cuando se omite engines: el chino comienza con 360/Baidu/Bing; el inglés comienza con Bing/Google/Naver/360, de modo que el presupuesto de cuatro intentos conserve respaldos funcionales en las líneas probadas (continental y HK). Una lista explícita de engines sigue siendo autoritativa. Los motores se ejecutan en rondas paralelas limitadas; un motor consume un espacio de fuente solo después de que produce resultados parseables que pasan un filtro léxico conservador de relevancia. Los motores fallidos, vacíos o irrelevantes se rellenan hasta el presupuesto de intentos, y se muestran diagnósticos en una línea "Nota del motor". Los resultados se clasifican por superposición con la consulta con un pequeño ajuste de calidad de fuente: las señales de granjas de contenido o re-publicación obvias se penalizan, mientras que las señales de GitHub/educación/docs se favorecen sin bloquear duro las páginas normales. La fusión sigue siendo entrelazada round-robin (1.º del motor A, 1.º del motor B, 2.º del A, ...), y la deduplicación por URL canónica elimina fragmentos, parámetros de seguimiento comunes y diferencias seguras de www..

Resultados numerados como lista de título [motor] — URL — fragmento. Limpieza de enlaces por motor: los enlaces de seguimiento de Bing se decodifican (parámetro u en base64); 360 lee el atributo data-mdurl; Baidu lee el data-url del bloque (URL directa, con un único GET de mejor esfuerzo solo para envoltorios heredados link?url=); Naver y Yandex llevan la URL directa en el ancla; los enlaces /url?q= de Google se desempaquetan; los rastreadores /l/?uddg= de DuckDuckGo se desempaquetan. Presupuestos de sondeo por motor: 10 s (Bing, Baidu), 8 s (360, Naver, Yandex), 5 s (Google, DuckDuckGo) — todos se ejecutan en paralelo, por lo que la ronda es tan lenta como su miembro más lento.

web_fetch

web_fetch({ url, maxChars? })

Lectura anónima de la web pública: User-Agent de navegador, como máximo cinco redirecciones, 20 s de tiempo de pared que cubren cabecera y cuerpo, el cuerpo de la respuesta se corta exactamente en 5 MB. Cada objetivo inicial y de redirección se comprueba después de la resolución DNS; se rechazan loopback, direcciones privadas, link-local, NAT de operador, reservadas, multicast y nombres de host locales para prevenir SSRF hacia la máquina o metadatos en la nube. El texto visible se extrae (se eliminan script/style/noscript/svg, los límites de bloque se convierten en saltos de línea, se descartan los formularios); se conservan los tipos textuales, JSON y XML decodificados con su charset declarado, mientras que los tipos binarios se descartan. La cabecera devuelve status, url final, content-type y truncamiento, seguidos del contenido. Los errores de red se informan con un código de estado legible y una breve nota, nunca una página fabricada.

Motores y líneas

Probes:

• Bing: accesible desde líneas continentales y HK; a veces devuelve 406 a agentes no estándar — los resultados aún se procesan con una antología sintética de enlaces.

• 360: accesible desde líneas continentales y HK (el enrutamiento cambia según el nodo); la página de resultados es HTML mixto con wappalyzer al final; su selector de resultados es más frágil.

• Baidu: requiere proxies de red desde las líneas probadas; el HTML de resultados declara gb2312. Sin JavaScript, la primera página suele carecer del bloque de resultados y necesita consultas con número de página.

• Naver: afficione a las líneas HK; a veces devuelve una página de consentimiento de cookies. Cuando lo hace, el selector de resultados encuentra solo la cabecera de la página — el motor se descarta como "no utilizable".

• Google: requiere proxy (y a menudo consentimiento); la salida está envuelta en /url?q= y &sa=; los resultados suelen aparecer según la región.

• Yandex: accesible desde líneas HK; bloquea por captcha, a menudo con captcha en la URL de redirección. Cuando el captcha se activa (respuesta 403), la salida sin JavaScript aún contiene enlaces reales (fragmento bajo el título, lista de resultados), por lo que el proxy de búsqueda rara vez falla por completo.

• DuckDuckGo: html.duckduckgo.com — en las redes probadas no es alcanzable desde líneas continentales o HK; la página de resultados carece de data-testid en resultados repetidos.

Notas de implementación

• Sin dependencias de red: solo node:http y módulos integrados; sin fetch de Node, sin paquetes npm.

• Sin JavaScript: todos los motores se consultan con HTML estático. Los motores que sirven resultados dinámicamente (por ejemplo, mediante EJS o JS) se consideran no utilizables.

• Recuperación: cada motor tiene un temporizador de 5–10 s; los tiempos de espera se consideran fallos. El presupuesto de intentos (por defecto 4) se agota solo cuando un motor no produce resultados utilizables.

• Sin caché persistente: cada búsqueda construye los resultados desde cero; ninguna configuración, cero archivos de estado.

• Solo node: dependencia única @modelcontextprotocol/sdk (tiempo de ejecución Node ≥ 18).

Comportamiento

• Enrutado inteligente de motores: el pool se elige por idioma de la consulta; los motores que fallan, devuelven vacío o son irrelevantes se reemplazan con presupuesto disponible.

• Sin clave de API: por diseño.

• Límites estrictos: cada motor como máximo 5 resultados; count máximo 10; por defecto 5.

• Sin seguimiento de estado: invocaciones sin estado, seguras para llamadas concurrentes.

Deliberadamente fuera del grupo: Sogou — redirige con 302 a sogou.com/antispider/, la misma clase de muro por IP que cubre Baidu. También analizado y rechazado desde la línea de Hong Kong: Mojeek (sirve una página de captcha), Ecosia (403 "Ecosia Firewall"), MetaGer (redirige a una página sin resultados), y Yahoo/Brave/Qwant/Startpage/goo.ne.jp (TCP inalcanzables desde las líneas de la China continental y de Hong Kong).

El muro de Google: qué se probó

La respuesta 200 desde esta IP no es un bloqueo sino un desafío de JavaScript interstitial (~90 KB de JavaScript ofuscado/cifrado; la ruta sin JavaScript es un meta-refresco a un callejón sin salida). El muro resulta tener dos capas:

1. Desafío JS (computacional) — al decodificarlo, calcula un valor de prueba y establece una cookie SG_SS (caducidad de 5 minutos), luego recarga. Esta capa es resoluble fuera del navegador: ejecutar los scripts de la página en Node.js plano con un simulador ligero de DOM (cookie jar, navigator, Image, document) completó el cálculo, y la cookie SG_SS resultante fue aceptada una vez — Google respondió 200 y emitió las cookies de confianza NID/AEC que de otro modo nunca envía a esta IP.

2. Capa de sesión (conductual) — las solicitudes HTTP planas posteriores, incluida una réplica exacta del flujo de recarga del propio script (emsg=SG_REL + sei coincidente, cookies fusionadas del jar, cabeceras de navegador), escalan al muro de anomalías 429 de google.com/sorry. Esta capa juzga toda la sesión (huella TLS/HTTP2, ritmo de solicitudes, mezcla de métodos), que la pila de OpenSSL/undici de Node no iguala.

Palancas del lado del cliente que se probaron y no cambiaron la respuesta de la capa 1: el parámetro gbv=1, calentamiento de cookies, cabeceras completas de huella de navegador, el flujo retry/enablejs, la entrada /m, UAs de navegador de texto/teléfono básico/IE6/Android antiguo, un UA falsificado de Googlebot (Google lo valida), cookies CONSENT, envío por POST (405), TLD alternativos, y el enlace "haz clic aquí" emsg=SG_REL sin la cookie. Alternativas de proxy de Google también eran inalcanzables o amuralladas desde esta red: Startpage y Qwant agotan el tiempo de espera, Mojeek sirve una página de captcha, Ecosia da 403.

Conclusión: la capa 1 es resoluble en Node (demostrado); la capa 2 no lo es, desde una pila de red que no es de navegador. Los únicos caminos fiables a Google desde esta máquina son un proxy con IP limpia o un contexto de navegador real (Chromium sin interfaz); ambos están en la misma capa de IP/patrón de tráfico que un raspador no puede superar honestamente, y las pruebas repetidas arriesgan ampliar la ventana de anomalía de la IP — así que este servidor no lo intenta. Google permanece como motor de respaldo que se activa en redes donde sirve un SERP en HTML plano.

Montaje en el arnés de DeepSeek

Añade a tu cordis.yml (el puente MCP recarga en caliente esta entrada):

- 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']

El modelo entonces ve las herramientas como mcp__search__web_search y mcp__search__web_fetch.

Limitaciones

• La calidad de búsqueda es heurística: la relevancia léxica maneja resultados claramente fuera de tema y n-gramas chinos; las páginas internas de los motores de búsqueda se excluyen; las señales de granja de contenido/republicación solo ajustan el orden, no son un juicio universal de confianza. Un resultado relevante no es prueba de que sus afirmaciones sean correctas — busca y verifica los datos importantes.

• Es raspado, no una API: los cambios de diseño pueden romper un parser; el fallo es ruidoso ("sin resultados orgánicos parseables"), nunca fabricado. Los parsers de Google y DuckDuckGo están escritos a partir de la estructura documentada del SERP y no son verificables en vivo desde esta red — ajústalos la primera vez que sus motores respondan realmente.

• Control de ritmo: ambos motores públicos toleran el uso ocasional; las ráfagas atraen desafíos de bots.

• La consulta sale de la máquina hacia los motores consultados (ese es el precio de la búsqueda sin clave); con el límite de dos fuentes, como máximo dos de ellos ven una consulta por búsqueda.

• Es un lector de páginas públicas sin clave, no un navegador ni un cliente de intranet: el contenido renderizado con JavaScript es invisible para él (misma clase de límite que los parsers de búsqueda); las páginas que dan 403/429 a clientes anónimos se informan, no se evaden. Los destinos de red locales/privados/reservados se bloquean deliberadamente, incluidos los destinos de redirección.