Die meisten AI-Plattformen verbinden sich mit externen Diensten über REST-APIs. Das funktioniert für strukturierte Daten — einen CRM-Kontakt lesen, ein Jira-Ticket erstellen — aber es verfehlt alles, was im Browser passiert. Der E-Mail-Entwurf in Gmail, der Slack-Thread, den Sie lesen, das halb ausgefüllte Formular in ServiceNow.
Wir haben eine Browser-Extension gebaut, die diese Lücke mit dem Model Context Protocol (MCP) überbrückt. Dieser Beitrag behandelt die Architekturentscheidungen, die Probleme, auf die wir gestoßen sind, und wie das System Ende-zu-Ende funktioniert.
Das Problem: Browser-Zustand ist für APIs unsichtbar
APIs geben Ihnen Datenbankeinträge. Sie geben Ihnen nicht, was auf dem Bildschirm ist. Ein Vertriebsmitarbeiter, der eine Follow-up-E-Mail in Gmail verfasst, hat Kontext, den keine API erfassen kann — den Ton, die halb geschriebenen Absätze, die nebenbei geöffneten Tabs. Wir wollten, dass AI-Workflows diesen Live-Browser-Kontext so nutzen, wie es ein menschlicher Assistent tun würde, der neben Ihnen sitzt.
Architekturübersicht
Die Extension ist auf WXT 0.20 (Manifest V3) mit Svelte 5 und TypeScript aufgebaut. Sie implementiert einen MCP-Client, der sich über WebSocket mit dem JieGou-Server verbindet und 60+ Browser-Automatisierungstools bereitstellt, die AI-Workflows aufrufen können.
Der Nachrichtenfluss sieht so aus:
MCP Server → WebSocket → Background Service Worker → Content Script → PageWenn ein Recipe oder Workflow Browser-Interaktion benötigt, sendet es einen JSON-RPC 2.0 Tool-Call über die WebSocket-Verbindung. Der Background-Worker der Extension leitet ihn an den entsprechenden Tool-Executor weiter, der ein Content-Script in den aktiven Tab injiziert und das Ergebnis zurückgibt.
WebSocket-Bridge
Der WebSocket-Proxy behandelt Authentifizierung, Heartbeats, Reconnection und Token-Refresh.
Authentifizierung erfolgt beim Verbinden — der Client sendet eine authenticate-Nachricht mit einem JWT-Token. Der Server validiert ihn und beginnt, Tool-Calls zu akzeptieren.
Heartbeats laufen alle 15 Sekunden auf Anwendungsebene (nicht auf WebSocket-Protokoll-Pings basierend). Wenn ein Pong nicht innerhalb von 5 Sekunden eintrifft, wird die Verbindung als tot betrachtet und die Reconnection beginnt.
Auto-Reconnect verwendet eine 3-Sekunden-Verzögerung bei Disconnect mit exponentiellem Backoff. Token-Refresh erfolgt proaktiv 5 Minuten vor JWT-Ablauf über einen REST-Endpunkt, sodass die Verbindung nie wegen abgelaufener Anmeldedaten abbricht.
Tool-Executor-Pipeline
Alle Tools erweitern eine BaseBrowserToolExecutor-Klasse, die gemeinsame Helper bereitstellt: injectContentScript() mit Ping/Pong-Deduplizierung, sendMessageToTab(), getActiveTabOrThrow() und Tab-Focus-Management.
Tools fallen in mehrere Kategorien:
Seiteninteraktion — click_element, fill_form_field, select_dropdown, check_box, scroll_page und navigate. Diese operieren auf DOM-Elementen, die durch CSS-Selektoren oder automatisch generierte Referenz-IDs identifiziert werden.
Content-Lesen — read_page parst das DOM und weist interaktiven Elementen stabile Referenz-IDs zu. So “sieht” die AI eine Seite — sie bekommt strukturierten Text mit anklickbaren Referenzen statt rohem HTML.
Plattformspezifische Extraktoren — web_fetcher hat spezialisierte Parser für Gmail, Slack, Jira, Salesforce, ServiceNow und HubSpot. Statt generischem DOM-Scraping verstehen diese die Markup-Struktur jeder Plattform und extrahieren saubere, typisierte Daten.
Browser-Interna — javascript führt beliebigen Code über Chrome DevTools Protocol Runtime.evaluate aus, network_capture überwacht HTTP-Traffic, screenshot erfasst den Viewport oder bestimmte Elemente, und gif_recorder erstellt animierte Aufnahmen von mehrstufigen Interaktionen.
Inject-Scripts: Ausführung in der Welt der Seite
Der kniffligste Teil der Architektur sind Inject-Scripts. Content-Scripts laufen in einer isolierten Welt — sie können das DOM lesen, aber nicht auf den JavaScript-Kontext der Seite, React-Component-State oder Framework-Interna zugreifen.
Wir haben 16 TypeScript-Module, die als IIFEs über ein benutzerdefiniertes esbuild-Plugin gebündelt und in die MAIN-Welt injiziert werden. Dies ermöglicht ihnen den Zugriff auf React-Interna, das Aufrufen von seiteneigenen APIs und die Interaktion mit Single-Page-App-Routern.
Die Injektion verwendet Ping/Pong-Deduplizierung, um zu vermeiden, dass dasselbe Script zweimal in einen Tab injiziert wird, und Ergebnisse fließen über window.postMessage zurück zum Content-Script, dann hoch zum Background-Worker.
Was wir gelernt haben
Manifest V3 Service Worker sind kurzlebig. Sie können jederzeit vom Browser beendet werden. Wir mussten die WebSocket-Verbindung widerstandsfähig gegen Service-Worker-Neustarts machen — transparentes Reconnecting ohne Verlust ausstehender Tool-Calls.
Plattformspezifisches Parsen schlägt generisches Scraping. Unsere erste Version nutzte generische DOM-Extraktion für alles. Gmails HTML ist tief verschachtelt und ändert sich zwischen Updates. Das Schreiben gezielter Parser für jede Plattform (bisher 6) verbesserte Zuverlässigkeit und Datenqualität dramatisch.
MCP ist ein gutes Protokoll dafür. Die JSON-RPC 2.0-Basis mit tools/list-Discovery und typisierten tools/call-Aufrufen ist einfach genug zu implementieren, aber strukturiert genug, um zuverlässig zu sein. Wir fanden es einfacher zu erweitern, als es der Bau eines eigenen Protokolls gewesen wäre.
Was kommt als Nächstes
Wir arbeiten daran, plattformspezifische Handler zu erweitern, die Zuverlässigkeit der Element-Zielerfassung über Single-Page-App-Navigation hinweg zu verbessern und Wege zu erkunden, Tool-Definitionen mit dem breiteren MCP-Ökosystem zu teilen.
Wenn Sie MCP-Integrationen oder Browser-Automatisierungstools bauen, würden wir gerne hören, welche Muster Sie als nützlich empfunden haben. Das Protokoll ist noch jung und die Community findet gemeinsam Best Practices heraus.