Wer N Werkzeuge mit M Modellen verbinden wollte, brauchte früher N×M Anpassungen. MCP entkoppelt Werkzeug- und Modellseite, sodass beide das Protokoll jeweils nur einmal implementieren. Der Beitrag erklärt diese Architektur, die Abstraktion von Browserumgebungen und Seitenaktionen sowie die weiterhin offenen Punkte.
Damit ein Agent tatsächlich Aufgaben erledigen kann, landet er am Ende meist im Browser: anmelden, Beiträge veröffentlichen, Daten erfassen oder Formulare ausfüllen. Technisch schwierig ist nicht das Klicken an sich, sondern der Integrationsaufwand, wenn ein Browser einem Agenten übergeben wird.
Die N×M-Falle bei Integrationen
Angenommen, es gibt N Werkzeuge und M Modelle. Ein Werkzeuganbieter muss für jedes Modell eine eigene Anbindung schreiben, während die Modellseite für jedes Werkzeug eine Adapterschicht benötigt. Beide Seiten pflegen ihre Implementierungen separat; insgesamt entstehen N×M Varianten.
Das Problem ist die Multiplikation. Ein zusätzliches Werkzeug bedeutet nicht nur eine weitere Aufgabe, sondern eine neue Verbindung zwischen diesem Werkzeug und jedem Modell. Umgekehrt kann eine neue Modellversion dazu führen, dass bereits angebundene Werkzeuge erneut geprüft werden müssen. Eine Fähigkeit kann noch so gut sein: Fehlt die Anpassung für ein bestimmtes Modell, lässt sie sich dort nicht nutzen – das Werkzeug bleibt in der Vermittlungsschicht hängen.
In der frühen Phase musste jeder seine eigene Lösung bauen. Dieselben Schritte – Umgebungen auflisten, einen Browser starten, eine Seite lesen – wurden für jeden Aufrufer neu geschrieben, oft mit unterschiedlicher Logik: Manche legten Wartezeiten in den Client, andere in den Server.
Das Protokoll entkoppelt beide Seiten
MCP (Model Context Protocol) wurde Ende 2024 öffentlich vorgestellt. Der Ansatz besteht darin, Werkzeugerkennung und Aufrufe in einem Standardformat zu definieren: Was wird angeboten, wie werden Parameter beschrieben und in welcher Struktur kommen Ergebnisse zurück?
Die Architektur wird dadurch zu einem Agenten mit einem MCP Client. Dieser Client verbindet sich nach dem Protokoll mit mehreren MCP Servern; dahinter liegen die eigentlichen Fähigkeiten. Der Implementierungsaufwand sinkt von N×M auf N+M: Die Modellseite implementiert den Client einmal, die Werkzeugseite den Server einmal.
Es gibt nur drei Rollen. Der Host ist die Anwendung, in der das Modell läuft, und startet den Client. Der Client implementiert das Protokoll, in der Regel gibt es einen pro Server. Der Server wird vom Werkzeuganbieter geschrieben und stellt Fähigkeiten als standardisierte Werkzeuge bereit.
Aktuell gibt es zwei Kommunikationsarten. Im lokalen Modus laufen Client und Server auf demselben Rechner und kommunizieren über Standardein- und -ausgabe; der Pfad ist kurz und die Konfiguration gering, weshalb dieser Modus bei Automatisierung häufig genutzt wird. Der Remote-Modus verwendet HTTP oder WebSocket und eignet sich für verteilte Bereitstellungen, verlangt aber zusätzliche Überlegungen zu Authentifizierung und Netzwerkgrenzen.
Im Browser werden drei Ebenen sichtbar
Wird eine Browserumgebung an das Protokoll angebunden, lassen sich die bereitgestellten Fähigkeiten grob in drei Ebenen einteilen.
Ganz oben steht die Umgebung: vorhandene Umgebungen eines Kontos auflisten, eine neue nach Konfiguration anlegen, eine bestimmte Umgebung starten, ihr einen Netzwerkausgang zuweisen und sie anschließend beenden. Solche Aktionen waren früher über unterschiedliche APIs verteilt; nun sind sie Werkzeuge, die das Modell finden und aufrufen kann. Nach dem Start wird üblicherweise ein Debug-Endpunkt zurückgegeben, etwa ein Port oder eine WebSocket-Adresse, die sich an Treiber wie Selenium oder Puppeteer übergeben lässt.
Die mittlere Ebene ist die Seite: eine Adresse öffnen, DOM oder Accessibility Tree auslesen, Tabs wechseln und Screenshots erstellen.
Die unterste Ebene umfasst Aktionen: klicken, Text eingeben, scrollen, auf eine Bedingung warten und Pop-ups behandeln.
Entscheidend ist nicht die Anzahl der Aktionen. Die Umgebung wird von einem Codeblock, den man selbst schreiben muss, zu einer Ressource, die der Agent auswählen und verwenden kann. Man beschreibt nur das Ziel; der Agent entscheidet, ob er eine neue Umgebung erstellt oder eine vorhandene wiederverwendet und in welcher Reihenfolge die Werkzeuge aufgerufen werden. Bei mehreren parallelen Umgebungen wird das besonders deutlich: Die Planung steht im Prompt statt fest im Skript.
Was derzeit noch ungelöst ist
Das Protokoll löst die Verbindung, nicht die Korrektheit. Einige leicht übersehene Punkte bleiben bestehen.
Die Qualität der Werkzeugbeschreibungen bestimmt das Ergebnis der Aufrufe. Falsche Parameter oder die Wahl des falschen Werkzeugs kann das Protokoll nicht ausgleichen. Mit wachsender Werkzeugzahl belegen die Beschreibungen außerdem Kontext, sodass zwischen Anzahl und Granularität abgewogen werden muss. Zu grobe Werkzeuge lassen unklar, wie viele Aufgaben sie abdecken; bei zu feiner Aufteilung ist der Kontext schnell gefüllt.
Berechtigungen und Auditierung stehen noch am Anfang. Viele Server laufen lokal auf einem einzelnen Rechner, starten mit erheblichen Rechten und bieten weder fein abgestufte Autorisierung noch vollständige Aufrufprotokolle. Im Remote-Modus muss zuerst geklärt werden, wer sich verbinden darf und was sichtbar ist.
Die Instabilität von Webseiten verschwindet ebenfalls nicht. Nicht auffindbare Elemente, schwankende Ladezeiten, abgelaufene Anmeldesitzungen und CAPTCHAs erfordern weiterhin Wartezeiten, Wiederholungen und Ausweichlogik. Das Protokoll vereinheitlicht lediglich den Einstiegspunkt.
Auch der Reifegrad des Ökosystems ist uneinheitlich. Verschiedene Server unterstützen nicht exakt dieselben Ressourcentypen, Rückgabestrukturen oder Fehlercodes. Werden mehrere Server in einer Aufgabe kombiniert, muss die Orchestrierung häufig weiterhin selbst geschrieben werden. Da sich das Protokoll weiterentwickelt, sind Verhaltensunterschiede zwischen Versionen zu beachten.
Eine weitere Grenze muss klar bleiben: Das Protokoll regelt, wie ein Modell Werkzeuge aufruft, nicht ob eine Aufgabe selbst regelkonform ist. Ob Datenerhebung autorisiert wurde, ein Konto für einen legitimen Zweck genutzt wird oder Plattformregeln verletzt werden, sind eigenständige Bewertungen und unabhängig davon, wie reibungslos die Verbindung funktioniert.
Bei mehreren Umgebungen beeinflussen deren Isolation sowie die abgestimmte Konfiguration von Netzwerkausgang, Zeitzone und Sprache das Ergebnis oft stärker als die Art der Anbindung. Auf der Ebene der Umgebungsisolation stellt PurpleMark Schnittstellen zum Erstellen und Starten von Umgebungen sowie zur Netzwerkkonfiguration bereit, die von AI-Werkzeugen aufgerufen und über denselben Client geplant werden können.
Dieser Beitrag erläutert nur technische Grundlagen. Verwenden Sie die beschriebenen Protokolle und Werkzeuge im Rahmen der geltenden Gesetze und Regeln.
