Einen KI-Assistenten über MCP anbinden

Über MCP (Model Context Protocol) kommt ein Assistent an Werkzeuge, die er selbst nicht mitbringt. Richte deinen auf Guard.ch aus, und er kann Seiten öffnen und lesen, klicken, tippen, Formulare ausfüllen, Dateien hochladen, JavaScript ausführen und Screenshots machen: in einem isolierten Cloud-Browser, vom Standort deiner Wahl aus.

Auf deinem Rechner läuft dabei nichts. Kein lokaler Browser-Dienst, kein Treiber, den du aktuell halten musst, und auch kein Modell-Schlüssel, den du hier hinterlegst. Guard.ch stellt den Browser, den Lebenszyklus der Sitzung, den Ausgang ins Netz und eine Live-Ansicht, in der du jederzeit übernehmen kannst; das Modell bleibt bei deinem Client.

Was du brauchst

Endpunkt

https://api.guard.ch/mcp

Transport

Streamable HTTP, jede Anfrage für sich

Authentifizierung

Ein App-Schlüssel von Guard.ch im Header

Plan

Ein Plan mit programmatischem Zugriff; die 30-tägige Testphase deckt ihn ab

Browser

Jedes Chromium-Image, das dein Plan erlaubt, standardmässig Chrome

Parallelität

Bis zu drei laufende Sitzungen pro Person, aus denen die Person und ihre Agenten gleichermassen schöpfen

App-Schlüssel erstellen

Erstelle und verwalte deine API-Schlüssel im Dashboard von browser.lol. Melde dich mit demselben Konto an wie bei Guard.ch.

• Ein Schlüssel pro Client. Einer pro Assistent, Rechner oder Pipeline hält den Widerruf chirurgisch präzise: Ziehst du einen, steht dieser eine Client still und sonst nichts.
• Ablaufdatum setzen. Nie, 30 Tage, 90 Tage oder ein Jahr, festgelegt beim Erstellen. Alles, was unbeaufsichtigt läuft, fährt mit einem Datum sicherer.
• Nur einmal sichtbar. Der Schlüssel wird genau einmal angezeigt, beim Erstellen. Ein verlorener Schlüssel wird ersetzt, nicht wiederhergestellt: widerrufen und einen neuen anlegen.
• Widerruf wirkt sofort. Ein widerrufener Schlüssel funktioniert augenblicklich nicht mehr, auch mitten im Gespräch.

Endpunkt und Authentifizierung

Es gibt einen Endpunkt, und er spricht Model Context Protocol über Streamable HTTP. Jede Anfrage steht für sich, ein Gespräch übersteht also einen Neustart des Clients mitten in der Arbeit.

https://api.guard.ch/mcp

Schick den Schlüssel in einem dieser beiden Header. In die URL gehört er nie, dort würde er in Browserverlauf, Proxy-Logs und Analysedaten landen:

• Authorization: Bearer YOUR_API_KEY als Bearer-Token, so wie es jeder Schnipsel unten macht.
• x-api-key: YOUR_API_KEY im Hersteller-Header, für Clients, die Authorization nicht setzen können.

Server im Client eintragen

Such deinen Client, setz die Konfiguration ein und ersetze YOUR_API_KEY durch den Schlüssel, den du eben erstellt hast. Derselbe Schlüssel gilt überall, ein zweiter Rechner braucht also nur diesen Schritt.

claude mcp add --transport http guardch https://api.guard.ch/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

{
  "mcpServers": {
    "guardch": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://api.guard.ch/mcp",
        "--header", "Authorization:Bearer YOUR_API_KEY"
      ]
    }
  }
}

{
  "mcpServers": {
    "guardch": {
      "url": "https://api.guard.ch/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

code --add-mcp '{"name":"guardch","type":"http","url":"https://api.guard.ch/mcp","headers":{"Authorization":"Bearer YOUR_API_KEY"}}'

codex mcp add guardch --url https://api.guard.ch/mcp \
  --bearer-token-env-var GUARDCH_API_KEY

gemini mcp add --transport http guardch https://api.guard.ch/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

{
  "mcpServers": {
    "guardch": {
      "serverUrl": "https://api.guard.ch/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Starte den Client danach neu, damit er den neuen Server sieht. Mehr wird nicht installiert: Der Browser steht bei uns.

Etwas verlangen

Gib deinem Assistenten eine Aufgabe, für die er einen Browser braucht. Die Sitzung öffnet er selbst:

Öffne example.com in einem Guard.ch-Browser und sag mir, was auf der Seite steht.

Kommt eine Beschreibung der Seite zurück, steht die Verbindung. Meldet der Client, es gebe keine Tools, hat er seine MCP-Konfiguration noch nicht neu gelesen.

Die Tools für deinen Assistenten

35 Tools, alle mit dem Präfix browser_, mit strukturierten Antworten. Ein Assistent kann direkt bei browser_navigate anfangen: Guard.ch öffnet ihm dafür eine Sitzung und antwortet mit einem Accessibility-Snapshot der Seite, dessen ref-Kennungen alle weiteren Tools ansteuern. Das ist günstiger und viel präziser als das Arbeiten mit Screenshots.

Browser und Standort wählen

image beim Erstellen bestimmt den Browser: jedes Chromium-Image, das das Konto fahren darf, und Chrome, wenn du keines nennst. Firefox und Tor sind reine Surf-Browser und lassen sich nicht programmatisch steuern; wer sie verlangt, bekommt eine Absage samt Liste der Kennungen, die gehen.

country legt fest, wo die Sitzung ins Netz geht, als Land oder Stadt (us, de, us-dal), und residential verlangt statt des üblichen Tunnels eine Residential-Adresse; proxy nimmt einen Ausgang, den du selbst betreibst. Im Betrieb ändert browser_set_location das Ganze, was zählt, sobald eine Seite nach Land sperrt oder je nach Land etwas anderes zeigt.

Zusehen und übernehmen

Zu jeder Sitzung gehört eine Live-Ansicht, und die Sitzungen deiner Agenten stehen im Reiter Agenten deines Dashboards. Öffne eine davon, und du bist in derselben Ansicht, die auch ein Mensch nutzt: Die Seite läuft live, und beenden kannst du die Sitzung von dort ebenfalls.

Nimm Maus und Tastatur, sobald der Assistent an einer Anmeldung, einem Captcha oder einer Entscheidung hängt, die du lieber selbst triffst, und lass ihn danach weitermachen. Es ist ein Browser, auf den ihr beide zugreift, also fängt nichts von vorn an.

Analyse neben der Seite

In einem Chromium-Browser kann die Analyse von Guard.ch neben der Seite mitlaufen: Anfragen, Weiterleitungsketten, Antwort-Header, Konsolenausgabe, Sicherheitsprobleme, Downloads, Formulare, Cookies und Speicher, erkannte Technologien und Tracker, WHOIS-, IP- und Zertifikatsabfragen auf Zuruf, dazu eine Einschätzung pro Host mit ihren Quellen.

browser_session_analysis schaltet diese Spur für eine Sitzung ein und aus, die ein Mensch in der App gestartet hat: Eingeschaltet wird sie mitlesbar und im Dashboard als Untersuchung geführt. Eine Sitzung, die der Assistent selbst erstellt hat, kommt dafür nicht in Frage und wird in beide Richtungen abgelehnt (analysis_unavailable).

Wie sich die Sitzungen verhalten

• Sitzungen entstehen von selbst. Das erste Seiten-Tool öffnet eine, wenn unter dem Schlüssel keine läuft. Laufen mehrere, wird ein Aufruf ohne session_id abgelehnt statt geraten. So landet ein beiläufiger Aufruf nie im falschen Browser.
• Sitzungen im Leerlauf enden von selbst. Eine Sitzung endet wenige Minuten nach dem letzten Tool-Aufruf oder nachdem sich ein CDP-Client getrennt hat, spätestens aber an ihrem absoluten Zeitlimit (eine Minute bis sechs Stunden, standardmässig eine Stunde). Beendest du sie selbst, ist der Platz sofort frei.
• Wiederholungen sind ungefährlich. Ein Idempotenzschlüssel beim Erstellen spielt die geglückte Erstellung noch einmal ab, statt einen zweiten Browser zu öffnen. Genau das willst du hinter einer Warteschlange oder einem Job, der es erneut versucht.
• Mensch und Agent teilen ein Konto. Dein Assistent kann die Sitzungen auflisten, steuern und beenden, die du in der App gestartet hast, und du kannst dasselbe mit seinen. Schliesst er eine von deinen, ist das Fenster weg, dem du gerade zusiehst: ein guter Grund, Sitzungen zu benennen.
• Weiter als bis zu deinem Konto reicht es nicht. Jedes Tool arbeitet nur auf deinen eigenen Sitzungen. Sitzungen anderer Mitglieder sind über den Server weder sichtbar noch erreichbar.

Grenzen und Absagen

• Programmatischer Zugriff hängt am Plan. Ohne ihn antwortet jeder Aufruf mit einem Hinweis auf ein Upgrade statt mit einem Ergebnis. Beide bezahlten Pläne haben ihn, die 30-tägige Testphase ebenfalls.
• Gerechnet wird in gleichzeitigen Sitzungen: bis zu drei pro Person. Jede Person im Plan darf bis zu drei Sitzungen gleichzeitig laufen haben, und die Agenten, die mit ihrem Schlüssel arbeiten, schöpfen aus denselben drei. Sind alle drei belegt, wird eine neue Sitzung abgelehnt und nicht eingereiht.
• Die meisten Tools sind kostenlos. Nur browser_act und browser_extract brauchen je einen Modellaufruf und belasten das tägliche KI-Budget des Kontos. Residential-Ausgänge werden gegen das Datenvolumen des Workspaces in dieser Abrechnungsperiode gezählt. Alle anderen Tools sind kostenlos.
• Das Erstellen ist ratenbegrenzt. Limits pro Minute, Stunde und Tag schützen die Plattform. Normale Agentenarbeit kommt nie in ihre Nähe, eine Schleife ausser Kontrolle schon.
• Gespeichert wird nichts. Eine geschlossene Sitzung ist weg, mitsamt allem, was sie gesehen hat. Die Liste behält 30 Tage an Einträgen (was lief, wann, wie lange), nie die Seiten selbst.

Sicherheit

• Ein App-Schlüssel ist ein Passwort-Äquivalent: Er gehört in den Schlüsselspeicher deines Clients oder in eine Umgebungsvariable, nie in eine geteilte Konfigurationsdatei oder einen Link. Rutscht er dir raus, widerrufst du ihn im Reiter «Apps».
• Der Schlüssel reist im Header. Halte ihn aus URLs heraus, dort würde er in Browserverlauf, Proxy-Logs und Analysedaten landen.
• Seiten laden in unserer Infrastruktur, nie auf dem Rechner, auf dem der Assistent läuft, und nie in einem Browserprofil von dir: Jede Sitzung ist ein Wegwerf-Container.
• browser_act sendet den Accessibility-Baum der Seite an OpenRouter; browser_extract sendet zusätzlich den sichtbaren Text. Hat sich eine Person über die Live-Ansicht angemeldet, können darin ihre eigenen Daten enthalten sein. Kein anderes Tool sendet Seiteninhalte aus dem Cluster.
• Die Sitzung eines Agenten ist so sichtbar wie die eines Menschen. Sie steht im Dashboard, du kannst live zusehen und sie jederzeit von Hand beenden.
• Alles läuft über TLS, und für die Sitzungen gilt derselbe AVV wie für den Rest des Produkts.

Wenn etwas klemmt

Fast immer ist es einer dieser Fälle:

Der Client zeigt keine Tools. Er hat seine Konfiguration nicht neu gelesen. Starte ihn nach dem Eintragen neu und prüf, ob wirklich der /mcp-Endpunkt oben eingetragen ist und nicht die REST-Basis.

Jeder Aufruf antwortet mit einem Upgrade-Hinweis. Das Konto hinter dem Schlüssel hat keinen Plan mit programmatischem Zugriff. Starte die Testphase, oder frag einen Workspace-Manager nach einem Platz.

Ein Aufruf wird als mehrdeutige Sitzung abgelehnt. Unter dem Schlüssel laufen zwei oder mehr Sitzungen, und Guard.ch rät nicht, welche gemeint ist. Lass sie auflisten und gib die session_id von da an ausdrücklich mit.

Eine neue Sitzung wird abgelehnt. Entweder sind alle drei laufenden Sitzungen des Kontos belegt, oder das gewünschte Image lässt sich nicht programmatisch steuern. Die Absage sagt, was von beidem, und nennt die Kennungen, die gehen.

Der Schlüssel hörte mitten im Gespräch auf zu funktionieren. Er wurde widerrufen oder ist abgelaufen. Leg einen neuen an und trag ihn im Client nach.

Dieselben Browser ohne MCP

Ein Client, der kein MCP spricht, erstellt dieselben Sitzungen über REST und hängt Playwright oder Puppeteer an den CDP-Endpunkt, den jede zurückgibt. Diesen Weg beschreibt die API-Anleitung.

Nächste Schritte

Schlüssel unter Apps anlegen, Endpunkt im Client eintragen, den Assistenten um eine Seite bitten. Im Reiter Agenten stehen die Sitzungen deiner Assistenten, und du kannst dort zusehen oder sie beenden. Fehlt dein Client in dieser Anleitung, melde dich bei uns.