Die Kunst, Tools für KI-Agenten zu bauen: Wie MCP die Softwareentwicklung umkrempelt

Seit zwei Jahren ist die KI-Branche von den Fähigkeiten ihrer Modelle besessen: größere Kontextfenster, besseres Schlussfolgern, multimodales Verständnis. Doch langsam zeigt sich eine unbequeme Wahrheit: Selbst die ausgereiftesten Modelle bleiben ausgebremst, weil sie von echten Daten und Tools abgeschnitten sind. Der Engpass ist nicht die Intelligenz, sondern die Integration.

Hier kommt das Model Context Protocol (MCP) ins Spiel, Anthropics Antwort auf das, was man dort das „USB-C für KI“ nennt: ein universeller Standard, der Sprachmodelle mit den Tools und Daten verbindet, die sie brauchen, um Aufgaben tatsächlich zu erledigen. Anders als beim vergleichsweise simplen Hardware-Handshake von USB-C müssen wir allerdings grundlegende Annahmen darüber überdenken, wie wir Software schreiben, wenn KI Tools wirksam einsetzen soll.

Die Herausforderung reicht tiefer als reines API-Design. Wir programmieren nicht mehr für deterministische Systeme, die Anweisungen vorhersagbar ausführen. Wir bauen für probabilistische Denker, die Probleme kreativ angehen, Anweisungen missverstehen oder neue Lösungswege finden können, mit denen wir nie gerechnet hätten. Das hat weniger mit dem Programmieren eines Computers zu tun als mit dem Entwurf eines kognitiven Gerüsts für einen brillanten, aber gelegentlich verwirrten Kollegen, der in Wahrscheinlichkeitsverteilungen denkt.

Die Entwicklung von Function Calling zu MCP

Vor MCP gab es Function Calling: OpenAIs Plugins, Anthropics Tool Use, diverse Framework-spezifische Ansätze. Das funktionierte, litt aber an grundlegenden Problemen: Kontextdrift bei der Verwaltung vieler Tools, uneinheitliche Fehlerbehandlung je nach Implementierung und das gefürchtete „M×N-Integrationsproblem“, bei dem jede Kombination aus Modell und Tool eigenen Code brauchte.

MCP, das Anthropic im November 2024 als Open Source veröffentlicht hat, ist mehr als eine weitere Integrationsmethode. Es ist eine vollständige Protokollspezifikation mit Transportschichten, Authentifizierungsmodellen und standardisierten Nachrichtenformaten. Neben Tool-Aufrufen unterstützt das Protokoll auch den Zugriff auf Ressourcen und Prompt-Vorlagen. Anthropics eigene API enthält inzwischen einen MCP-Connector, der MCP-Server direkt aufruft, ohne dass man einen Client schreiben muss: ein deutliches Bekenntnis zum Standard.

Das Ökosystem steckt noch in den Anfängen, wächst aber. Das offizielle MCP-Repository enthält Server für Google Drive, Slack, GitHub und PostgreSQL. Ein Benchmark namens MCP-Bench misst inzwischen die Leistung von Agenten bei standardisierten MCP-Aufgaben und liefert damit eine empirische Grundlage für Entscheidungen im Tool-Design. Early Adopters wie Block und Apollo experimentieren mit MCP im Produktivbetrieb, doch in der Breite der Unternehmen bleibt die Einführung verhalten, weil Organisationen erst die Sicherheitsfolgen abwägen.

Warum Ihre REST-API ein miserables KI-Tool abgibt

Klassische APIs sind Verträge zwischen deterministischen Systemen. Rufen Sie getUser(123) auf, und Sie bekommen die Daten von User 123, jedes Mal im exakt gleichen Format. Tools für KI-Agenten sind dagegen Verträge zwischen deterministischen Systemen und nicht deterministischen Denkern, die dasselbe Problem bei jedem Durchlauf anders angehen können.

Anthropics kürzlich erschienene ausführliche Analyse zum Tool-Design fördert eine kontraintuitive Erkenntnis zutage: Die Tools, die für Agenten am besten funktionieren, verletzen oft Prinzipien, die uns im klassischen API-Design heilig sind. Nehmen wir das Adressbuch-Beispiel: Eine REST-API bietet vielleicht einen list_contacts-Endpunkt an, der alle Einträge zurückgibt und das Filtern dem aufrufenden Programm überlässt. Nutzt aber ein LLM-Agent so ein Tool, muss er jeden Kontakt Token für Token verarbeiten und verbrennt dabei wertvollen Kontext für irrelevante Daten. Das ist, als müsste jemand ein ganzes Telefonbuch lesen, um eine einzige Nummer zu finden.

Zusätzliche Suchparameter allein lösen das nicht. Wirksame Agenten-Tools fassen ganze Workflows zusammen. Statt list_users, list_events und create_event als getrennte Endpunkte anzubieten, empfiehlt Anthropic ein einziges schedule_event-Tool, das die Verfügbarkeitsprüfung und die Terminplanung atomar erledigt. Das entspricht der Art, wie Menschen Aufgaben tatsächlich erledigen: Wir denken nicht in CRUD-Operationen.

Diese Designphilosophie geht über das bloße Zusammenfassen hinaus. Tools sollten semantisch aussagekräftige Bezeichner zurückgeben statt UUIDs. Sie sollten Fehlermeldungen liefern, mit denen sich etwas anfangen lässt, statt Stack Traces. Und sie sollten Antwortformate zur Auswahl anbieten, damit Agenten je nach Bedarf knappe Zusammenfassungen oder detaillierte Daten anfordern können. Jede Designentscheidung beeinflusst, ob Agenten über das Tool sinnvoll nachdenken und es wirksam nutzen können.

Die rekursive Verbesserungsschleife

Am verblüffendsten an Anthropics Methodik ist vielleicht der Ansatz zur Tool-Optimierung: KI-Agenten helfen dabei, genau die Tools zu verbessern, die sie selbst benutzen. Das ist mehr als ein cleverer Einfall, denn es bringt messbar bessere Ergebnisse als von Menschen entworfene Tools.

Die Evaluierungs-Pipeline läuft in Etappen. Zuerst erzeugt man realistische Testszenarien, die auf echten Anwendungsfällen beruhen. Statt „Vereinbare ein Meeting“ heißt es dann etwa: „Vereinbare für nächste Woche ein Meeting mit Jane, um unser neuestes Projekt für Acme Corp zu besprechen. Hänge die Notizen von unserem letzten Projektplanungsmeeting an und reserviere einen Konferenzraum.“ Solche komplexen, mehrstufigen Aufgaben setzen Tool-Kombinationen und die Fehlerbehandlung einem Stresstest aus.

Danach laufen diese Szenarien durch Evaluierungsagenten, die die Aufgaben zu lösen versuchen und dabei ihre Überlegungen strukturiert ausgeben. Anthropic empfiehlt, die Agenten anzuweisen, neben den Antworten auch Reasoning-Blöcke zu erzeugen, die ihre Tool-Wahl erklären. So entstehen ausführliche Transkripte der Interaktionen zwischen Agent und Tool, samt Erfolgen, Fehlschlägen und Stellen, an denen Verwirrung entsteht.

Jetzt wird es meta: Diese Transkripte gehen zur Analyse an eine weitere KI-Instanz. Der analysierende Agent sucht nach Mustern: Tools, die wegen schlechter Paginierung immer wieder aufgerufen werden, Parameter, die regelmäßig missverstanden werden, Workflows, die sich zusammenfassen ließen. Dann schlägt er konkrete Verbesserungen vor: Parameter klarer benennen, Antwortformate anpassen, häufig gemeinsam auftretende Operationen zusammenlegen.

Die Ergebnisse überzeugen. In Anthropics Evaluierungen schnitten von Claude optimierte Tools sowohl beim Slack- als auch beim Asana-MCP-Server besser ab als die ursprünglichen, von Menschen geschriebenen Versionen. Das waren keine geringfügigen Verbesserungen: Die Abschlussquoten der Aufgaben stiegen deutlich, und der Token-Verbrauch sank ebenso deutlich.

Die verborgenen Herausforderungen: Discovery, Koordination und Weiterentwicklung

Die Sicherheitsbedenken rund um MCP sind real (Untersuchungen haben Tausende offen erreichbare MCP-Server ohne Authentifizierung gefunden), aber sie sind nicht die einzige Herausforderung. Hartnäckigere Probleme plagen Agentensysteme im Produktivbetrieb:

Tool Discovery im großen Maßstab: Wenn Hunderte von Tools zur Verfügung stehen, wie wählt ein Agent aus? Neuere Arbeiten wie ScaleMCP erforschen das dynamische Abrufen von Tools, doch gelöst ist das Problem nicht. Namespacing hilft (Tools werden unter Präfixen wie slack_ oder github_ gruppiert), aber Agenten tun sich weiterhin schwer mit der Auswahl, wenn theoretisch mehrere Optionen passen würden.

Koordination über mehrere Schritte: MCP-Bench testet gezielt Szenarien, die mehrere voneinander abhängige Tool-Aufrufe erfordern. Agenten müssen den Zustand über die Aufrufe hinweg mitführen, mit Teilausfällen umgehen und manchmal zurückgehen, wenn ein Ansatz scheitert. Das Protokoll unterstützt das, aber das Tool-Design beeinflusst die Erfolgsquote erheblich. Tools, die den Sitzungszustand halten oder eine transaktionsähnliche Semantik bieten, schneiden in komplexen Workflows besser ab.

Token-Ökonomie: Jedes Token, das eine Tool-Antwort verbraucht, fehlt beim Schlussfolgern. Anthropics Lösung, Parameter für das Antwortformat mit den Modi „concise“ und „detailed“, kann den Token-Verbrauch um 65 % oder mehr senken. Dafür müssen Tools aber intelligent entscheiden, welche Informationen wesentlich sind und welche nur ergänzend, und das ist eine nicht triviale Designaufgabe.

Schema-Evolution: Die vielleicht am wenigsten diskutierte, aber kritischste Herausforderung: Wie entwickeln Sie Tool-Schemas weiter, ohne Agenten aus dem Tritt zu bringen, die gelernt haben, damit umzugehen? Anders als bei klassischen APIs, bei denen Sie alle Clients kontrollieren, können Sie das Verständnis jedes Agenten von Ihrem Tool nicht per Zwangsupdate aktualisieren. Die MCP-Spezifikation sagt auffallend wenig zu Versionierungsstrategien, das Problem bleibt also weitgehend ungelöst.

Der philosophische Wandel im Softwaredesign

Über die technischen Herausforderungen hinaus stehen MCP und Agenten-Tools für einen grundlegenden Wandel in unserem Denken über Software-Schnittstellen. Statt Computern Anweisungen zu geben, befähigen wir zunehmend künstliche Kollegen. Das verlangt ein anderes mentales Modell.

Klassisches API-Design optimiert auf Konsistenz, Vorhersagbarkeit und Komponierbarkeit. Das Design von Agenten-Tools optimiert auf kognitive Ergonomie: wie selbstverständlich eine Intelligenz (künstlich oder nicht) eine Fähigkeit verstehen und nutzen kann. Das erklärt, warum zusammengefasste, an Workflows orientierte Tools granulare CRUD-Operationen übertreffen, obwohl sie die Trennung der Zuständigkeiten verletzen.

Die Fehlerbehandlung zeigt diesen Wandel besonders gut. Eine klassische API gibt vielleicht {"error": "INSUFFICIENT_PERMISSIONS", "code": 403} zurück. Ein für Agenten optimiertes Tool antwortet: „Zugriff verweigert. Zum Ändern dieses Dokuments brauchen Sie ‘write’-Zugriff. Fordern Sie den Zugriff beim Eigentümer des Dokuments an oder versuchen Sie es stattdessen mit ‘suggest_edit’.“ Die zweite Variante liefert Information und zugleich Orientierung: Mentoring, verpackt in Fehlermeldungen.

Diese vermenschlichende Designphilosophie zieht sich durch alle erfolgreichen Tools. Parameternamen verwenden natürliche Sprache statt Abkürzungen. Antwortstrukturen folgen der Art, wie Menschen die Information beschreiben würden. Sogar die Wahl zwischen JSON und XML kann die Leistung von Agenten beeinflussen, weil Modelle mit Formaten besser zurechtkommen, die in ihren Trainingsdaten häufig vorkommen.

Was das für Entwickler heute bedeutet

Für Softwareentwickler ist MCP Chance und Herausforderung zugleich. Die Chance liegt auf der Hand: einmal bauen, überall nutzbar machen. Ein MCP-Server für Ihren Dienst ließe sich potenziell von jedem KI-Agenten verwenden, was starke Netzwerkeffekte erzeugt.

Die Herausforderung geht allerdings tief. Wir programmieren nicht mehr nur, wir entwerfen kognitive Affordanzen. Jeder Parametername, jede Beschreibung und jedes Antwortformat beeinflusst, wie gut Agenten über unsere Tools nachdenken und sie nutzen können. Das verlangt, weniger wie ein Systemprogrammierer zu denken und mehr wie ein UX-Designer, dessen Nutzer zufällig Wahrscheinlichkeitsverteilungen sind.

Praktische Schritte für Entwickler, die in dieses Feld einsteigen:

1. Beginnen Sie mit Prototypen: Bauen Sie einfache MCP-Server für Ihre bestehenden Dienste. Testen Sie sie lokal mit Claude oder anderen Agenten, um Schwachstellen zu finden.
2. Investieren Sie in Evaluierung: Testen Sie nicht nur die Happy Paths. Erzeugen Sie komplexe, realistische Szenarien, die mehrere Operationen verketten. Setzen Sie Evaluierungsagenten ein, um Stellen sichtbar zu machen, an denen Verwirrung entsteht.
3. Setzen Sie auf Konsolidierung: Widerstehen Sie dem Drang, jede interne Operation nach außen zu geben. Richten Sie Tools an vollständigen Workflows und den Absichten der Nutzer aus.
4. Iterieren Sie mit KI-Unterstützung: Nutzen Sie die rekursive Verbesserungsschleife. Lassen Sie Agenten ihre eigenen Fehlschläge analysieren und Verbesserungen vorschlagen. Die Ergebnisse überraschen oft selbst erfahrene Entwickler.
5. Planen Sie die Weiterentwicklung ein: Überlegen Sie, wie sich Ihre Tools mit der Zeit verändern werden. Bauen Sie von Anfang an Deprecation-Hinweise, Versionsaushandlung und Graceful Degradation ein.

Der Weg nach vorn: Mehr als Integration

MCP ist erst der Anfang. Das Protokoll unterstützt bereits fortgeschrittene Funktionen wie Sampling (Server fordern LLM-Completions von Clients an) und Elicitation (Server fragen während laufender Operationen zusätzliche Informationen ab). Diese Fähigkeiten deuten auf eine Zukunft hin, in der die Grenze zwischen Tool und Agent immer fließender wird.

Wir erleben gerade, wie eine neue Schicht im Software-Stack entsteht, in der KI-Agenten APIs nicht bloß konsumieren, sondern aktiv an verteilten Systemen teilnehmen. Aus Tools werden Fähigkeiten, Fähigkeiten ermöglichen Strategien, und Strategien erreichen Ziele, die wir womöglich nie explizit programmiert hätten.

Die Folgen gehen über die Architektur hinaus. Je besser Agenten mit Tools umgehen, desto mehr brauchen wir neue Frameworks für Governance, Audit Trails und die Durchsetzung von Richtlinien. Die Frage ist nicht, ob KI-Agenten fester Bestandteil von Softwaresystemen werden, denn das passiert bereits. Die Frage ist, wie wir Tools bauen, die ihre Fähigkeiten verstärken und dabei menschliche Aufsicht und menschliche Werte wahren.

Die eigentliche Erkenntnis aus Anthropics Forschung betrifft mehr als besseres Tool-Design. Wir haben über den falschen Engpass nachgedacht. Wir hielten die Intelligenz der Modelle für den begrenzenden Faktor. Tatsächlich ist es die kognitive Ergonomie der Tools, die wir bereitstellen. Bringen Sie die in Ordnung, und plötzlich können Agenten Dinge, die wir nicht für möglich gehalten hätten.

Der USB-C-Moment der KI ist da. Anders als dieser simple Hardware-Standard verlangt MCP aber von uns, neu zu denken, wie wir Systeme verbinden und wie wir für Intelligenz selbst gestalten. Die Tools, die wir heute bauen, bestimmen, was Agenten morgen leisten können. Bleibt die Frage: Sind wir bereit, für Köpfe zu gestalten, die in Wahrscheinlichkeiten statt in Prozeduren denken?

Aus dem Englischen übersetzt: zum Originalbeitrag