mcp-searxng: Websuche für MCP-Clients über eine eigene SearXNG-Instanz

Welche Lücke der Server schließt

Ein MCP-Client wie Claude Desktop, Cursor oder Cline kann Werkzeuge aufrufen, die ihm ein Server über das Model Context Protocol bereitstellt. Ohne einen solchen Server hat das Modell keinen Zugriff auf aktuelle Webinhalte. Der übliche Weg führt über kommerzielle Such-APIs, die einen Schlüssel verlangen und die Anfragen beim Anbieter protokollieren. mcp-searxng setzt an einer anderen Stelle an: Es spricht die JSON-Schnittstelle einer SearXNG-Instanz an, also einer Meta-Suchmaschine, die selbst mehrere Suchdienste abfragt. Betreibt man diese Instanz selbst, verlässt die Suchanfrage die eigene Infrastruktur nicht in Richtung eines kommerziellen Suchanbieters. Das README formuliert es so, dass eine vom Betreiber kontrollierte Instanz das Vertrauen in einen Drittanbieter vermeidet, während eine öffentliche Instanz die Anfrage erhält und protokollieren kann. SearXNG und diese Integration liefern laut README von sich aus keine Anonymität. Die Zielgruppe sind entsprechend Teams und Einzelpersonen, die SearXNG bereits betreiben oder betreiben wollen und dafür einen MCP-Anschluss brauchen.

Ein Node-Prozess zwischen Client und SearXNG

Der Server ist ein eigenständiger Node.js-Prozess, den der MCP-Client startet und mit dem er über stdio oder optional über HTTP spricht. Die Konfiguration übergibt der Client beim Start, in der Regel über Umgebungsvariablen. Aus dem README geht hervor, dass Suchanfragen an die SearXNG-Instanz gehen und deren Antwort in das Werkzeugergebnis übersetzt wird. Textresultate stellen laut README zuerst Antworten, Korrekturen, Vorschläge und Infoboxen vor die eigentliche Ergebnisliste. Für die Ausgabe gibt es zwei Formate: formatierten Text oder rohes JSON, wählbar pro Aufruf über response_format oder als Vorgabe des Betreibers über SEARXNG_DEFAULT_RESPONSE_FORMAT. Neben der Suche bietet der Server das Lesen von URLs, wobei der Inhalt typabhängig nach Markdown umgewandelt wird, inklusive begrenzter Textextraktion aus PDFs, mit Paginierung, Abschnittsfilterung, Absatzbereichen und Überschriftextraktion. Beide Pfade, Suche und URL-Lesen, liegen hinter einem In-Memory-Cache mit konfigurierbarer TTL und LFU-Verdrängung.

Replicas, Fan-out und der Preis dafür

SEARXNG_URL nimmt nicht nur eine URL auf, sondern eine mit Semikolon getrennte Liste austauschbarer Replicas. Standardmäßig arbeitet der Server die Liste der Reihe nach ab und wechselt bei einem Fehler zur nächsten Instanz. Mit SEARXNG_FANOUT fragt er stattdessen alle gesunden Replicas parallel ab und führt die Ergebnisse zusammen. Das ist die interessanteste Designentscheidung des Projekts, denn sie verschiebt die Verfügbarkeitsfrage vom Client zum Betreiber: Wer mehrere Instanzen betreibt, bekommt Ausfallsicherheit ohne Änderung am Client. Der Preis ist weniger offensichtlich. Fan-out bedeutet mehr ausgehende Anfragen pro Suchvorgang, und die Zusammenführung paralleler Trefferlisten erzeugt eine Reihenfolge, die nicht mehr der Ranking-Logik einer einzelnen Instanz entspricht. Wer Fan-out einschaltet, sollte wissen, dass er damit ein eigenes Ranking-Problem einführt. Die Dokumentation beschreibt das Zusammenführen, ohne ein Ranking-Verfahren zu benennen.

Inbetriebnahme über die Client-Konfiguration

Der Einstieg läuft über die Konfigurationsdatei des MCP-Clients, im README am Beispiel von claude_desktop_config.json. Der Server wird per npx gestartet, mit -y und dem Paketnamen mcp-searxng, und die Instanz-URL kommt über die Umgebungsvariable SEARXNG_URL hinein. Der Platzhalter YOUR_SEARXNG_INSTANCE_URL wird durch die eigene Adresse ersetzt, etwa https://searxng.example.com. Für Replicas steht dort eine Semikolon-Liste wie https://one.example.com;https://two.example.com. Das README verweist für geprüfte Rezepte zu Claude Desktop, Claude Code, Codex CLI, Cursor, VS Code, Windsurf, Cline und OpenCode auf docs/client-configurations.md. Weitere Umgebungsvariablen sind im README belegt: SEARXNG_FANOUT für den parallelen Modus und SEARXNG_DEFAULT_RESPONSE_FORMAT für das Standardausgabeformat. Für lokale Modelle mit kleinem Kontextfenster gibt es einen Lite-Tools-Modus mit minimalen Werkzeugschemata. Wer den HTTP-Transport statt stdio nutzen will, findet im README den Hinweis auf den Streamable-HTTP-Modus des MCP SDK v2 mit optionaler Härtung, Ratenbegrenzung und begrenzter zustandsloser Kompatibilität für serverlose oder horizontal skalierte Deployments.

SSRF-Schutz und die Grenzen des URL-Lesers

web_url_read blockiert laut README standardmäßig private und interne URLs sowie Weiterleitungen, und zwar in allen Transportmodi. Das ist eine bewusste Einschränkung, denn ein Modell, das eine URL aus einer Suchantwort oder aus einer Nutzereingabe aufruft, ist ein bequemer Weg, um interne Dienste zu erreichen. Wer den Server in einem Netz betreibt, in dem interne Adressen erreichbar sind, sollte diese Voreinstellung nicht aufweichen. Die zweite Grenze betrifft den Browser-Solver-Pfad. Für jede nicht gecachte URL, die die statische URL-Prüfung und die HEAD-Größenprüfung besteht, kann der Server optional eine Browsersitzung von FlareSolverr, Byparr oder beiden anfordern und den zurückgegebenen User-Agent samt zugehörigen Cookies durch den begrenzten URL-Leser wiederverwenden. Im Dual-Provider-Modus ist FlareSolverr immer primär, Byparr wird nur nach einem belegten oder vorübergehend nicht verfügbaren Primärsystem versucht. Das README nennt hier eine Einschränkung, die man kennen sollte: Der Client-Abbruch stoppt die lokale Arbeit zügig, aber ein entfernter Browser kann bis zu seinem konfigurierten Provider-Timeout weiterlaufen, nachdem der HTTP-Client die Verbindung getrennt hat. Wer Abbruch als Kostenkontrolle einplant, plant falsch.

Wo der Server das falsche Werkzeug ist

Die Suchqualität ist nicht die des Servers, sondern die der SearXNG-Instanz und der von ihr konfigurierten Engines. Eine öffentliche Instanz kann format=json ablehnen; dafür gibt es laut README einen optionalen HTML-Fallback, der Ergebnisse aus der HTML-Seite parst. Dieser Pfad ist ausdrücklich als Fallback beschrieben, nicht als gleichwertiger Ersatz, und er hängt an der Struktur einer fremden Seite. Wer reproduzierbare Ergebnisse über Wochen braucht, ist auf einer öffentlichen Instanz schlecht aufgehoben, weil sich deren Engine-Konfiguration jederzeit ändern kann. Ein zweiter Fall: Wer die Suche über einen kommerziellen Index mit eigener Crawling-Infrastruktur braucht, wird hier nicht fündig, weil die Abdeckung von den vorgeschalteten Engines abhängt. Und wer den Server in einer Umgebung ohne Node.js betreibt, muss den Umweg über das Container-Image gehen; das README verweist auf Docker Hub unter isokoliuk/mcp-searxng.

Der Unterschied zu den Anbieter-Servern

Das README enthält eine Vergleichstabelle mit Brave MCP, Exa MCP und Firecrawl MCP, Stand 2026-07-29. Der Ansatz unterscheidet sich grundlegend: Brave, Exa und Firecrawl betreiben den Suchindex selbst und stellen ihn über eine gehostete API bereit, der Client braucht einen API-Schlüssel. mcp-searxng betreibt keinen Index. Es ist eine Vermittlungsschicht zwischen MCP und einer SearXNG-Instanz, die der Nutzer selbst auswählt oder betreibt. In der Tabelle ist mcp-searxng die einzige Spalte mit einem Häkchen bei self-hosted und bei free / no API key, während Firecrawl dort partial aufweist und Brave und Exa jeweils kein Häkchen. Beim Lesen von URLs unterscheidet sich das Bild: Exa und Firecrawl bieten es laut Tabelle ebenfalls, Brave nicht. Paginierung fehlt laut Tabelle bei Exa. Die praktische Konsequenz: Wer die Kontrolle über die Suchinfrastruktur will, tauscht sie gegen Betriebsaufwand ein. Wer sie nicht will, zahlt beim Anbieter und akzeptiert dessen Protokollierung.

Wartung, Versionen und Lizenz

Das Repository steht unter der MIT-Lizenz, was die Weitergabe und Anpassung mit Namensnennung erlaubt. Wer den Code forkt und verändert, muss die Lizenzbedingungen einhalten; das ist keine Rechtsberatung, sondern nur der Hinweis auf den Lizenzidentifikator im Repository. Die Release-Historie zeigt v2.0.0 am 21. August 2026, v2.1.0 am 25. August 2026 und v2.2.0 am 9. September 2026, also drei Minor- beziehungsweise Major-Sprünge innerhalb weniger Wochen. Daraus lässt sich ableiten, dass sich die Konfigurationsoberfläche in dieser Phase bewegen kann; wer den Server produktiv einsetzt, sollte die Release Notes vor einem Update lesen. Ein Kostenfaktor, der leicht übersehen wird: Der Browser-Solver-Pfad zieht FlareSolverr oder Byparr als zusätzliche Dienste nach sich. Das README nennt konkrete, verifizierte Images mit Digest, nämlich ghcr.io/flaresolverr/flaresolverr:v3.5.0 und ghcr.io/thephaseless/byparr:2.1.0, geprüft am 30. Juli 2026. Wer diesen Pfad nicht braucht, spart sich zwei Container, zwei Timeouts und eine weitere Fehlerquelle. Die Entscheidung darüber sollte vor dem Deployment fallen, nicht danach.

Redaktionelles Fazit

Wer bereits eine SearXNG-Instanz betreibt und Suchanfragen nicht an Brave, Exa oder Firecrawl abgeben will, bekommt hier einen schlanken MCP-Server mit Failover, Caching und SSRF-Schutz für web_url_read. Wer keine eigene Instanz betreiben will oder Suchqualität und Indexabdeckung eines kommerziellen Anbieters braucht, sollte zu einem der Anbieter-Server greifen. Vor dem Einsatz zu prüfen: ob die Ziel-Instanz format=json erlaubt, ob die konfigurierten Replicas tatsächlich antworten, und ob der Browser-Solver-Pfad überhaupt gebraucht wird, denn er zieht FlareSolverr oder Byparr als zusätzliche Dienste nach sich.

Offizielle Quellen

1. ihor-sokoliuk/mcp-searxng on GitHub
2. License: MIT
3. Project website
4. README
5. Releases