MCP server de búsqueda web autoalojado

Busca un MCP server de búsqueda web autoalojado y los resultados se dividen en dos montones: proyectos de GitHub que ejecutas enteramente tú, y páginas de proveedores que llaman "local" a una API alojada porque el cliente corre en tu portátil. Son cosas distintas, y cuál necesitas depende de qué intentas mantener realmente en casa.

Este post es concreto sobre dónde se sitúa CrawlForge en esa línea — incluida la parte que no es autoalojada.

Qué significa "autoalojado" en un MCP server

Un montaje de búsqueda web con MCP tiene tres capas, y cada una puede alojarse por separado:

1. El proceso del servidor — lo que tu cliente MCP lanza y con lo que habla por stdio.
2. El backend de búsqueda — lo que de verdad responde a la consulta.
3. El plano de control — autenticación, medición, facturación.

La mayoría de las afirmaciones de "autoalojado" solo cubren la capa 1. Ejecutar un proceso en local es lo mínimo; casi todos los MCP server lo hacen. La pregunta que decide si cuenta como autoalojado a efectos de privacidad es la capa 2: ¿sale tu consulta de tu red, y quién la ve?

Cuánto de CrawlForge se ejecuta en tu máquina

La capa 1 es enteramente tuya. crawlforge-mcp-server es un paquete npm con licencia MIT que corre como proceso local sobre stdio — sin demonio del proveedor, sin runtime en la nube, y con el código en GitHub por si quieres leerlo antes de ejecutarlo.

npm install -g crawlforge-mcp-server

La capa 2 es la interesante. search_web acepta un parámetro provider con dos valores admitidos, y uno de ellos es tu propia instancia de SearXNG:

export CRAWLFORGE_SEARXNG_URL=http://localhost:8888

{
  "query": "mcp server directory",
  "provider": "searxng",
  "limit": 10
}

Con eso configurado, la consulta va a tu máquina con SearXNG y a ningún otro sitio — ningún proveedor de búsqueda externo ve la cadena. Los resultados vuelven normalizados con la misma forma que los del provider alojado, así que el ranking, la deduplicación y la caché se siguen aplicando y nada cambia después en tu flujo.

Las tools basadas en LLM siguen el mismo patrón. extract_with_llm, summarize_content y analyze_content usan por defecto un modelo local de Ollama, así que el paso de extracción también puede quedarse en tu hardware.

Qué no es autoalojado

La capa 3. La medición pasa por CrawlForge sin importar qué provider elijas.

search_web está envuelto en la misma comprobación de autenticación y credits que cualquier otra tool, y esa comprobación ni sabe ni le importa que hayas elegido SearXNG. Una búsqueda servida por SearXNG sigue necesitando una API key válida y sigue costando 5 credits, exactamente igual que una alojada.

Conviene ser claro sobre lo que eso te da y lo que no. Autoalojar el backend de búsqueda cambia quién ve tus consultas — una ganancia real de privacidad, y la razón habitual para quererlo. No hace que la herramienta sea gratis, y no elimina la dependencia del proveedor. Si tu requisito es "ninguna conexión saliente hacia un proveedor", CrawlForge no lo cumple hoy.

Cuándo lo correcto es un servidor totalmente autoalojado

Si la capa 3 es la que necesitas controlar — red aislada, sin cuentas de proveedor, sin coste por llamada — usa mejor un proyecto totalmente autoalojado. SearXNG tiene wrappers MCP que hablan directamente con él, y para ese requisito te servirán mejor que dar rodeos con una herramienta medida.

CrawlForge se gana su sitio cuando quieres el backend de búsqueda en local pero sigues queriendo un solo servidor para el resto del trabajo: scrape, extract_content, crawl_deep, serp_rank y 23 tools más sobre la misma conexión y la misma key. Buscar contra tu propia instancia y extraer con tu propio Ollama, mientras una ruta alojada se encarga de las páginas que SearXNG solo te señaló, es un término medio razonable — y en la práctica es la configuración que acaba queriendo la mayoría de quienes buscan esto.

Consigue una API key — 1.000 credits puntuales, sin tarjeta. Define CRAWLFORGE_SEARXNG_URL, pasa provider: "searxng", y tus consultas se quedan en tu red.