Kleine modulare Browser-Tools übertreffen MCP in puncto Token‑Effizienz und Entwicklerkontrolle.

Einführung

Die Diskussion darüber, ob Entwickler für alltägliche Agenten‑Aufgaben voll ausgestattete MCP (Model‑Centric Programming)‑Server benötigen, hat in den AI‑, Twitter‑ und Entwickler‑Communities an Fahrt aufgenommen. Die Kernfrage ist einfach: Können leichte, komponierbare Werkzeuge, die Agenten bereits verstehen, schwere MCP‑Manifeste ersetzen, dabei Tokens sparen und die Flexibilität bewahren? Dieser Artikel untersucht ein minimalistisches Toolkit, das auf Bash und kleinen Node‑Skripten basiert, vergleicht es mit populären MCP‑Implementierungen und skizziert praktische Workflows für Einzelentwickler und kleine Teams.

Token‑Effizienz: Die wahren Kosten von MCP‑Manifests

Wie MCP Tokens verbraucht

Beliebte MCP‑Server wie Playwright MCP und Chrome DevTools MCP liefern umfangreiche Werkzeugkataloge. Zum Beispiel:

• Playwright MCP – 21 Werkzeuge, ~13 700 Tokens (≈ 6,8 % von Claudes Kontextfenster)
• Chrome DevTools MCP – 26 Werkzeuge, ~18 000 Tokens (≈ 9 % des Kontextfensters)

Diese Token‑Zahlen entstehen bevor überhaupt Arbeit geleistet wird. Werden mehrere MCP‑Server kombiniert, multipliziert sich der Token‑Overhead, und Agenten müssen ausführliche Werkzeugbeschreibungen parsen, was zu Verwirrung und geringerer Komponierbarkeit führt.

Der Vorteil des minimalen Toolkits

Eine schlanke Alternative besteht aus einer knappen README (≈ 225 Tokens) plus einer Handvoll Node‑Skripten, die Puppeteer Core nutzen. Da Agenten Bash und JavaScript bereits verstehen, können sie diese Skripte direkt aufrufen, ohne große Skill‑Kataloge zu benötigen. Das Ergebnis ist ein Token‑Fußabdruck, der zwei Größenordnungen kleiner ist als bei traditionellen MCP‑Manifests und damit der klassischen Unix‑Philosophie kleiner, komponierbarer Werkzeuge entspricht.

Das minimale Browser‑Toolkit im Detail

Das Toolkit enthält sechs Skripte, die jeweils einen klar definierten Zweck erfüllen.

start.js

• Startet Chrome mit einem frischen oder geklonten Profil.
• Beendet eventuell laufende Chrome‑Prozesse, erzeugt ein temporäres Benutzer‑Daten‑Verzeichnis und startet Chrome mit Remote‑Debugging auf Port 9222.
• Versucht wiederholt, über puppeteer.connect eine Verbindung herzustellen, bis sie erfolgreich ist, und gibt dann eine Erfolgsmeldung aus.

Dieser deterministische Startvorgang eliminiert die Notwendigkeit komplexer RPC‑Schemata und bietet dem Agenten einen einfachen, zuverlässigen Vertrag.

nav.js

• Syntax: nav.js <URL> [new]
• Navigiert im aktiven Tab (oder öffnet einen neuen Tab, wenn new angegeben wird) und wartet auf DOMContentLoaded.
• Gibt eine klare Statusmeldung wie „opened“ oder „navigated“ zurück.

Das Skript spiegelt die natürliche Denkweise von Agenten bei Seitenaktionen wider: „gehe zu dieser Seite“ – ohne eine Flut von Klick‑, Hover‑ oder Scroll‑Varianten.

evil.js

• Führt beliebiges JavaScript im Kontext der Seite aus.
• Verwendung: evil.js "document.querySelectorAll('a').length"
• Erstellt eine asynchrone Funktion, evaluiert den Code und gibt die Ergebnisse als Schlüssel‑Wert‑Paare (für Objekte/Arrays) oder als Skalarwert aus.

Durch das Zulassen von nativen DOM‑Codes reduziert evil.js den Token‑Overhead, der nötig wäre, jede mögliche Interaktion zu beschreiben, und ermöglicht direkte Datenauslese, ohne große Ergebnisse über den Prompt zu streamen.

screenshot.js

• Erstellt einen Screenshot des Viewports der aktiven Seite.
• Speichert das Bild im temporären Verzeichnis des Betriebssystems mit einem Zeitstempel‑Dateinamen und gibt den Pfad aus.
• Der Agent kann das Bild anschließend einlesen und bei Bedarf Vision‑Modelle anwenden.

Bilder als Dateien zu speichern statt sie im Prompt einzubetten, reduziert den Token‑Verbrauch drastisch.

pick.js

• Bietet einen interaktiven visuellen Selektor.
• Zeigt ein Banner und ein Hervorhebungs‑Rechteck, das dem Mauszeiger folgt; ein Klick wählt ein Element, Ctrl/Cmd+Click ermöglicht Mehrfachauswahl, Enter bestätigt, Esc bricht ab.
• Gibt strukturierte Informationen zu jedem ausgewählten Element zurück, darunter Tag, ID, Klasse, gekürzter Text, CSS‑Selektor‑Kette und ein Ausschnitt des äußeren HTML.

Dieses Werkzeug überbrückt menschliche Intention und Code und erlaubt Agenten, zuverlässige Selektoren für Scraper oder Automatisierungsskripte zu erzeugen.

Unterstützende Hilfsskripte

Zusätzliche Dienstprogramme (z. B. ein Cookies‑Helper) runden das Toolkit ab und erledigen gängige Browser‑Aufgaben, ohne das Token‑Budget zu erhöhen.

Aufbau eines nahtlosen Workflows

1. Erstelle ein dediziertes Verzeichnis (z. B. ~/agent-tools).
2. Klonen Sie jedes Tool‑Repository in diesen Ordner.
3. Füge das Verzeichnis zu deinem PATH hinzu – etwa über einen Shell‑Alias oder eine Umgebungsvariable – damit der Agent die Skripte direkt aufrufen kann.
4. Referenziere die README nur bei Bedarf im Kontext des Agenten, um den Prompt schlank zu halten.
5. Setze das Tools‑Verzeichnis als Arbeitsverzeichnis für Claude oder andere LLM‑Interfaces, sodass Werkzeugdefinitionen bei Bedarf eingebunden werden können.

Durch Befolgen dieser Schritte arbeiten Agenten mit einem minimalen Befehlssatz, vermeiden ständige Verzeichniswechsel und benötigen keine massiven Skill‑Manifeste.

Wann MCP noch Sinn macht

In Unternehmensumgebungen ist der direkte Zugriff auf APIs oder das Dateisystem häufig eingeschränkt. In solchen Fällen kann ein MCP‑Server als regelbasierter Vermittler fungieren und:

• Rollenbasierte Berechtigungen bereitstellen
• Auditable Datenabfragen ermöglichen
• Einen kontrollierten Zugriff auf interne Dienste gewähren

Dennoch sollten Entwickler auch hier den Token‑Fußabdruck der Werkzeugbeschreibungen des MCP‑Servers im Auge behalten. Ein Manifest mit 13 – 18 k Tokens beansprucht noch immer einen merklichen Teil des Kontextfensters; daher bleibt es bewährte Praxis, Beschreibungen knapp zu halten und große Ausgaben in Dateien auszulagern.

Fazit

Das minimalistische Toolkit zeigt, dass kleine, komponierbare Skripte dieselbe – oder sogar größere – Funktionalität wie schwere MCP‑Server liefern können, dabei den Token‑Verbrauch dramatisch senken und die Entwicklerkontrolle erhöhen. Für Einzelentwickler und kleine Teams empfiehlt sich folgender Ansatz:

• Nutze start.js, nav.js, evil.js, screenshot.js, pick.js und die unterstützenden Helfer.
• Halte Werkzeugdefinitionen in einer knappen README und rufe sie über Bash auf.
• Setze MCP‑Server nur dort ein, wo strenge Governance oder ein eingeschränkter API‑Zugang erforderlich sind.

Indem man die Unix‑Philosophie „ein Ding gut machen“ annimmt, bleiben Agenten schnell, günstig und anpassungsfähig – genau die Eigenschaften, die moderne, KI‑unterstützte Entwicklung benötigt.