Im vorigen Kapitel haben wir einen minimalen Agenten zum Laufen gebracht, der dem Kopf (LLM) ein Werkzeug anbindet und die Schleife selbst dreht. An diesem Erfolgserlebnis dürften Sie erkannt haben: Die tatsächliche Leistung eines Agenten entscheidet sich fast vollständig daran, „an welche Werkzeuge er angebunden ist“. In diesem Kapitel lernen wir, wie man aus dem Verschleiß herauskommt, diese Werkzeuge jedes Mal selbst zu bauen, und stattdessen mit dem gemeinsamen Standard MCP (Model Context Protocol) standardisiert an externe Werkzeuge und Daten anbindet. MCP entstand bei Claude und ist längst auf dem Weg, der branchenweite Standard für Anbindungen zu werden.
Das Ziel: „Werkzeuge nicht selbst bauen, sondern mit einem Standard sicher anbinden“
Warum die Werkzeuganbindung das Herz des Agenten ist
Das LLM selbst kann, so klug es auch sein mag, nur „Wörter hervorbringen“. Den aktuellen Lagerbestand zu kennen oder eine Zeile in eine Datei zu schreiben, ist ohne ein Mittel, die Außenwelt zu berühren, unmöglich. Dass ein Agent die Schleife „recherchieren, ausführen, prüfen“ drehen kann, liegt allein daran, dass er Werkzeuge besitzt, die nach außen wirken.
Mit anderen Worten: Die Obergrenze der Fähigkeiten eines Agenten wird durch Qualität und Zahl der angebundenen Werkzeuge bestimmt. Beim selben LLM unterscheidet sich das Machbare grundlegend zwischen einem Agenten, der nur einen Taschenrechner hat, und einem, der an Datenbank, Suche, Dateien und interne APIs angebunden ist. Nicht selten wächst die gefühlte Leistung stärker, wenn man gute Werkzeuge treffend anbindet, als wenn man den Kopf gegen ein besseres tauscht.
💡 „Gut ausgestattet“ schlägt „schlau“. Auch ein fähiger Mensch kann mit leerem Werkzeugkasten nichts ausrichten. Ein Großteil der Zeit in der Agentenentwicklung fließt tatsächlich in den Entwurf: „Welches Werkzeug übergebe ich wie sicher?“ Das ist der Kern dieses Kapitels.
Die Grenzen roher Werkzeugdefinitionen
Im vorigen Kapitel haben wir Werkzeuge mit eigener Hand definiert. Eine Funktion schreiben, Name, Argumente und Beschreibung ans LLM übergeben und bei einem Aufruf ausführen und das Ergebnis zurückgeben – dieser Ablauf selbst ist richtig und bis heute die Grundlage. Das Problem ist, dies jedes Mal, pro Werkzeug, pro Projekt neu zu bauen.
Denken wir etwa an ein „Werkzeug, das eine Datenbank durchsucht“. Die Verbindung schreiben, die Abfrage zusammensetzen, das Ergebnis formatieren, Fehler behandeln, Zugangsdaten sicher handhaben … Dieses ganze Paket implementiert jeder für sich – in Ihrem Projekt, im Nachbarteam, in einer anderen Sprache. Dass Entwickler auf der ganzen Welt dasselbe Werkzeug immer wieder als Neuerfindung des Rades bauen, ist die Realität roher Werkzeugdefinitionen.
Ein für ein Projekt geschriebenes Werkzeug ist an dieses Framework, diese Sprache gebunden und lässt sich schwer woanders hin mitnehmen.
Bindet man M Arten von Werkzeugen an N Agenten-Plattformen an, braucht es rechnerisch N×M Anbindungs-Codestücke.
Ändert sich die Spezifikation eines Anschlussziels, muss man die überall verstreuten Eigenbau-Werkzeuge einzeln nachziehen.
Das ähnelt stark der Zeit, als jedes Peripheriegerät ein eigenes Spezialkabel brauchte. Für den Drucker ein Drucker-Anschluss, für die Maus ein Maus-Anschluss – je mehr Geräte, desto mehr explodieren die Verbindungsarten. Gäbe es einen „gemeinsamen Anschluss“, verschwände dieser Aufwand auf einen Schlag. Hier tritt MCP auf den Plan.
Was MCP ist – der gemeinsame Standard der Werkzeuganbindung
MCP (Model Context Protocol) ist ein offener Standard, um KI und externe Werkzeuge und Daten auf standardisierte Weise anzubinden. Anthropic veröffentlichte ihn Ende 2024 für Claude, danach zogen diverse KI-Werkzeuge und -Dienste nach. Stand 2026 ist er über Anbietergrenzen hinweg breit adoptiert und wächst unter einer neutralen Trägerschaft zu einem Branchenstandard heran. Wichtig ist, dass es kein Produkt eines einzelnen Unternehmens ist, sondern eine gemeinsame Spezifikation, die jeder implementieren kann.
Die Idee von MCP in einem Satz: „das USB für die Anbindung von KI-Werkzeugen“. So wie mit dem Aufkommen von USB die Peripheriegeräte jedes Herstellers am selben Anschluss nutzbar wurden, gilt für ein MCP-fähiges Werkzeug: Jeder MCP-fähige Agent kann es „einstecken und nutzen“. Weil sich die bauende und die nutzende Seite an dieselbe Vereinbarung halten, faltet sich die Kombinationshölle N×M zu „N+M“ zusammen.
Der von Ihnen gebaute Agent oder Apps wie Claude sind hier. Die Seite, die den Server fragt „Welche Werkzeuge sind gerade angebunden?“ und die benötigten Werkzeuge aufruft.
Die Seite, die Funktionen wie Dateioperationen, DB-Suche und SaaS-Anbindung gebündelt als „Werkzeuge“ veröffentlicht. Ein Server kann mehrere Werkzeuge halten.
Beide sprechen nach einem festen Ablauf miteinander. Verbindet sich der Client, erhält er zunächst vom Server „eine Liste der nutzbaren Werkzeuge“ und „jeweils Beschreibung und Argumente“. Das LLM betrachtet die Liste, wählt das zum Ziel passende Werkzeug, ruft es auf, und der Server führt es aus und gibt das Ergebnis zurück – dass dieser Hin- und Rückweg ohne werkzeugspezifische Einzelimplementierung zustande kommt, ist das Herz von MCP.
Client → Server :„Sag mir, welche Werkzeuge nutzbar sind“ Server → Client:„Die drei search_docs / read_file / query_db, so lauten die Beschreibungen“ LLM entscheidet :„Ich rufe query_db mit dem Argument {sql:"..."} auf“ Client → Server :„Führe query_db aus“ Server → Client:„Das Ergebnis sind diese Zeilendaten“
Für die Veröffentlichung gibt es im Wesentlichen zwei Wege. Der lokale Typ, der auf der eigenen Maschine als Prozess läuft, und der Remote-Typ, der übers Netzwerk angebunden wird. Lokal passt zu eigenen Dateien und Entwicklungs-DBs, Remote zu im Team geteilten SaaS-Anbindungen. In beiden ist die Vereinbarung „die Werkzeugliste bekommen und aufrufen“ dieselbe, und die Handhabung auf Client-Seite ändert sich kaum.
📖 Erst das Gesamtbild. Lesen Sie zuvor den Erklärartikel „Was ist MCP“, der Entstehung, Begriffe und Verbreitungsstand von MCP verständlich ordnet, dann geht dieses Kapitel ganz von selbst ein. Feinheiten der Spezifikation und Versionen entwickeln sich schnell, prüfen Sie also vor der Implementierung stets die aktuelle offizielle Doku.
MCP-Server nutzen und bauen
Das Beste an MCP ist, dass man bereits veröffentlichte Server direkt nutzen kann. Häufig gebrauchte Werkzeuge hat meist schon jemand als MCP-Server bereitgestellt. Bindet man sie an den eigenen Agenten an, wachsen dessen Fähigkeiten schlagartig, ohne das Rad neu zu erfinden.
Lesen und Schreiben in einem angegebenen Ordner. Grundlage, um Dokumente lesen oder Ergebnisse ausschreiben zu lassen.
SQL ausführen oder das Schema einsehen. Auf „aggregiere das“ hin echte Daten abfragen und antworten.
Websuche oder interne Wissenssuche. Wird zur „recherchierenden Hand“, die aktuelle Infos und Belege heranholt.
Aufgabenverwaltung, Chat, Speicher usw. Bestehende Arbeitswerkzeuge werden zu Händen und Füßen des Agenten.
Der Anbindungsablauf selbst ist einfach. Den gewünschten Server starten (oder eine URL angeben) und in den Client-Einstellungen Ort und Zugangsdaten des Servers eintragen – mehr nicht. Danach erhält der Agent beim Verbinden die Werkzeugliste und ruft nach Bedarf auf. Sie müssen das „Innere des DB-Suchwerkzeugs“ nicht schreiben. Ihre Aufgabe wird es, die bereitgestellten Werkzeuge zweckentsprechend zu kombinieren.
⚠️ „Praktisch, also alles anbinden“ ist tabu. Mit jedem zusätzlichen Server wachsen um die Zahl der Werkzeuge die Beschreibungen, die ans LLM gehen, die Entscheidung zerfasert, und der Spielraum für Fehlbedienung wird größer. Grundsatz ist, nur die Werkzeuge anzubinden, die dieser Agent wirklich braucht. Zu viele Werkzeuge senken eher die Genauigkeit.
Eigene Server bauen
Werkzeuge, für die es keinen fertigen Server gibt – interne Eigen-APIs, spezielle Geschäftslogik –, muss man einfach nur selbst als MCP-Server schreiben. Das ist der Charme von MCP: Einmal als Server veröffentlicht, ist es aus jedem passenden Agenten gleichermaßen nutzbar. Ein für ein Projekt gebautes Werkzeug lässt sich im nächsten Projekt und in einem anderen Agenten des Teams ohne Neuschreiben wiederverwenden.
Der Inhalt des Serverbaus lautet: „die gewünschte Funktion als Werkzeug definieren, Name, Argumente und Beschreibung deklarieren und bei einem Aufruf die Verarbeitung ausführen und das Ergebnis zurückgeben“. Die Idee ist dieselbe wie bei der rohen Werkzeugdefinition aus dem vorigen Kapitel, aber es unterscheidet sich entscheidend, dass das Ausgabeziel nicht „ein bestimmter Agent“, sondern „der gemeinsame Anschluss MCP“ ist. Der Bauaufwand ist einmalig, die Wiederverwendung beliebig oft.
🛠 Wenn Sie in die Implementierung einsteigen. Konkreten Code, um mit Claude Agenten oder Werkzeuganbindungen zu bauen, liefert praxisnah Claude Agent SDK – Einstieg. Das SDK bringt einen Mechanismus zum Umgang mit MCP-Servern mit, sodass sich sowohl die Anbindung fertiger Server als auch der Eigenbau entlang der offiziellen Doku vorantreiben lässt.
Welche Werkzeuge man wie übergibt
Kann man Werkzeuge „anbinden“, lautet die nächste Frage: „Was übergibt man wie?“ Das ist der Entwurfskniff, der über Qualität und Sicherheit des Agenten entscheidet, und auch die Grundlage der folgenden Kapitel. Merken wir uns drei Prinzipien.
Nur die für diese Aufgabe nötigen Werkzeuge und Bereiche übergeben. „Genügt Lesen, keine Schreibrechte übergeben.“ Bei einer DB ein eingeschränktes Lese-Konto, bei Dateien nur der Zielordner – das ist die Grundlinie.
Das LLM entscheidet allein anhand der Beschreibung, ob es ein Werkzeug nutzt. „Was tut das Werkzeug, wann nutzt man es, was bedeuten die Argumente, in welchen Fällen darf man es nicht nutzen“ konkret schreiben. Vage Beschreibungen erzeugen Fehlgebrauch.
Schreiben, Löschen, Abrechnen, Befehlsausführung und andere unumkehrbare Operationen nicht mit den lesenden gleichsetzen. Prüfung vor der Ausführung, Einschränkung des Ziels und Protokollierung stets beifügen.
Besonders ③ ist wichtig. „Recherchierende“ Werkzeuge (Suche, Abruf, Lesen) richten wenig Schaden an, wenn sie versehentlich aufgerufen werden. „Verändernde“ Werkzeuge (Schreiben, Löschen, Senden, Ausführen) dagegen erzeugen mit einer einzigen Fehlbedienung unumkehrbare Folgen. Die eiserne Regel: Lesende und schreibende bewusst trennen und Letzteren mehrere Schutzschichten davorlegen.
| Typ | Beispiel | Risiko | Richtwert fürs Übergeben |
|---|---|---|---|
| Lesend | Suche, Abruf, Datei lesen | eher niedrig (Vorsicht beim Umgang mit Infos) | relativ frei. Bereich einschränken |
| Schreibend | Datei aktualisieren, DB-Schreiben, Senden | hoch (schwer rückgängig) | Prüfung, Einschränkung, Protokoll verpflichtend |
| Ausführend | Befehlsausführung, externer Aufruf, Abrechnung | maximal (Einfallstor für Amoklauf und Missbrauch) | grundsätzlich Schutz + menschliche Freigabe einschieben |
🔒 Das machen wir in Kapitel 6 gründlich. Die Kontrolle gefährlicher Werkzeuge, der Schutz gegen Prompt-Injection und der Entwurf von Freigabeabläufen sind unumgängliche Themen, um einen Agenten in die Produktion zu bringen. Wir behandeln sie gebündelt in Kapitel 6 „Guardrails und Sicherheit“, nehmen Sie aus diesem Kapitel also nur das Gespür mit, „dass Werkzeuge unterschiedliche Gefahrengrade haben“. Auch, keinen nicht vertrauenswürdigen MCP-Server leichtfertig anzubinden, ist eine wichtige Gewohnheit.
Fortgeschrittene Werkzeuge wie Browser-Steuerung
Unter den Werkzeugen fällt in jüngster Zeit besonders die Browser-Steuerung auf. Den Bildschirm betrachten, Links folgen, Formulare ausfüllen, Buttons drücken – kann man einem Agenten die Bedienung überlassen, die ein Mensch im Browser tut, verwandeln sich viele Webdienste ohne eigene API in „Hände und Füße“. Es sind Implementierungen aufgekommen, die Browser-Steuerung als MCP-Server bereitstellen, und die Anbindungshürde ist gesunken.
Allerdings ist dies zugleich eines der mächtigsten und risikoreichsten Werkzeuge. Die Gefahr, Anweisungen auf dem Bildschirm unbesehen zu übernehmen (Verleitung, Falschinformation), unbeabsichtigte Klicks oder Sendungen, das Offenlegen von Zugangsdaten – die Warnungen zu „Ausführend“ aus dem vorigen Abschnitt treffen genau zu. Klug ist, zunächst mit eher lesenden Anwendungen wie Betrachten und Informationsabruf zu beginnen und schreibende Operationen behutsam mit Schutzmechanismen zu versehen.
🌐 Wie viel kann man übergeben? Die realistische Leistung und die Grenzen von Browser-Steuerungs-Agenten prüft Wie weit kann KI Browser-Aufgaben automatisieren konkret. Hat man das Maß „kein Allheilmittel, aber bei engem Zweck praxistauglich“ im Blick, gerät die Werkzeugwahl nicht ins Wanken.
Nicht nur beim Browser gilt: Je fortgeschrittener das Werkzeug, desto größer werden „das Machbare“ und „das Mögliche“ in gleichem Maße. Gerade wenn Sie ein starkes Werkzeug übergeben, halten Sie die drei Prinzipien – Rechte, Beschreibung, Schutz – sorgfältig ein – das ist die Botschaft, die sich durch dieses Kapitel zieht.
- Die Fähigkeiten eines Agenten entscheiden sich durch Qualität und Zahl der angebundenen Werkzeuge. Oft wirkt das Werkzeugdesign stärker als der Kopf.
- Rohe Eigenbau-Werkzeuge sind schwer wiederverwendbar und werden zur Kombinationshölle N×M. Man wünscht sich einen gemeinsamen Anschluss.
- MCP ist ein offener Standard, der KI und externe Werkzeuge standardisiert anbindet. Das „USB für KI“, in dem Client (nutzende Seite) und Server (bereitstellende Seite) nach derselben Vereinbarung sprechen.
- Fertige MCP-Server (Datei/DB/Suche/SaaS) lassen sich einstecken und nutzen, eigene Werkzeuge als Eigenbau-Server wiederverwenden.
- Die Prinzipien des Übergebens: ① Rechte minimal ② Qualität der Beschreibung ③ gefährliche Werkzeuge gesondert. Je stärker das Werkzeug (z. B. Browser-Steuerung), desto behutsamer.
Weiß man, wie man Werkzeuge zusammenstellt, folgt als Nächstes die Stufe, „Agenten zu vermehren“. Wir gehen zu einem Entwurf über, in dem mehrere Agenten eine Arbeit, die einer allein nicht bewältigt, aufteilen und zusammenspielen. In Kapitel 4 „Multi-Agenten-Design“ lernen wir Rollenteilung und die Kooperation zwischen Agenten (A2A).