MCP und externe Werkzeuge

MCP und externe Werkzeuge

0:00 Bisher hat unser Agent das gesehen, was im Repository liegt. Das ist viel — aber das Wissen eines Projekts endet nicht am Rand des Verzeichnisses. Anforderungen stehen im Ticketsystem, Datenbankschemata in der Datenbank, Entwürfe im Designwerkzeug. In diesem Modul geht es darum, wie der Agent diese Quellen erreicht, ohne dass jemand sie hineinkopiert. Das Mittel dafür heißt Model Context Protocol.

0:23 Und weil damit die Reichweite wächst, wächst auch die Verantwortung — darüber sprechen wir ebenso ausführlich wie über die Anbindung selbst.

MCP und externe Werkzeuge

0:32 Der letzte Tag beginnt mit der Erweiterung nach außen. Der Leitsatz: Der Agent kann nur, was er erreichen kann — MCP entscheidet, wie weit das reicht. Acht Kapitel führen vom Protokoll über die praktische Anbindung bis zur Frage, welche Werkzeuge überhaupt in eine gute Toolchain gehören. Dazwischen liegt eine wichtige Unterscheidung, die man einmal sauber begriffen haben muss: der Unterschied zwischen Kontext und Werkzeug. Beispielprojekt bleibt kanuverleih.

Model Context Protocol erklärt

1:00 Beginnen wir mit dem Standard selbst. Er ist erstaunlich unspektakulär, und genau das ist seine Stärke: Es geht darum, dass Werkzeuge und Agenten sich auf eine gemeinsame Sprache einigen. Sehen wir uns an, was das praktisch bedeutet, welche Bauformen es gibt und wo die Grenzen dessen liegen, was ein Standard leisten kann.

1:19 Das Model Context Protocol ist ein offener Standard, über den KI-Anwendungen externe Werkzeuge, Datenquellen und Dienste ansprechen. Ein MCP-Server bietet Funktionen an, der Agent ruft sie auf — unabhängig davon, wer beide gebaut hat. Der Vergleich, der trägt: eine genormte Steckdose. Sie müssen nicht wissen, welcher Hersteller den Toaster gebaut hat; der Stecker passt. Genau das leistet der Standard.

1:45 Und wie bei der Steckdose gilt: Dass etwas passt, sagt noch nichts darüber, ob das angeschlossene Gerät taugt. Vier Punkte. Ein Anbindungsweg statt einer Integration je Werkzeug — vorher musste jede Kombination aus Agent und Werkzeug einzeln gebaut werden. Server sind zwischen Agenten austauschbar; was Sie für ein Werkzeug bauen, funktioniert auch anderswo.

2:07 Wer das Werkzeug kennt, kann den Server schreiben — das öffnet die Entwicklung für Fachleute statt nur für Modellanbieter. Und Fähigkeiten wachsen, ohne den Agenten zu ändern. Das ist der klassische Gewinn eines Standards: Die Zahl der nötigen Verbindungen sinkt von einem Produkt auf eine Summe. Zwei Arten, wie ein Server läuft. Lokal als Prozess auf Ihrer Maschine — typisch für Zugriffe auf Dateien, Datenbanken oder Kommandozeilenwerkzeuge.

2:33 Oder entfernt als Dienst über HTTP — typisch für SaaS-Werkzeuge und Teamdienste. Die Fußzeile nennt den praktischen Unterschied bei der Einrichtung: Lokale Server starten mit einem Befehl, entfernte werden über eine Adresse angebunden. Für die Sicherheitsbetrachtung ist die Unterscheidung ebenfalls wichtig, denn ein lokaler Server läuft mit Ihren Rechten auf Ihrer Maschine.

2:56 Der erste Punkt ist die wichtigste Einordnung: MCP ist ein Protokoll, kein Qualitätsversprechen. Dass sich etwas anbinden lässt, sagt nichts über seine Güte. Der zweite ist die sicherheitsrelevante Folge: Ein Server bringt fremden Code auf Ihre Maschine — bei lokalen Servern buchstäblich. Der dritte betrifft die Reife: Nicht jeder Server ist für den Produktivbetrieb gedacht.

3:18 Und der vierte ist ein Wartungsthema: Die Fähigkeiten eines Servers ändern sich mit seiner Version, und damit auch das, was der Agent tun kann.

Warum MCP für Coding Agents zählt

3:27 Warum ist das gerade für Coding-Agenten interessant? Weil deren Blick standardmäßig genau am Repository endet — und das meiste, was man zum Entwickeln wissen muss, dort nicht steht. Sehen wir uns an, was durch die Anbindung möglich wird und welchen Preis das hat, denn kostenlos ist die erweiterte Reichweite nicht. Ein Coding-Agent sieht standardmäßig Dateien und die Shell. Alles andere — Tickets, Schemata, Fehlerberichte, Entwurfsdateien — liegt außerhalb.

3:55 MCP holt genau diese Quellen in Reichweite, ohne sie ins Repository zu kopieren. Der Zusatz ist wichtig. Die Alternative wäre nämlich, Dinge zu duplizieren: das Schema als Datei ablegen, den Ticketinhalt hineinkopieren. Kopien veralten. Eine angebundene Quelle wird zur Laufzeit gelesen und ist damit so aktuell wie das System, aus dem sie stammt.

4:18 Vier Möglichkeiten. Anforderungen direkt aus dem Ticketsystem lesen, statt sie hineinzukopieren. Datenbankschemata abfragen statt zu vermuten — und das Vermuten ist eine erstaunlich häufige Fehlerquelle, weil der Agent Schemata aus dem Code rekonstruiert. Fehlerberichte mit dem Code zusammenführen. Und Ergebnisse zurückschreiben, wo das Team sie sucht.

4:39 Der zweite Punkt allein rechtfertigt in vielen Projekten schon den Aufwand: Ein Agent, der das echte Schema kennt, schreibt deutlich weniger falsche Abfragen. Vier Zeilen, die jeweils denselben Übergang beschreiben: von Handarbeit zu Abfrage. Ticketinhalt hineinkopieren wird zu Ticket wird gelesen. Schema raten wird zu Schema wird abgefragt. Screenshot beschreiben wird zu Entwurf wird abgerufen. Und Ergebnis manuell übertragen wird zu Ergebnis wird eingetragen.

5:07 Die Fußzeile nennt beide Seiten der Medaille: Jede Zeile spart Handarbeit — und jede erweitert zugleich den Wirkungsbereich des Agenten. Der zweite Halbsatz ist der, um den es später in diesem Modul geht. Der erste Punkt ist die nüchterne Bilanz: Mehr Reichweite heißt auch mehr möglicher Schaden. Der zweite ist praktisch — externe Daten belegen Kontext wie jede andere Quelle, und Antworten von Diensten sind oft umfangreicher als erwartet.

5:34 Der dritte betrifft die Geschwindigkeit: Ein langsamer Server bremst die ganze Session, weil der Agent auf seine Antwort wartet. Und der vierte ist eine Abhängigkeit, die man bewusst eingehen sollte: Dienste fallen aus, und dann fällt Ihr Arbeitsablauf mit aus.

MCP-Server verbinden

5:49 Kommen wir zur Praxis. Das Anbinden ist unspektakulär: ein Befehl oder ein Abschnitt in der Konfiguration. Interessanter sind die Fragen drumherum — wo die Konfiguration liegt, wie Zugangsdaten hinterlegt werden und warum man nicht alles global eintragen sollte. Sehen wir uns beides an. Server werden entweder über die Kommandozeile hinzugefügt oder direkt in der Konfigurationsdatei eingetragen.

6:14 Lokale Server bekommen einen Startbefehl, entfernte eine Adresse und gegebenenfalls einen Zugangsschlüssel. Es ist dieselbe Konfigurationsdatei, in der auch Modell und Rechte stehen — was praktisch ist, aber auch bedeutet: Was Sie dort eintragen, gilt zunächst für alle Ihre Projekte. Es gibt daneben die Möglichkeit, Server auf ein einzelnes Repository zu begrenzen, und oft ist das die bessere Wahl.

6:37 Vier Handgriffe. Sie fügen einen lokalen Server mit seinem Startbefehl hinzu oder einen entfernten über seine Adresse. Sie lassen sich die angebundenen Server auflisten und prüfen sie in der Session. Die Fußzeile erklärt die Schreibweise: Der doppelte Bindestrich trennt den Servernamen von dem Befehl, der ihn startet — sonst weiß die Kommandozeile nicht, welche Argumente zu wem gehören.

6:59 Der dritte Befehl lohnt sich als Gewohnheit: Es sammeln sich mit der Zeit Server an, die niemand mehr benutzt. Zwei Einträge, einer je Bauform. Der lokale bekommt einen Befehl und dessen Argumente. Der entfernte bekommt eine Adresse — und einen Verweis darauf, in welcher Umgebungsvariablen der Zugangsschlüssel steht. Genau das ist die Zeile, auf die es hier ankommt, und die Fußzeile sagt es deutlich: Zugangsdaten gehören in Umgebungsvariablen, nie in die Konfigurationsdatei selbst.

7:28 Denn diese Datei wird kopiert, geteilt, in Backups gesichert und gelegentlich versehentlich in ein Repository eingecheckt. Der erste Punkt betrifft die Reichweite: Server projektweit einzutragen, wo einer im Projekt genügt, macht sie überall verfügbar — auch dort, wo sie nichts zu suchen haben. Der zweite ist die eben besprochene Schlüsselfrage. Der dritte ist eine Sorgfaltspflicht, die gern übersprungen wird: Server anbinden, ohne zu wissen, was sie anbieten.

7:56 Und der vierte ist ein Aufräumthema: Vergessene Server laufen weiter und kosten Kontext, weil ihre Werkzeugbeschreibungen mitgeladen werden.

Externe Datenquellen verfügbar machen

8:04 Beginnen wir mit dem harmlosesten und zugleich nützlichsten Teil: dem Lesen. Es gibt in jedem Projekt Wissen, das ordentlich dokumentiert ist — nur eben nicht im Repository. Sehen wir uns an, wie man solche Quellen anbindet und warum man dabei mit dem Lesen anfangen und nicht gleich schreiben sollte. Der größte Nutzen entsteht dort, wo Wissen bereits existiert, aber nicht im Repository liegt: in Tickets, Schemata, Entwürfen und Betriebsdaten.

8:30 Der Agent liest sie zur Laufzeit statt aus einer veralteten Kopie. Das ist der Unterschied zwischen einem Ausdruck und einem Blick ins System. Und es löst nebenbei ein Problem, das jeder kennt: Die Kopie im Repository stimmte am Tag ihrer Erstellung und ist seitdem stiller Ballast, auf den sich trotzdem jemand verlässt.

8:49 Fünf Schritte mit einer klaren Reihenfolge. Klären, welche Quelle wirklich fehlt — nicht welche man anbinden könnte. Nur die lesenden Zugriffe anbinden, zuerst. An einer echten Aufgabe erproben. Prüfen, was tatsächlich in den Kontext gerät. Und erst danach über schreibende Zugriffe entscheiden. Die Fußzeile hebt Schritt vier hervor, weil er regelmäßig überrascht: Antworten externer Dienste sind oft umfangreicher als erwartet.

9:15 Ein Ticketsystem liefert gern die komplette Kommentarhistorie mit — und die füllt Ihr Kontextfenster erstaunlich schnell. Vier Merkmale. Sie sind aktueller als jede Kopie im Repository. Sie liefern strukturierte statt erzählter Information — ein Schema ist präziser als eine Beschreibung des Schemas. Sie sind ohnehin die Quelle der Wahrheit im Team, was Diskussionen erspart. Und ihr Zugriff ist nachvollziehbar protokolliert.

9:42 Der letzte Punkt wird in regulierten Umgebungen wichtig: Wenn jemand fragt, wer wann welche Daten gesehen hat, gibt es beim angebundenen Dienst eine Antwort. Das Erfolgskriterium ist hier bewusst am Nutzen festgemacht: Eine Aufgabe, die vorher zusätzliche Handarbeit erforderte, wird mit der angebundenen Quelle gelöst. Wenn Sie das nicht zeigen können, war die Anbindung Selbstzweck. Der Hinweis nennt die Reihenfolge: Beginnen Sie lesend.

10:08 Schreibende Zugriffe kommen erst, wenn sich das Lesen bewährt hat — und dann als eigene, bewusste Entscheidung, nicht als Nebenprodukt.

Entwicklungswerkzeuge integrieren

10:17 Jetzt wird es interessanter — und heikler. Neben Datenquellen lassen sich Werkzeuge anbinden, die etwas tun: Testläufe anstoßen, Umgebungen bereitstellen, Abfragen ausführen. Damit verschiebt sich der Agent vom Lesen zum Handeln außerhalb des Repositorys. Sehen wir uns an, wie man das nach Risiko einstuft. Neben Datenquellen lassen sich Werkzeuge anbinden, die Aktionen ausführen: Testläufe anstoßen, Umgebungen bereitstellen, Abfragen ausführen.

10:46 Hier verschiebt sich der Agent vom Lesen zum Handeln außerhalb des Repositorys. Und das ist eine andere Größenordnung. Innerhalb des Repositorys schützt Sie Git — Sie können zurück. Außerhalb gibt es dieses Netz nicht. Eine ausgeführte Datenbankabfrage lässt sich nicht mit einem Befehl rückgängig machen. Vier Zeilen nach Risiko sortiert. Lesend: Schema abfragen, Ticket abrufen — beides gering.

11:11 Schreibend: einen Kommentar eintragen — mittleres Risiko, denn es ist sichtbar, aber korrigierbar. Ausführend: eine Abfrage laufen lassen — hohes Risiko, weil die Wirkung sofort und außerhalb Ihrer Kontrolle eintritt. Die Fußzeile zieht die praktische Konsequenz: Die Risikostufe bestimmt, ob eine Freigabe je Aufruf sinnvoll ist.

11:32 Bei lesenden Werkzeugen wäre sie lästig, bei ausführenden ist sie angebracht. Der erste Punkt ist der gravierendste: ausführende Werkzeuge gegen Produktivsysteme richten. Das passiert nicht mit Absicht, sondern weil die Zugangsdaten, die man zur Hand hat, oft die produktiven sind. Der zweite ist praktisch: Ohne Zeitlimit blockiert ein hängender Aufruf die ganze Session.

11:55 Der dritte betrifft die Fehlerbehandlung — Meldungen des Servers sind für den Agenten oft unverständlich, und er interpretiert sie dann kreativ. Und der vierte: Werkzeuge mit ähnlichem Namen werden verwechselt. Diese Übung ist schnell gemacht und lohnt sich: Stufen Sie jedes angebundene Werkzeug als lesend, schreibend oder ausführend ein und legen Sie eine passende Regel dazu fest.

12:17 Der Hinweis nennt die Frage, die man dabei stellen muss und die oft unbeantwortet bleibt: Gegen welche Umgebung arbeitet dieses Werkzeug tatsächlich? Nicht, wofür es gedacht ist — was in seiner Konfiguration steht. Der Unterschied ist im Zweifel erheblich.

Kontext und Tools unterscheiden

12:32 Jetzt zu einer Unterscheidung, die technisch klingt und ganz praktische Folgen hat: Was ist Kontext, und was ist ein Werkzeug? Beides bringt Informationen zum Agenten, aber auf völlig verschiedenen Wegen und mit völlig verschiedenen Kosten. Sehen wir uns an, warum das für Ihre Konfiguration wichtig ist. Kontext ist Information, die in die Antwort einfließt. Ein Werkzeug ist eine Fähigkeit, etwas zu tun oder etwas abzurufen.

12:58 Die Unterscheidung entscheidet darüber, was dauerhaft Platz kostet und was nur bei Bedarf wirkt. Das Bild dazu: Kontext ist das, was auf Ihrem Schreibtisch liegt. Ein Werkzeug ist die Telefonnummer der Fachabteilung. Das Erste nimmt Platz weg, ob Sie es brauchen oder nicht. Das Zweite kostet nur dann etwas, wenn Sie anrufen.

13:19 Drei Vergleichszeilen. Wann geladen: Kontext von Anfang an, Werkzeuge beim Aufruf. Kostet Platz: Kontext dauerhaft, beim Werkzeug nur das Ergebnis. Beispiel: Projektregeln gegenüber einer Schemaabfrage. Die Fußzeile gibt die Entscheidungsregel: Was selten gebraucht wird, gehört hinter ein Werkzeug — nicht in den ständigen Kontext.

13:40 Das ist dieselbe Logik wie bei Skills gegenüber Projektregeln aus dem vorigen Modul. Sie werden diesem Muster in agentischen Systemen immer wieder begegnen. Vier Gründe. Ständiger Kontext verdrängt die eigentliche Aufgabe — wer alles mitgibt, verwässert den Auftrag. Werkzeugergebnisse lassen sich gezielt anfordern, also genau dann, wenn sie gebraucht werden.

14:03 Fehlerquellen sind leichter zuzuordnen, weil ein fehlgeschlagener Werkzeugaufruf sichtbar ist. Und der vierte Punkt ist der interessanteste: Der Agent kann Werkzeuge kombinieren — erst das Schema abfragen, dann die Abfrage bauen. Statischer Kontext kann das nicht. Der erste Punkt beschreibt die häufigste Fehlkonfiguration: große Dokumente in den Dauerkontext legen, statt sie abrufbar zu machen.

14:27 Der zweite betrifft den Nutzen — Werkzeuge anbinden, deren Ergebnis kaum jemand liest. Der dritte ist ein Effekt, den man erst bei größeren Sammlungen merkt: Zu viele Werkzeuge machen die Auswahl unzuverlässig, weil der Agent zwischen ähnlichen Beschreibungen wählen muss. Und der vierte: Umfangreiche Antworten füllen den Kontext schneller als erwartet.

Berechtigungen und Sicherheitsgrenzen

14:48 Jetzt kommt der Abschnitt, den ich für den wichtigsten dieses Moduls halte. Denn es gibt eine Annahme, die naheliegt und falsch ist: dass die Sandbox des Agenten auch für angebundene Server gilt. Sehen wir uns an, warum das nicht so ist und was daraus für Ihre Zugänge folgt. Ein MCP-Server ist fremder Code mit Zugriff auf das, wofür Sie ihm Schlüssel geben.

15:09 Die Sandbox des Agenten schützt davor nicht: Was der Server tut, tut er in seinem eigenen Prozess und mit seinen eigenen Rechten. Das ist der Punkt, den man verstanden haben muss. Sie haben in Modul sieben sorgfältig eingestellt, was der Agent darf. Diese Einstellung gilt für den Agenten — nicht für einen Server, den Sie ihm zur Seite gestellt haben.

15:30 Der läuft eigenständig. Vier Prüfpunkte. Herkunft und Pflegezustand des Servers — wer hat ihn gebaut, wird er gepflegt? Welche Rechte der hinterlegte Zugang tatsächlich hat; das ist die Frage, die am häufigsten großzügig beantwortet wird. Ob er gegen Produktiv- oder Testsysteme arbeitet. Und was in den Protokollen des Dienstes landet — denn was Sie abfragen, sagt auch etwas über Ihr Projekt aus.

15:56 Diese vier Fragen kosten zusammen zehn Minuten und sind die beste Investition vor jeder Anbindung. Fünf Regeln. Server einzeln anbinden, nicht in Sammelpaketen — dann wissen Sie, was Sie haben. Zugänge mit den geringstmöglichen Rechten ausstatten. Auf Testsysteme richten, solange es geht. Die angebotenen Werkzeuge einmal vollständig durchsehen; Sie sollten wissen, was der Agent überhaupt aufrufen kann.

16:21 Und nicht mehr genutzte Server wieder entfernen. Die Fußzeile nennt den häufigsten Fehler: ein Zugang mit Vollrechten für einen rein lesenden Anwendungsfall. Das passiert aus Bequemlichkeit und fällt jahrelang nicht auf. Der erste Punkt ist eine Erwartungskorrektur: Der Agent kann Werkzeuge auch dann aufrufen, wenn Sie es nicht erwarten — er entscheidet selbst, was zur Aufgabe passt.

16:45 Der zweite ist die Vertrauensfrage: Ein kompromittierter Server sieht alles, was durch ihn läuft. Der dritte beschreibt einen Wartungsfehler — Rechte werden beim Anbinden vergeben und danach nie geprüft. Und der vierte ist ein Diagnoseproblem: Ausfälle des Dienstes erscheinen als Fehler des Agenten, und man sucht an der falschen Stelle.

Eigene Toolchains entwerfen

17:05 Zum Abschluss die Frage nach dem Maß. Es gibt inzwischen Hunderte von Servern, und die Versuchung ist groß, möglichst viele anzubinden. Sehen wir uns an, warum eine gute Toolchain durch Auswahl entsteht statt durch Sammeln — und mit welchem Verfahren man sie aufbaut, ohne den Überblick zu verlieren. Eine Toolchain ist die bewusst gewählte Menge an Werkzeugen für eine Arbeitsweise.

17:27 Sie entsteht nicht durch Sammeln, sondern durch Auswahl: Jedes Werkzeug muss einen wiederkehrenden Handgriff ersetzen. Das ist derselbe Maßstab wie bei Skills im vorigen Modul — und wie dort gilt: Was Sie einmal brauchen, rechtfertigt keine dauerhafte Anbindung. Eine große Sammlung sieht mächtig aus, macht aber die Auswahl unzuverlässiger und die Fehlersuche schwieriger.

17:49 Fünf Schritte, und die Reihenfolge ist der eigentliche Rat. Wiederkehrende Handgriffe außerhalb des Editors notieren. Je Handgriff prüfen, ob ein Server ihn abdeckt. Einen Server anbinden und zwei Wochen nutzen. Den Nutzen belegen oder ihn wieder entfernen. Und erst dann den nächsten anbinden. Die Fußzeile begründet das: Ein Server nach dem anderen — sonst weiß niemand, welcher den Unterschied gemacht hat.

18:14 Das ist dieselbe Disziplin, die man beim Optimieren von Software anwendet: eine Änderung, eine Messung. Vier Merkmale. Jedes Werkzeug hat einen benennbaren Anlass. Niemand im Team muss raten, was wofür da ist. Ausfälle sind zuzuordnen und zu überbrücken — Sie wissen also, was nicht mehr geht, wenn ein Dienst ausfällt. Und die Menge bleibt überschaubar und begründbar.

18:38 Der zweite Punkt ist im Team der wichtigste: Eine Toolchain, die nur ihr Erbauer versteht, ist ein Risiko — spätestens dann, wenn er im Urlaub ist. Der Hinweis liefert den Maßstab: Was Sie nicht in einem Satz begründen können, gehört nicht in die Kette. Das ist streng, aber es funktioniert. Gehen Sie Ihre angebundenen Werkzeuge durch, dokumentieren Sie je Werkzeug den Anlass und entfernen Sie die ungenutzten.

19:03 Das Aufräumen ist dabei der wertvollere Teil: Jeder Server, den Sie entfernen, spart Kontext, verkleinert die Angriffsfläche und macht die Auswahl für den Agenten eindeutiger. Vier Punkte zum Mitnehmen. MCP ist ein Standard für die Anbindung, kein Qualitätssiegel für den Server dahinter. Kontext kostet dauerhaft Platz, Werkzeuge nur ihr Ergebnis — deshalb gehört Selteneres hinter ein Werkzeug.

19:27 Die Sandbox des Agenten schützt nicht vor dem, was ein angebundener Server tut. Und jedes Werkzeug braucht einen benennbaren Anlass, sonst gehört es weg. Im nächsten Modul verlassen wir das interaktive Arbeiten ganz: Es geht um Automatisierung und das Codex SDK.