Ein MCP-Konnektor deckt nicht den ganzen Dienst ab, sondern nur eine Auswahl seiner API-Aufrufe – genau die, die beim Bau des Konnektors vorgesehen wurden. Bei Gmail merkst du das schnell: MCP liest eine Nachricht und versieht sie mit einem Label, zeigt dir aber nicht den Inhalt eines Anhangs und legt auch keinen Filter an. Alles Übrige beherrscht nur die Gmail-API selbst, und dafür musst du direkt auf sie zugreifen.

Ausführlich behandeln wir das im Tipp darüber, was zu tun ist, wenn die KI sagt, dafür gebe es kein Werkzeug – dort stellen wir alle Wege zu einem Dienst vor und zeigen den Prompt, mit dem du die KI auf jeden davon schickst. Heute setzen wir diese Theorie in die Praxis um.

API steht für application programming interface, auf Deutsch Programmierschnittstelle. Dahinter steckt derselbe Dienst, den du als Mensch über eine Website und ihre Schaltflächen bedienst – Programmen gegenüber zeigt er sich nur anders: als Liste von Vorgängen, die sie von aussen anfordern können. Ein MCP-Konnektor ruft diese API auf und gibt dem KI-Agenten einen Ausschnitt davon weiter; eine eigene Integration ruft sie ohne Zwischenstelle auf.

Damit ein KI-Agent mit der Gmail-API sprechen kann, brauchst du drei Dinge: ein Projekt in der Google Cloud Console, die darin freigeschaltete Gmail-API und eigene OAuth-Zugangsdaten, also Client-ID und Client-Geheimnis, mit denen sich deine Integration gegenüber Google ausweist. Alle drei richtest du im Browser ein; die Autorisierung und den ersten Test überlässt du Claude Code.

Wenn du nur Mails lesen und senden willst, bleib beim fertigen Konnektor – wir zeigen ihn in der Lektion über die Google-Konnektoren, wo du alles mit ein paar Klicks verbindest.

Die Google-Konsole ist nur teilweise übersetzt, und die Namen der übersetzten Einträge ändern sich von Monat zu Monat. Deshalb nennen wir hier jedes Element des Bildschirms auf Deutsch und setzen den englischen Namen in Klammern dahinter – nach diesem englischen Namen suchst du, wenn bei dir eine andere Beschriftung steht.

Zu jedem Bildschirm geben wir dir ausserdem einen Verweis, der direkt dorthin führt, beschriftet mit dem Wort Link – ein Klick, und du bist dort, ohne dich durchs Menü zu suchen. Google ändert die Adressen in der Konsole immer wieder, wir versprechen dir also nicht, dass alle in einem Monat noch funktionieren. Führt einer davon ins Leere, steht daneben der Name der Seite – über den findest du sie auch von Hand.

Am leichtesten gehst du diese Lektion zusammen mit Claude Code durch: Sag ihm, dass du eine eigene Integration über die Google Cloud Console bauen willst, gib ihm den Link zu diesem Beitrag und stell eine wichtige Bedingung:

Ich möchte eine eigene Gmail-Integration über die Google Cloud Console anbinden. Lies https://howstart.cc/de/lektionen/eigene-google-integration-ueber-die-cloud-console/ und führe mich Schritt für Schritt hindurch. Wichtig: Beschreibe mir einen Schritt und warte, bis ich bestätige, dass ich ihn hinter mir habe. Erst dann geh zum nächsten Schritt über.

Wenn du irgendwo hängen bleibst – beim ersten Anlauf ist das normal –, genügt ein «ich sehe diese Schaltfläche nicht» oder «ich bekomme einen Fehler über gesperrten Zugriff». So musst du die passende Stelle nicht selbst mitten in einer langen Anleitung suchen.

Leg ein Projekt in der Google Cloud Console an

Die Google Cloud Console ändert den Aufbau ihrer Bildschirme und deren Namen – der ganze Bereich rund um die Autorisierung heisst heute Google Auth Platform und ist auf mehrere einzelne Seiten verteilt. Die Namen der Elemente geben wir nach der Google-Dokumentation an; den Aufbau des Menüs verstehst du besser als grobe Orientierung denn als Abbild, das bis ins letzte Detail stimmt.

Ein Projekt fasst alles Weitere zusammen: freigeschaltete APIs, Zustimmungsbildschirm, Zugangsdaten und Kontingente. Leg es mit der Schaltfläche Projekt erstellen (Create project) auf der Seite Ressourcen verwalten (Manage resources) an – Link. Im Fenster gibst du den Projektnamen an und wählst die übergeordnete Ressource (Parent resource), also eine Organisation oder einen Ordner. Zu einem gewöhnlichen Google-Konto gehört weder das eine noch das andere, dieses Feld lässt du also unverändert. Die Projekt-ID setzt Google automatisch aus dem Namen zusammen; jetzt kannst du sie noch korrigieren, nach dem Anlegen lässt sie sich nicht mehr ändern.

Gib dem Projekt einen allgemeinen Namen. «Verbindung zu Gmail» wirkt die erste Woche lang vernünftig. Spätestens an dem Tag, an dem du im selben Projekt die API von Google Drive oder eines anderen Dienstes freischaltest, stimmt dieser Name nicht mehr mit dem überein, was im Projekt steckt. Ein Name, der den Bereich der Integration beschreibt, etwa «Büro-Integrationen» oder «Automatisierungen der Firma», passt dagegen auch dann noch, wenn weitere Google-Dienste dazukommen.

Projekte in Google Cloud

Schalte die API des Dienstes frei, mit dem du dich verbindest

Ein frisches Projekt kann noch gar nichts. Den Zugriff auf jeden Google-Dienst schaltest du einzeln frei, in der API-Bibliothek (API Library): Wähl im Menü APIs und Dienste (APIs & Services), dann Bibliothek (Library) und darin den Bereich Google Workspace – Link. Klick auf die API, die du brauchst – für E-Mail ist das die Gmail API –, und schalte sie mit der Schaltfläche Aktivieren (Enable) frei – Link.

Die Auswahl der APIs ist nicht endgültig – weitere Dienste kannst du später freischalten und bereits laufende auch wieder abschalten, wenn du merkst, dass du sie nicht mehr brauchst. Das alles bleibt innerhalb einer einzigen Integration; ein neues Projekt in der Google Cloud Console brauchst du dafür nicht. Die weiteren Schritte zeigen wir am Beispiel von Gmail; für jeden anderen Google-Dienst läuft es genauso ab, nur mit einer anderen API und einem anderen Bereich.

APIs von Google Workspace freischalten

Richte den OAuth-Zustimmungsbildschirm und die Bereiche ein

Der Zustimmungsbildschirm ist das Fenster, das Google beim Anmelden zeigt: der Name der Anwendung und die Liste der Berechtigungen, um die sie bittet. Hinter diesem Fenster steht in deinem Fall nur eine einzige Person, nämlich du selbst – das Verfahren läuft trotzdem genauso ab wie bei einer Anwendung für tausend Leute. In der Konsole liegen diese Einstellungen im Bereich Google Auth Platform, aufgeteilt auf mehrere Seiten: Branding, Zielgruppe (Audience), Clients und Datenzugriff (Data Access).

Auf der Seite Zielgruppe – Link – wählst du den Nutzertyp Extern (External); der umfasst jedes gewöhnliche Google-Konto, deines eingeschlossen. Darunter steht der Veröffentlichungsstatus, und hier klickst du gleich auf App veröffentlichen (Publish app). Ein neues Projekt startet im Status Testen (Testing), und in diesem Status musst du die Autorisierung alle sieben Tage wiederholen, denn Zustimmung und Aktualisierungs-Token laufen nach dieser Frist ab.

Im Status In Produktion (In production) gibt es keine Kontoliste mehr, die den Zugang einschränkt: Formal kann sich bei deiner Integration jede Person mit einem Google-Konto anmelden. In der Praxis wird das ausser dir niemand tun, denn um dieses Fenster überhaupt zu sehen, braucht man deine Client-ID und dein Client-Geheimnis – und die liegen in einer Datei auf deiner Festplatte. Google hat diese Anwendung nicht geprüft, beim Anmelden siehst du deshalb eine Warnung, dass sie ungeprüft ist; über die Schaltfläche Erweitert (Advanced) kommst du trotzdem weiter. Mit einer Prüfung durch Google verschwinden die Warnung und die Grenze von hundert neuen Nutzenden – bei einer Integration für eine einzelne Person brauchst du weder das eine noch das andere.

Die Bereiche (scopes) fügst du auf der Seite Datenzugriff hinzu – Link. Du tippst sie nicht von Hand ein: Es öffnet sich eine Liste mit Suchfeld, in der du den Bereich über seinen Namen suchst und den gewünschten anklickst. Ein Bereich legt zwei Dinge auf einmal fest: welche Berechtigungen Google im Zustimmungsfenster abfragt und was das Token danach darf – und ein Token darf genau so viel, wie du ihm bei der Autorisierung zugestanden hast. Hier liegt ein Reflex nahe, der die ganze Arbeit zunichtemacht: Ein Bereich nur zum Lesen wirkt vorsichtig, macht deine Integration aber schwächer als den Konnektor, den du gerade hinter dir lässt. Wähl die Bereiche deshalb so, dass sie alles abdecken, was der Konnektor konnte – und nimm das dazu, was er nicht konnte. Für Gmail sind das zwei:

  • https://www.googleapis.com/auth/gmail.modify – Nachrichten lesen, erstellen und senden; endgültig löschen, ohne Umweg über den Papierkorb, geht damit nicht. Damit erledigst du alles, was der Konnektor konnte, und zusätzlich kommst du an den Inhalt von Anhängen heran und kannst HTML-formatierte Nachrichten senden, also mit Fettschrift, Listen und Links im Text.
  • https://www.googleapis.com/auth/gmail.settings.basic – Einstellungen und Filter von Gmail, also genau das, was der Konnektor gar nicht anfasst.

Den Bereich https://mail.google.com/ legst du nicht dazu. Er umfasst dasselbe und zusätzlich das endgültige Löschen ohne Umweg über den Papierkorb – ein Fehler im Skript entfernt Nachrichten dann spurlos.

Zielgruppe und Testnutzende OAuth-Bereiche von Google

Erzeuge die OAuth-Zugangsdaten für die Anwendung

Die Zugangsdaten sind ein Paar: Client-ID und Client-Geheimnis. Mit diesen beiden weist sich deine Integration gegenüber Google aus. Erzeug dieses Paar auf der Seite Clients – Link – mit der Schaltfläche Client erstellen (Create client). Als Anwendungstyp wähl Desktop-App (Desktop app) – dieser Typ passt zu einer Integration, die auf deinem eigenen Rechner läuft. Die übrigen Einstellungen lässt du unangetastet.

Gleich nach dem Erstellen des Clients lädst du die JSON-Datei mit den Daten herunter – in der Google-Dokumentation heisst sie client_secret.json. Das Client-Geheimnis siehst du nur in diesem einen Moment; später lässt es sich weder ansehen noch erneut herunterladen. Geht es verloren, musst du ein neues Geheimnis erzeugen und die Datei austauschen.

Wir empfehlen dir, ein eigenes Verzeichnis anzulegen, das nur dem Aufbewahren von Zugangsschlüsseln dient, etwa zugangsschluessel.

Anwendungen auf dem eigenen Rechner

Führ die erste Autorisierung durch und hol dir das Token

Das Klicken in der Google Cloud Console endet an dieser Stelle. Jetzt musst du aus der Datei mit den Client-Daten ein Token gewinnen, mit dem die Integration im Alltag arbeitet – und das ist bereits Arbeit für Claude Code: ein kurzes Skript schreiben, es bei dir ausführen und die Fehlermeldung lesen, falls etwas nicht aufgeht.

Im Verzeichnis zugangsschluessel liegt die Datei client_secret.json mit OAuth-Daten vom Typ Desktop app zu einem Projekt in Google Cloud. Schreib und starte ein Skript, das eine einmalige Autorisierung mit den Bereichen gmail.modify und gmail.settings.basic durchführt und das Aktualisierungs-Token in eine Datei daneben schreibt. Zeig mir den Link zum Anmelden und warte, bis ich bestätige.

Du siehst dann dasselbe wie alle, die sich bei einer Anwendung über Google anmelden: das Anmeldefenster und die angeforderten Berechtigungen, genau die von deinem Zustimmungsbildschirm. Nach der Zustimmung schickt Google einen Code an eine lokale Adresse zurück. Das Skript tauscht ihn gegen ein Zugriffs-Token und ein Aktualisierungs-Token ein. Von da an meldet sich die Integration ohne dich an.

Nach dem Klick auf die Zustimmung landet der Browser oft auf einer Seite, die leer aussieht – weisser Bildschirm und keine Meldung. So soll es sein: Das Skript hat die Antwort bereits entgegengenommen, und die Seite selbst hat nichts anzuzeigen. Schreib Claude Code dann, dass die Anmeldung erledigt ist, und bitte darum, den Vorgang abzuschliessen. Stellt sich heraus, dass beim Skript nichts angekommen ist, kopier die Adresse dieser leeren Seite aus der Adresszeile des Browsers und füg sie im Gespräch ein – in der Adresse steckt der Code, mit dem Claude Code die Autorisierung abschliesst.

Wenn du statt des Zustimmungsfensters eine Meldung über gesperrten Zugriff bekommst, geh zurück auf die Seite Zielgruppe (Audience) – Link – und prüf den Veröffentlichungsstatus. Im Status Testen (Testing) kann sich nur ein Konto anmelden, das auf der Liste der Testnutzenden steht, klick also auf App veröffentlichen (Publish app). In Produktion (In production) schränkt keine Kontoliste die Anmeldung ein, die Ursache liegt dann woanders – meistens fehlt ein Bereich auf der Seite Datenzugriff (Data Access) – Link.

Ablauf von OAuth-Token

Häng die Daten an deine Integration und teste sie

Bevor du das Thema als erledigt abhakst, prüf die ganze Kette: Projekt, freigeschaltete API, Zustimmung, Token. Am einfachsten mit einer einzigen echten Anfrage.

Verwende das gespeicherte Token und gib die Betreffzeilen der drei letzten Nachrichten aus meinem Postfach aus. Ändere nichts im Postfach und nichts in den Dateien mit den Schlüsseln – das soll ausschliesslich gelesen werden.

Ein Fehler an dieser Stelle hilft dir weiter, denn jede Meldung weist auf eine andere Ursache hin. Wird die Anfrage mit dem Hinweis abgelehnt, die API sei nicht freigeschaltet, schickt dich das in die API-Bibliothek (API Library) – Link. Meistens stellt sich heraus, dass sie freigeschaltet ist, nur in einem anderen Projekt als dem, aus dem die Zugangsdaten stammen. Wird die Anfrage wegen eines fehlenden Bereichs abgelehnt, wurde dein Token noch mit dem alten Satz Berechtigungen ausgestellt: Einen Bereich auf der Seite Datenzugriff (Data Access) – Link – zu ergänzen, ändert nichts, solange du die Autorisierung nicht wiederholst und dir kein neues Token ausstellen lässt.

Nimm weitere Google-Dienste in dasselbe Projekt auf

Für jeden weiteren Google-Dienst reichen dasselbe Projekt und dieselben Zugangsdaten aus. Du gehst zurück in die API-Bibliothek (API Library) – Link –, schaltest den nächsten Dienst frei und ergänzt seinen Bereich auf der Seite Datenzugriff (Data Access) – Link. Die Autorisierung wiederholst du, denn dein altes Token wurde mit den alten Berechtigungen ausgestellt. Ein zweites Projekt legst du nicht an.

Am nützlichsten sind dabei die Google Sheets API und die Google Docs API. Der fertige Konnektor von Google Drive liest Dateien, benennt sie um und verschiebt sie zwischen Ordnern, den Inhalt einer bestehenden Tabelle oder eines bestehenden Dokuments rührt er aber nicht an. Bearbeiten lässt sich eine Datei erst über die API – genau dort hört der Konnektor auf.

Für den ganzen übrigen Teil von Google gibt es überhaupt keinen Konnektor: Auf claude.ai bestehen genau drei offizielle Verbindungen zu Google – Gmail, Google Kalender und Google Drive. Mit der Google Tasks API legt die KI Aufgaben auf deinen Aufgabenlisten an und hakt sie ab. Mit der Google Chat API liest und schreibt sie Nachrichten im Chat deiner Firma. Beide Dienste schaltest du genauso frei wie Gmail – ein Klick in der API-Bibliothek, ein Bereich, eine Autorisierung.

Die Verbindung zur Mail ist nur der Zugang zum Werkzeug. Wie du Claude Code deine Schreibweise beibringst, damit die Antworten auf Mails nach dir klingen, liest du in der Lektion über den Ghostwriter.

Konnektoren für Google Workspace Google Tasks API Google Chat API

Sichere deine Zugangsschlüssel

Im Verzeichnis zugangsschluessel liegen jetzt zwei Dateien, und die beiden haben unterschiedliche Aufgaben: client_secret.json sagt Google, welche Anwendung um Zugriff bittet; in der Datei mit dem Token steckt deine Zustimmung, und damit öffnet die Integration dein Postfach. Die Google-Dokumentation sagt zu beiden knapp dasselbe: Sie gehören an einen Ort, auf den ausschliesslich deine Integration Zugriff hat.

Halte dieses Verzeichnis deshalb ausserhalb des Projektordners, in dem du mit Claude Code arbeitest, und speichere es an keinem Ort, an dem noch jemand anderes hineinschauen kann: nicht auf einem geteilten Laufwerk, nicht im Anhang einer Mail und nicht in einem öffentlichen Code-Repository.

Füg den Inhalt dieser Dateien auch nicht in den Chat ein, damit «die KI sieht, ob alles stimmt». Ein Geheimnis im Text eines Gesprächs ist keines mehr, und Claude Code braucht zum Prüfen der Datei nur den Pfad dorthin.

Tokens in einer Desktop-App aufbewahren

Was du aus dieser Lektion mitnimmst

Ein Projekt in der Google Cloud Console ist die Klammer um mehrere Dienste, nicht die Verbindung zu einem einzigen. Gib ihm einen allgemeinen Namen und schalte weitere APIs darin frei, sobald du sie brauchst.

Freigeschaltete API und Bereich sind zwei verschiedene Erlaubnisse. Die eine legt fest, auf welchen Dienst das Projekt überhaupt zugreifen darf, die andere, was einem bestimmten Token erlaubt ist.

Ein Token wird mit den Bereichen ausgestellt, die im Moment der Autorisierung gelten. Änderst du die Bereiche in der Konsole, wirkt das erst nach einer erneuten Autorisierung.

Der Veröffentlichungsstatus entscheidet, wie lange ein Token gültig bleibt. Im Status Testen laufen Zustimmung und Aktualisierungs-Token nach sieben Tagen ab, in Produktion nicht – deshalb beginnt eine Integration, die dauerhaft arbeiten soll, mit einem Klick auf App veröffentlichen.

Das Client-Geheimnis siehst du ein einziges Mal. Du lädst es beim Erstellen des Clients herunter, bewahrst es im Verzeichnis für Zugangsschlüssel auf und zeigst es niemandem – auch nicht der KI, der du bloss den Pfad zur Datei gibst.

Aufgaben

Hak ab, was du erledigt hast. Den Stand merkt sich dein Browser, du kannst also morgen zu dieser Liste zurückkehren.

  • Projekt in der Google Cloud Console angelegt und allgemein benannt, nicht nach einem einzelnen Dienst
  • API des Dienstes, mit dem du dich verbindest, in der API-Bibliothek (API Library) freigeschaltet – Link
  • Anwendung veröffentlicht – Status In Produktion auf der Seite Zielgruppe (Audience) – Link
  • Bereiche gmail.modify und gmail.settings.basic auf der Seite Datenzugriff (Data Access) hinzugefügt – Link
  • Datei mit den Client-Daten heruntergeladen und im Verzeichnis für Zugangsschlüssel gespeichert
  • Erste Autorisierung durchgeführt, Token auf der Festplatte gespeichert
  • Eine echte Anfrage mit dem Token ausgeführt und anhand des Ergebnisses bestätigt, dass die Integration funktioniert