fast-webfetch-mcp

Ein Web-Fetch-MCP-Server, der Seiten mit einem echten Browser auf deinem eigenen Rechner rendert und dem Modell dann sauberes Markdown übergibt – statt einer Token-Rechnung für 2 MB JavaScript.

Das Abrufen kostet hier nichts: keine API-Schlüssel, keine Preisgestaltung pro Seite. Und wenn eine Site behauptet, dich zu blockieren, ist das oft nur ein Headless-Erkennungsskript, das ein echtes Chromium einfach durchläuft.

So funktioniert es

Zwei kleine Programme, ein Job:

MCP client (agent)
   │  JSON-RPC over stdio
   ▼
src/index.ts          Bun + MCP SDK — tool schemas, budgets, rendering
   │  spawns per request
   ▼
crawl4ai_worker.py    Python + Crawl4AI — headless Chromium, markdown extraction
   │
   ▼
The actual internet

Der TypeScript-Server besitzt die Richtlinie: Timeouts, Nebenläufigkeitsgenehmigungen, Ausgabekürzung, optionale Gemini-gestützte Zusammenfassung. Der Python-Worker besitzt die Mechanik: Browser-Lebenszyklus, Rendering, Wiederholungen. Keiner kennt den Job des anderen, und der Vertrag zwischen ihnen ist ein JSON-Dokument auf stdout.

Related MCP server: crawler-mcp

Installation

Voraussetzungen: Bun, Python 3.12+ und eine GPU-agnostische Menge Geduld für den ersten Browser-Download.

git clone <this repo> ~/.local/share/mcp/fast-webfetch-mcp   # or anywhere
cd ~/.local/share/mcp/fast-webfetch-mcp
bun install
uv venv .venv --python 3.12 && uv pip install --python .venv/bin/python crawl4ai

Überprüfe, ob die Browser-Seite funktioniert:

FAST_WEBFETCH_SMOKE_URL=https://example.com bun run src/index.ts

Du solltest Markdown für die Beispiel-Domain sehen. Falls du stattdessen einen Stack-Trace über Playwright-Browser siehst, führe crawl4ai-setup aus der venv aus und versuche es erneut – es installiert den richtigen Chromium-Build für dich.

Binde es in deinen Agenten ein

{
  "mcpServers": {
    "fast-webfetch": {
      "type": "stdio",
      "command": "/usr/bin/mullvad-exclude",
      "args": ["/home/you/.bun/bin/bun", "run", "/path/to/fast-webfetch-mcp/src/index.ts"],
      "env": { "PATH": "/home/you/.bun/bin:/usr/bin:/bin" }
    }
  }
}

Der mullvad-exclude-Wrapper ist optional; er lässt nur den Fetch-Verkehr eine VPN umgehen, sodass Sites deine echte IP sehen. Ein einfaches "command": "bun" funktioniert identisch.

Tools

fast_fetch — eine URL zu Markdown

fast_fetch_raw — eine URL zu rohem HTML

Gleiche Argumente minus prompt. Verwende es, wenn Markdown das verliert, was du brauchst: Tabellen, data--Attribute, Meta-Tags, exaktes Markup.

Das options-Objekt

Alle drei Tools akzeptieren ein optionales options-Objekt für Sites, die mehr als ein einfaches Laden-und-Greifen benötigen:

{
  "url": "https://example.com/feed",
  "options": { "full_page": true, "wait_seconds": 1.5, "drop_overlays": true }
}

Falsch geschriebene Schlüssel werden stillschweigend verworfen, nicht durchgereicht – die Options-Payload wird auf der Python-Seite zu CrawlerRunConfig-Flags.

fast_fetch_multiple — bis zu 15 URLs in einem Batch

Jede URL kommt als eigener Abschnitt mit einem Metadaten-Header (url, status, elapsed_ms, truncated) zurück. Eine langsame Site kann die anderen nicht aushungern – sie erhält nur einen Fehler pro Element wegen Timeout, während ihre Batch-Genossen erfolgreich sind.

Konfiguration

Alles optional, alles Umgebungsvariablen.

Server-Einstellungen

Browser-Einstellungen

Verhalten, das man kennen sollte

JS-lastige Sites liefern unter der Standard-Wartestrategie oft eine leere Hülle. Wenn eine 200 ohne Inhalt zurückkommt, versucht der Worker einmal erneut mit networkidle, innerhalb desselben Timeout-Budgets – im schlimmsten Fall wartest du einmal, nicht zweimal. Verbindungsfehler und HTTP-Fehler bleiben dagegen Einzelversuche: Eine tote Host erneut zu versuchen, ist nur ein langsamerer Weg zu scheitern.

fast_fetch und fast_fetch_multiple schöpfen aus demselben Pool von 12 Browser-Slots, sodass ein großer Batch einen gleichzeitigen Einzel-Fetch nicht aushungern kann. Nachfrage über den Pool hinaus wird in die Warteschlange gestellt; ein Batch, der mehr Slots anfordert als existieren, bekommt, was frei ist.

Schließlich existiert max_length, weil das Kontextfenster deines Agenten ein Budget ist, keine Müllhalde.

Wenn etwas schiefgeht, erhältst du einen Log-Pfad

Fehler werden in zwei Haufen sortiert: das Internet ist unzuverlässig (Timeouts, langsame Sites, Batch-Deadline-Fehler pro Element) und das Tool bricht tatsächlich (Worker startet nicht, Worker abgestürzt, stdout-Überlauf, nicht parsebare Ausgabe). Nur der zweite Haufen schreibt ein Log – der erste bekommt nur ein ehrliches Fehler-Tag.

Ein Tool-seitiger Fehler endet mit:

log: /path/to/fast-webfetch-mcp/logs/2026-08-22T09-02-06-780Z-fast_fetch.json

Darin: das Tool, exakte Argumente, Worker-Eingabe und der vollständige Fehlerdatensatz (Stufe, Exit-Code, Signal, stderr-Ende) – genug, um die Anfrage wörtlich zu wiederholen:

FAST_WEBFETCH_INPUT='{"url":"https://example.com","max_length":40000}' \
  .venv/bin/python crawl4ai_worker.py

Umleiten mit FAST_WEBFETCH_LOGS_DIR.

Unter 30 Sekunden bleiben

Agent-Harnesses neigen dazu, MCP-Aufrufe um die 30-Sekunden-Marke zu beenden, daher behandelt dieser Server 28s als harte Wand. Jedes Tool antwortet davor: fertige Ergebnisse, wenn der Fetch es geschafft hat, andernfalls strukturierte Fehler pro Element, die sagen, welche Stufe die Zeit gefressen hat. Ein Batch, der das Budget überschreitet, gibt trotzdem die Elemente zurück, die fertig wurden.

Fehlerbehebung

Entwicklung

bun install
bun test            # 18 tests, no network needed
bun run typecheck   # tsc --noEmit, strict + noUncheckedIndexedAccess

Der Python-Worker kann direkt angesteuert werden, was der schnellste Weg ist, Fetch-Verhalten ohne die MCP-Schicht zu debuggen:

FAST_WEBFETCH_INPUT='{"url":"https://example.com","max_length":500}' \
  .venv/bin/python crawl4ai_worker.py

Siehe auch

• ddg-search — das natürliche Frontend: sucht und übergibt Ergebnis-URLs an diesen Server

• Crawl4AI — die darunterliegende Crawling-Engine

• Model Context Protocol — das Drahtprotokoll

Lizenz

MIT.