webclaw: Web-Extraktion als Rust-Binary, MCP-Server und REST-API
Fast, local-first web content extraction for LLMs. Scrape, crawl, extract structured data — all from Rust. CLI, REST API, and MCP server.
Auf einen Blick
- Was ist das?
- webclaw verwandelt URLs in Markdown, JSON und LLM-Kontext und lässt sich als CLI, MCP-Server oder selbst gehosteter Dienst betreiben. Der interessante Teil ist die Aufteilung zwischen lokaler Extraktion und gehostetem Fallback für Bot-geschützte Seiten.
- Für wen ist es gedacht?
- Sinnvoll ist webclaw für Teams, die Webinhalte in RAG-Pipelines oder Agenten-Workflows einspeisen und die Extraktion selbst betreiben wollen, statt pro Seite einen fremden Dienst zu bezahlen. Wer die AGPL-3.0 nicht mit seinem Produkt vereinbaren kann oder Seiten mit hartnäckigem Bot-Schutz ohne konfigurierten API-Key verarbeiten muss, sollte vorher prüfen, ob der lokale Pfad allein trägt.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Zwei unbrauchbare Ausgaben und der Versuch, sie zu vermeiden
Das README benennt das Problem selbst: Die meisten Scraping-Werkzeuge liefern einem Agenten entweder eine blockierte Seite, eine Login-Wand oder eine leere App-Hülle, oder sie liefern rohes HTML mit Navigation, Skripten, Styling, Werbung und dupliziertem Boilerplate. Beides ist für einen LLM-Kontext unbrauchbar, das eine weil kein Inhalt da ist, das andere weil zu viel davon da ist. webclaw setzt dagegen auf genau eine Ausgabe: sauberen Text beziehungsweise Markdown, aus dem ein Modell direkt arbeiten kann.
Die Zielgruppe ist damit enger, als das Repository auf den ersten Blick suggeriert. Angesprochen sind Leute, die RAG-Indizes oder Agenten-Workflows bauen und dafür wiederkehrend fremde Seiten abrufen müssen. Wer einmalig eine Tabelle von einer Seite kratzt, braucht das nicht. Wer täglich dieselbe Dokumentationsseite in einen Index schiebt, schon.
Lokale Extraktion, gehosteter Fallback, und wo die Grenze verläuft
Die Architektur folgt einer Aufteilung, die im README explizit benannt wird: Der Großteil der Seiten wird lokal extrahiert, ohne API-Key. Für bot-geschützte und JavaScript-gerenderte Seiten existiert ein gehosteter Dienst unter webclaw.io, und der wird über die Umgebungsvariable WEBCLAW_API_KEY angesprochen. Das Repository selbst enthält laut Beschreibung CLI, MCP-Server, Extraktions-Engine und einen selbst hostbaren Server.
Wichtig ist, was das für den Datenfluss bedeutet. Der lokale Pfad heißt: HTTP-Abruf, Parsen, Reduktion auf Hauptinhalt, Ausgabe als Markdown, Text, JSON, LLM-Format oder HTML. Der gehostete Pfad wird nur dann relevant, wenn die lokale Anfrage nicht durchkommt. Wer den API-Key setzt, verlagert also einen Teil seiner Abrufe auf fremde Infrastruktur, ohne dass das README eine Grenze nennt, ab wann genau umgeschaltet wird. Das ist eine Designentscheidung, die man beim Selbstbetrieb im Auge behalten muss: Der Key ist kein Schalter für ein Feature, sondern ein Fallback für fehlgeschlagene Extraktion.
Die Topic-Liste des Repositories enthält tls-fingerprinting. Das deutet darauf hin, dass die Engine auf TLS-Ebene arbeitet, um sich von einfachen HTTP-Clients zu unterscheiden. Das README führt das nicht weiter aus, entsprechend sollte man hier keine Aussage über Wirksamkeit gegen konkrete Bot-Erkennungssysteme treffen.
Installation: fünf Wege, ein Installer
Der schnellste Weg richtet sich an Agenten, nicht an Menschen. npx create-webclaw erkennt unterstützte MCP-Clients (Claude Code, Claude Desktop, Cursor, Windsurf, OpenCode, Codex CLI und weitere) und schreibt deren Konfiguration. Wer das nicht automatisch will, trägt den Server selbst ein:
{ "mcpServers": { "webclaw": { "command": "npx", "args": ["-y", "@webclaw/mcp"] } } }
Für die Kommandozeile gibt es Homebrew über brew tap 0xMassi/webclaw und brew install webclaw, fertige Binaries für macOS, Linux und Windows, ein Container-Image unter ghcr.io/0xmassi/webclaw sowie den Cargo-Weg: cargo install --git https://github.com/0xMassi/webclaw.git webclaw-cli und entsprechend webclaw-mcp. Der Cargo-Weg ist der einzige, der native Build-Werkzeuge voraussetzt. Das README listet dafür pro Distribution die Pakete, etwa pkg-config, libssl-dev, cmake und clang auf Debian und Ubuntu.
Ein Detail, das in der Installationssektion auffällt: Es gibt ein separates Skill-Paket unter 0xMassi/webclaw-skill, das per npx skills add installiert wird und dem Agenten scrape, crawl, map, extract, summarize, diff, brand und search als native Werkzeuge bereitstellt. Das ist ein zweiter Integrationspfad neben MCP, und wer beides einrichtet, hat zwei Wege zu denselben Funktionen.
Was die Werkzeuge konkret tun
Die Werkzeugtabelle im README unterscheidet zwischen lokal lauffähigen und lokal-plus-LLM-Funktionen. scrape, crawl, map und batch laufen lokal. extract und summarize laufen ebenfalls lokal, benötigen aber ein lokales oder konfiguriertes LLM. Das ist der Punkt, an dem webclaw aufhört, ein reiner Extraktor zu sein: Sobald ein Modell im Spiel ist, hängt die Qualität der strukturierten Ausgabe an diesem Modell, nicht an der Engine.
Für die Kommandozeile zeigt das README mehrere konkrete Aufrufe. Formatwahl über --format markdown, --format llm oder --format json. Reduktion auf den Hauptinhalt über --only-main-content. Selektorsteuerung über --include "article, main, .content" und --exclude "nav, footer, .sidebar, .ad". Crawling über --crawl --depth 2 --max-pages 50. Vergleich zweier Stände über --diff-with pricing-old.json, wobei die vorherige Ausgabe vorher per Umleitung in eine Datei geschrieben wird. Markenerkennung über --brand.
Bemerkenswert ist die Reihenfolge der Beispiele. Das README führt --diff-with und --brand fast beiläufig, aber beide sind für wiederkehrende Beobachtungsaufgaben nützlicher als ein einzelner Scrape. Wer Preisseiten oder Markenauftritte über Zeit verfolgt, hat hier zwei fertige Aufrufe statt einer Eigenbaulösung.
Wo webclaw das falsche Werkzeug ist
Die lokale Extraktion hat eine harte Grenze, und das README benennt sie indirekt selbst: JavaScript-gerenderte Seiten gehören nicht zum lokalen Pfad. Eine Single-Page-App, die ihren Inhalt erst im Browser zusammensetzt, liefert lokal eine leere Hülle. Genau das ist das erste der beiden Eingangsprobleme. Ohne API-Key bleibt in diesem Fall nichts Verwertbares übrig.
Zweitens ist die Lizenz ein Filterkriterium, kein Nebensatz. AGPL-3.0 bedeutet: Wer den selbst gehosteten Server als Netzwerkdienst betreibt und verändert, muss den Quellcode unter derselben Lizenz verfügbar machen. Für ein internes Werkzeug ist das meist unkritisch. Für ein kommerzielles Produkt, das webclaw als Dienst einbettet, ist es eine Architekturentscheidung, die vor dem ersten Commit fallen sollte. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzwahl hier den Einsatzbereich mitbestimmt.
Drittens: Das Repository gibt keine Angaben zu Rate Limits des gehosteten Dienstes, zu Kosten pro Abruf oder zu Datenhaltung auf der Hosted-Seite. Wer den API-Key produktiv setzt, sollte diese Punkte vorher klären, weil sie nicht aus dem Repository hervorgehen.
Der Vergleich mit Firecrawl und Crawl4AI
Das Repository positioniert sich über Topic-Tags explizit als Alternative zu Firecrawl, Crawl4AI, Jina und den kommerziellen Scraping-APIs. Der Unterschied liegt weniger im Funktionsumfang als im Verteilungsmodell. Firecrawl ist primär ein Dienst mit SDK; webclaw ist primär ein Rust-Binary, das man lokal ausführt, und der Dienst existiert als Fallback daneben. Crawl4AI ist ein Python-Projekt, was für Python-Pipelines bequemer ist, für alles andere aber eine zusätzliche Laufzeit bedeutet.
Für Rust-Umgebungen ist das der eigentliche Argumentationspunkt: kein Python-Interpreter, kein Node-Prozess, ein Binary. Das README zeigt zusätzlich ein Beispielverzeichnis für eine Firecrawl-kompatible API (examples/firecrawl-compatible-api/), was nahelegt, dass sich bestehende Integrationen gegen den selbst gehosteten Server umbiegen lassen. Wie vollständig diese Kompatibilität ist, sagt das README nicht. Das wäre der erste Punkt, den man im Beispielverzeichnis nachlesen sollte, bevor man eine Migration plant.
Wartung, Release-Takt und was das für den Betrieb heißt
Die Release-Historie zeigt v0.6.22 vom 30. August 2026, davor v0.6.21 und v0.6.20 beide vom 16. August 2026. Zwei Releases am selben Tag deuten auf schnelle Nachbesserungen hin. Der Sprung von 0.6.20 auf 0.6.22 innerhalb von zwei Wochen ist für ein Werkzeug dieser Art normal, bedeutet aber auch: Die CLI-Fläche kann sich zwischen Minor-Versionen bewegen. Wer webclaw in eine Pipeline einbaut, sollte die Version pinnen, statt dem jeweils neuesten Binary zu folgen.
Der letzte Push liegt bei September 2026, das Projekt ist nicht archiviert. Es gibt einen Discord und einen X-Account, was auf aktive Betreuung hindeutet, aber nichts über die Zahl der Beitragenden aussagt. Für ein Werkzeug, das in eine Datenpipeline eingebettet wird, ist die relevante Frage nicht, ob committet wird, sondern ob sich die Ausgabeformate zwischen Versionen ändern. Dazu macht das README keine Zusage.
Ein praktischer Hinweis zum Aktualisieren: Der Cargo-Weg installiert aus dem Git-Repository, nicht aus crates.io. Ein cargo install erneut auszuführen zieht also den aktuellen Stand von main, nicht die letzte Release-Marke. Wer reproduzierbare Builds braucht, muss den Commit oder das Release-Tag selbst festlegen.
Redaktionelles Fazit
Sinnvoll ist webclaw für Teams, die Webinhalte in RAG-Pipelines oder Agenten-Workflows einspeisen und die Extraktion selbst betreiben wollen, statt pro Seite einen fremden Dienst zu bezahlen. Wer die AGPL-3.0 nicht mit seinem Produkt vereinbaren kann oder Seiten mit hartnäckigem Bot-Schutz ohne konfigurierten API-Key verarbeiten muss, sollte vorher prüfen, ob der lokale Pfad allein trägt. Als Erstes würde ich den Installer in einer isolierten Umgebung laufen lassen und mir ansehen, welche Konfigurationsdateien er in den MCP-Clients tatsächlich schreibt.
Community-Notizen