Guillaume Duvernay

Ich nutze MCP für den Großteil meiner Arbeit nicht mehr

13 Min. Lesezeit

AI efficiencyagentsMCP

Seit einigen Monaten meide ich MCP, wann immer ich die Wahl habe, und nutze stattdessen etwas anderes. Ich habe kein Problem mit dem Protokoll selbst. Mein Problem ist das, was es mich bei meiner täglichen Arbeit kostet, die aus vielen repetitiven Vorgängen in einem CRM, einem CMS und einigen Analytics-Tools besteht.

Dies ist die schriftliche Fassung eines Videos, das ich veröffentlicht habe, mit denselben Beispielen.

Video: MCPs im großen Stil? Hört auf, all eure Token zu verschwenden!Play

Das Setup blieb nie über verschiedene Umgebungen hinweg stabil

Ich wechsle zwischen Claude Code, Codex und Antigravity, je nachdem, was ich gerade tue. Jedes dieser Tools verbindet MCP-Server auf seine eigene Weise. Manchmal ist es eine JSON-Konfigurationsdatei. Manchmal muss man ein offizielles Plugin finden, und wenn es keines gibt, fügt man einen benutzerdefinierten Server manuell hinzu.

Jedes Mal, wenn ich eine Session in einer anderen Umgebung öffnete, war ich mir unsicher, ob alles verbunden war. Einige Server waren offline und mussten neu authentifiziert werden. Ich fing an zu arbeiten und stellte es erst auf halber Strecke fest.

In einem Team-Plan wird es noch schlimmer. In Claude Code kann nur der Admin benutzerdefinierte Connectoren hinzufügen, bevor sie für alle verfügbar sind. Ein Teammitglied, das einen benötigt, muss also warten.

Das ist eine Reibung, mit der ich leben kann. Der Teil, der mich wirklich Zeit und Ressourcen kostet, liegt tiefer.

Tool-Beschreibungen kosten Token, bevor man überhaupt etwas fragt

Wenn ein MCP-Server verbunden ist, stellt er seine Tools dem Client zur Verfügung. Für ein CRM sind das Dinge wie Kontakte auflisten, Kontakt abrufen, Kontakt erstellen oder Kontakt bearbeiten. Jedes Tool enthält eine Beschreibung, wann es zu verwenden ist, sowie das Format des erwarteten Payloads.

All das landet in der Session. Verbindet man zehn Server mit jeweils zwanzig Tools, schleppt man zweihundert Tool-Beschreibungen und deren Schemas in jedes Gespräch mit, selbst in jene, in denen man nur zwei davon nutzt.

Zehn Server mit jeweils zwanzig Tools sind ein illustrativer Wert, keine Messung eines spezifischen Setups. Gezeigt wird das Prinzip: ein festes Budget, dessen Großteil bereits vor Beginn der Konversation aufgebraucht ist.
Jedes dieser Elemente wird geladen, unabhängig davon, ob die Session darauf zugreift. Die markierten zwei sind diejenigen, die eine typische Session aufruft.

Die Clients werden hier besser. Claude Code kann Tools progressiv einblenden, anstatt jede Beschreibung sofort zu laden, und es gibt andere Ansätze, bei denen der Agent nach dem benötigten Tool sucht. Ich erwarte daher, dass dieses Problem weitgehend von selbst verschwindet, weshalb es nicht meine Hauptkritik ist.

Der Agent tippt das bereits Vorhandene neu

Nehmen wir an, Sie bitten Ihren Agenten, zweihundert Kontakte aus einer CSV in Ihr CRM zu übertragen. Die Datei liegt direkt auf Ihrem Laptop, korrekt formatiert.

Der Agent muss dennoch jeden Tool-Aufruf selbst schreiben, Zeichen für Zeichen: den Tool-Namen, dann den Payload mit Name, E-Mail und weiteren Details des Kontakts. Zweihundertmal. Meistens nicht parallel.

Die Kosten sind hier als Proportionen und nicht als exakte Messungen zu verstehen. Die mittlere Zeile skaliert mit der Dateigröße, die anderen nicht.

Ich wünschte, der Agent würde die CSV betrachten, herausfinden, wie die Header den CRM-Feldern zugeordnet sind, und die Daten verschieben, ohne sie erst in sich selbst zu laden. Das ist eine Transformation. Die meisten Clients können das nicht und schreiben die Daten stattdessen neu.

Zudem ist es unzuverlässig. Ab ein paar hundert Datensätzen wird ein Agent oft nachlässig und bearbeitet nur die Hälfte oder macht in der Mitte einen kleinen Fehler, den man erst später bemerkt.

Sieben Minuten, um eine Zahl zu ändern

Das war der Punkt, an dem ich aufhörte, MCP für meine repetitiven Aufgaben zu nutzen.

Ich verwalte eine Website in Webflow. Articles befinden sich in einer CMS-Collection, eine Zeile pro Artikel, und der Inhalt ist Rich Text, den Webflow als Inline-HTML speichert. Ein typischer Artikel umfasst zweitausend Wörter.

Ich bat den Agenten, einen Artikel zu finden und darin eine Zahl zu ändern: 70 zu 80.

Das Finden ging blitzschnell. Dann bietet das Webflow-MCP ein Tool dafür: ein CMS-Item bearbeiten, wobei man die zu ändernden Felder zusammen mit den neuen Werten übergibt. Es gibt kein Suchen-und-Ersetzen innerhalb eines Feldes. Um also zwei Zeichen zu ändern, las der Agent den gesamten Text aus, tippte alle zweitausend Wörter mit der neuen Zahl in der Mitte erneut und sendete das Ganze ab.

Die sieben Minuten und die 20 % sind Werte aus meiner eigenen Session an diesem Tag für einen einzigen Artikel.

Eine Lösung wären intelligentere Tools: ein Suchen-und-Ersetzen-Endpunkt für ein CMS-Feld. Das würde helfen, ist aber etwas, das ich auf dem Server eines anderen nicht erzwingen kann.

Die andere Lösung benötigt keine Erlaubnis. Den Artikel einmal abrufen, in eine lokale Datei schreiben, dort mit den Tools bearbeiten, die die Umgebung bereits gut beherrscht, und ihn wieder hochladen.

Die mittlere Spalte macht den gesamten Unterschied. Das Bearbeiten einer Datei ist die größte Stärke dieser Umgebungen, und diese Bearbeitung erfolgt nicht über das Modell.

Rückgabewerte lassen sich nicht einschränken

Ein MCP-Aufruf gibt immer etwas zurück, und was auch immer zurückkommt, wird Teil Ihres Kontextfensters.

Fragen Sie nach Ihren zwanzig aktuellsten Artikeln, weil Sie deren Veröffentlichungsdaten benötigen. Sofern der Server zufällig einen Parameter für Felder anbietet, erhalten Sie zwanzig vollständige Artikel. Inklusive Inhalten. Zweitausend Wörter pro Stück, plus jedes andere Feld in der Collection.

Wenn der Server keinen entsprechenden Parameter anbietet, landet der Payload vollständig im Fenster und bleibt dort für den Rest der Session.

Die API war bereits vorhanden

Viele MCP-Server sind lediglich Wrapper um eine API, die das Unternehmen bereits hatte.

Webflow, HubSpot und andere haben dokumentierte REST-APIs, die seit Jahren öffentlich sind. Darauf basieren die Connectoren von Zapier, Make, n8n und Softr. Als diese Unternehmen einen MCP-Server veröffentlichten, haben die meisten einfach ihre bestehenden Endpunkte in das Protokoll abgebildet. Es ist also nur ein zweites Interface für dieselben Operationen.

Solange eine Plattform MCP und API parallel hält, ändert das gewählte Interface nichts an den verfügbaren Funktionen.

Und Ihr Agent kann eine API perfekt ansprechen. In einer Codex- oder Claude Code-Session schreibt er die Anfrage und führt sie von Ihrem Rechner aus. Der Unterschied ist, dass ein API-Aufruf in einem Skript stehen kann.

Genau dieser Unterschied löst das Problem des Neu-Tippens. Der Agent betrachtet Ihre CSV, erarbeitet einmalig das Mapping, schreibt ein Skript, das die Zeilen durchläuft und für jede einen Aufruf tätigt, und führt dieses dann aus. Ab diesem Moment ist kein Modell mehr im Loop. Das Skript läuft, bis es fertig ist.

Schreiben Sie eine Fertigkeit (Skill), nicht eine Tool-Liste

Eine API ist nicht selbsterklärend, und genau das ist es, was MCP eigentlich bietet. Sagt man einem Agenten „nutze die HubSpot-API“, wird er raten, basierend auf dem, was er sich erinnert. Meistens nah dran, aber nicht exakt.

Aber APIs sind dokumentiert, meist mit einer OpenAPI-Spec, auf die man verweisen kann oder die der Agent selbst findet. Und für alles, was man mehr als einmal tut, schreibt man es auf.

# Skill: CSV zu CRM-Kontakten

Wir nutzen niemals das CRM-MCP. Alles läuft über die REST-API.

## Verwendete Endpunkte
- `POST /crm/v3/objects/contacts` für einzelne Kontakte
- `POST /crm/v3/objects/contacts/batch/create` für bis zu 100 pro Aufruf
- Vollständige Referenz: https://developers.hubspot.com/docs/api/crm/contacts

## Authentifizierung
Der Key befindet sich in der `.env` im Repo-Root als `CRM_KEY`. Lesen Sie ihn mit
`source .env` innerhalb des Skripts. Niemals ausgeben, niemals in eine
Nachricht kopieren.

## Mapping
Prüfen Sie zuerst die CSV-Header und ordnen Sie diese den CRM-Feldern zu. Fragen Sie nach,
bevor Sie bei nicht offensichtlichen Übereinstimmungen raten.

Sobald diese Datei existiert, weiß der Agent, wie Sie mit Ihrem CRM kommunizieren, welche Endpunkte Sie nutzen und wie man sich authentifiziert. Er hört auf zu raten, und Sie erhalten die gleiche Zuverlässigkeit, die MCP Ihnen bot.

CLIs funktionieren genauso und sind oft sogar besser. Agenten beherrschen Terminal-Befehle gut, die meisten CLIs dokumentieren sich über Help-Outputs und viele übernehmen OAuth für Sie: Sie loggen sich einmal im Browser ein und der Token bleibt auf Ihrem Rechner. Unter der Haube ist es meistens wieder dieselbe API.

Der Key bleibt in der Datei

Hier ist die Nutzung von APIs tatsächlich aufwendiger als bei MCP. Die meisten MCP-Server nutzen mittlerweile OAuth, man klickt sich durch eine Login-Seite und ist fertig. Bei einer API hält man meist einen Key in der Hand.

Ich führe eine .env-Datei im Root des Ordners, in dem der Agent arbeitet, und sage dem Agenten, dass der Key dort liegt und wie er zu verwenden ist: über einen Befehl, der ihn in das Skript einliest, niemals durch Ausgeben in der Konversation. Der Agent weiß, dass der Key existiert und wo er liegt. Er sieht den Wert niemals.

Verkettung wie im Terminal

Sobald Aufrufe in Skripten leben, können Sie diese hintereinander schalten, und das Modell sieht nur noch das Endergebnis.

Nehmen wir etwas, das ich regelmäßig mache: Finden Sie die drei Artikel, die ich am längsten nicht mehr angefasst habe, rufen Sie deren Performance ab und entscheiden Sie, was neu geschrieben werden muss.

Über MCP wäre jede Zwischenantwort im Kontextfenster gelandet. Hier erreichen die ersten drei Schritte das Modell überhaupt nicht.

Der Agent erhält einen kurzen, strukturierten Bericht und tut das, was er wirklich gut kann: ihn zu lesen und mir zu sagen, was zu korrigieren ist. Er hat die zwanzig Artikel, durch die er sortiert hat, nie gesehen.

Niemand braucht API-Keys auf seinem Laptop

Der offensichtliche Einwand: Wir sind zehn Leute in einem Marketing-Team, müssen jetzt alle API-Keys auf ihrem Rechner speichern?

Nein. Was wir bei Softr gebaut haben, ist ein Proxy. Jede Person hat einen eigenen Key. Sie rufen den Proxy damit auf, der Proxy weiß, wer sie sind, und leitet die Anfrage an den richtigen Dienst unter Verwendung des Keys weiter, den er für diesen Dienst hält.

Die Berechtigungsebene ist der Teil, den wir zuvor nicht bauen konnten. Ein roher Key besitzt dieselben Scopes für jeden, der ihn hält.

Berechtigungen sind der Punkt, der mir am wichtigsten ist. Ein API-Key ist bei der Erstellung fest definiert, und danach kann jeder, der ihn besitzt, dieselben Dinge tun. Über den Proxy setzen wir Operationen auf eine Whitelist. So kann unser Webflow-Key für den Großteil des Teams read-only sein, während ein Content-Manager erstellen und bearbeiten darf. Niemand kann versehentlich einen Artikel löschen, und es musste niemand etwas installieren.

Wann MCP trotzdem das richtige Tool ist

Ich argumentiere nicht gegen MCP. Für einmalige Aufgaben ist es das schnellste Mittel, und ich nutze es immer noch.

Hier wird nicht behauptet, man müsse sich für eines entscheiden. Die Kosten von MCP fallen bei Volumen und Wiederholung ins Gewicht, daher lohnt es sich dort, es zu ersetzen.

Der richtige Zeitpunkt, dies in Betracht zu ziehen, ist, wenn ein wesentlicher Teil Ihrer Arbeit über einen Agenten läuft, der mit Ihren Tools kommuniziert. Vorher ist das Einrichten der größte Teil der Arbeit, und da gewinnt MCP.

Danach lohnt sich ein Nachmittag Zeit. Fragen Sie Ihren Agenten, welche Endpunkte Ihre Tools anbieten, lassen Sie sich den Skill gemeinsam schreiben und führen Sie eine Ihrer wiederkehrenden Aufgaben auf beiden Wegen aus. Der Unterschied wird bei jedem Volumen sofort deutlich.

Quellen