Externe Datenquellen mit MCP

Externe Datenquellen mit MCP

0:00 Sprachmodelle sind erstaunlich gut darin, Code zu schreiben und Fragen zu beantworten. Bei einer Sache sind sie prinzipiell schlecht, und das lässt sich auch nicht wegtrainieren: bei allem, was gerade eben erst passiert ist. Das Repository, das Sie vor fünf Minuten angelegt haben, der Ticketstand von heute Morgen, die Kundendaten aus Ihrem internen System — davon kann kein Modell wissen.

0:22 In diesem letzten Modul schließen wir diese Lücke. Wir sehen uns an, wie die CLI externe Dienste anspricht, wie man sie einrichtet und wie man dabei maßvoll bleibt.

Anschluss an die Außenwelt

0:32 Der Weg führt vom Prinzip zur Praxis. Zuerst klären wir, welche Lücke dieses Protokoll überhaupt schließt — und welche nicht. Dann sehen wir uns an, was schon eingerichtet ist, denn einen Server bringt die CLI mit. Im dritten Teil geht es um die Konfigurationsdatei, also um den Teil, den Ihr Team versionieren und verantworten muss.

0:51 Und zum Schluss um eine Beobachtung, die viele überrascht: Ein eingerichteter Server wird nicht automatisch auch benutzt. Der erste Punkt enthält eine Einschränkung, die ich betonen möchte: „und welche nicht". Um dieses Thema herum gibt es viel Aufregung, und es lohnt sich, nüchtern zu bleiben. Ein Server macht ein Modell nicht klüger, er macht es anschlussfähig. Der Rest des Moduls ist Handwerk — ansehen, hinzufügen, abschalten, konfigurieren.

1:19 Und ein Punkt, der weniger nach Technik klingt und im Alltag wichtig ist: Freigaben so eng setzen, wie es geht.

MCP in der Copilot CLI

1:26 Fangen wir beim Prinzip an. Der Name klingt sperriger, als die Sache ist — es geht schlicht um eine gemeinsame Sprache zwischen KI-Werkzeugen und externen Diensten. Und darum, was sich damit ändert. Denn hinter dem Kürzel steckt keine neue Technologie, sondern eine Vereinbarung darüber, wie sich Werkzeuge anmelden und beschreiben.

1:46 Das klingt unspektakulär und ist der ganze Trick. Ein Bild, das gut trägt: Browser-Erweiterungen. Der Browser selbst kann surfen, mehr nicht. Erst die Erweiterung bringt ihm bei, Passwörter zu verwalten oder Texte zu prüfen. Genau so verhält es sich hier. Das Protokoll ist die Steckverbindung, ein Server ist das, was Sie einstecken, und die Werkzeuge sind die Funktionen, die er anbietet.

2:10 Praktisch wichtig für den Einstieg: Der Server für GitHub ist bereits eingebaut. Repositories, Issues und Pull Requests sind also erreichbar, ohne dass Sie irgendetwas einrichten. Der erste Punkt ist der prinzipielle: Der Wissensstand eines Modells endet an einem Datum, die Wirklichkeit nicht. Der zweite ist der, der in Unternehmen den Ausschlag gibt.

2:32 Kein Modell dieser Welt kennt Ihr internes Bestellsystem — und genau dort sitzen die Daten, mit denen Ihre Software arbeitet. Der vierte Punkt ist eine beruhigende Eigenschaft: Ein Server ist eine Erweiterung, kein Umbau. Sie können ihn hinzufügen, ausprobieren und wieder entfernen, ohne dass etwas zurückbleibt. Das lädt zum Experimentieren ein — mit einer Einschränkung, die gleich folgt.

2:56 Die ersten beiden Punkte sind der Grund, warum ich zur Zurückhaltung rate. Jeder aktive Server legt seine Werkzeugbeschreibungen ins Kontextfenster, und zwar bevor Sie das erste Wort tippen — Sie erinnern sich an die Tabelle aus dem dritten Modul. Mehr Auswahl führt dabei nicht zu besseren Antworten, sondern oft zu unschärferen.

3:15 Der dritte Punkt ist eine Sicherheitsfrage: Ein fremder Server ist Code, der auf Ihrem Rechner startet. Prüfen Sie die Quelle, bevor Sie ihn einrichten — und behandeln Sie Zugangsdaten entsprechend.

Server und Konfiguration inspizieren

3:27 Bevor Sie etwas hinzufügen, lohnt der Blick auf das, was schon da ist. Die CLI meldet beim Start, wie viele Server verbunden sind — und der Bestand lässt sich von zwei Seiten aus verwalten. Sie werden merken, dass Sie schon einen mitbringen, ohne je etwas eingerichtet zu haben — und dass sich der Bestand auch außerhalb der Sitzung verwalten lässt.

3:46 Zwei Wege führen zum selben Ziel: der Befehl innerhalb der Sitzung und derselbe Befehl außerhalb, direkt in der Shell. Das ist kein Zufall, sondern folgt einem Muster, das Ihnen aus dem letzten Modul bekannt vorkommt — auch Skills lassen sich beidseitig verwalten. Der Grund ist praktisch: Was Sie interaktiv ausprobieren, wollen Sie später vielleicht in einem Einrichtungsskript festhalten.

4:08 Angezeigt wird in beiden Fällen dasselbe: welche Server eingerichtet sind, ob die Verbindung steht und welche Werkzeuge sie anbieten. Diese Aufstellung folgt dem Lebenszyklus eines Servers: ansehen, hinzufügen, ändern, abschalten, entfernen. Eine Zeile verdient besondere Aufmerksamkeit — das Abschalten. Es ist der Mittelweg zwischen behalten und löschen: Die Einrichtung bleibt erhalten, der Server belegt aber keinen Platz mehr im Kontextfenster.

4:35 Wer mit mehreren Servern arbeitet, wird das oft brauchen und immer nur die einschalten, die zur aktuellen Aufgabe passen. Die Suchfunktion in der Fußzeile ist noch als experimentell gekennzeichnet — praktisch, aber nicht verlässlich genug für eine Anleitung. Der erste Schritt ist kein technischer, und das ist Absicht: Wer betreibt diesen Server, was tut er, welche Rechte will er? Erst danach kommt das Formular.

4:59 Der Servername ist mehr als eine Beschriftung — mit ihm sprechen Sie den Server später im Prompt an, also wählen Sie ihn kurz und eindeutig. Beim Typ entscheiden Sie zwischen einem lokal gestarteten Prozess und einem entfernten Dienst. Und der letzte Schritt ist der, an dem sich Sorgfalt auszahlt: die Freigabe der Werkzeuge. Alles freigeben ist die bequeme Antwort, eine Liste die bessere.

Einen MCP-Server konfigurieren

5:23 Schauen wir hinter die Oberfläche. Was Sie im Formular eintragen, landet in einer JSON-Datei — und die ist der Teil, der Ihr Team wirklich betrifft, weil er versioniert wird. Und weil sie versioniert wird, ist sie zugleich der Ort, an dem Ihr Team festlegt, welche externen Dienste im Projekt überhaupt erlaubt sind. Es gibt zwei Ebenen, und Sie kennen das Muster inzwischen von Agenten und Skills: eine im Benutzerprofil und eine im Projekt. Die Arbeitsteilung ist dieselbe.

5:50 Was Ihre persönliche Arbeitsweise betrifft, gehört ins Profil. Was das Team braucht, gehört ins Projekt — dort wird es mitversioniert und gilt für alle. Wichtig ist die Vorrangregel: Die Projektfassung sticht die persönliche. Wenn ein Server sich also plötzlich anders verhält als gewohnt, lohnt der Blick darauf, ob im Projekt eine zweite Konfiguration liegt.

6:13 Worauf es hier ankommt, ist die letzte inhaltliche Zeile. Alles davor ist Mechanik — wie der Server startet und womit. Die Werkzeugliste dagegen ist eine Entscheidung: Sie legt fest, was dieser Dienst in Ihrer Sitzung überhaupt tun darf. In vielen Anleitungen steht dort ein Sternchen, das alles freigibt, und in den meisten Konfigurationen bleibt es für immer stehen.

6:34 Dabei ist die Alternative kaum mehr Aufwand: Der Befehl zum Anzeigen eines Servers nennt Ihnen die verfügbaren Werkzeuge, und daraus wird eine kurze Liste. Fünf Minuten Arbeit, dauerhaft engere Rechte. Der zweite Punkt ist mir der wichtigste: Die Werkzeugliste ist eine Freigabe, keine Dokumentation. Sie beschreibt nicht, was der Server kann, sondern was er bei Ihnen darf — das ist ein Unterschied wie zwischen einem Prospekt und einem Schlüsselbund.

7:01 Der letzte Punkt ist der praktische Rat für den Alltag: Abschalten statt löschen. Damit halten Sie das Kontextfenster frei, ohne die Einrichtung samt Zugangsdaten noch einmal machen zu müssen. Für Server, die Sie nur alle paar Wochen brauchen, ist das genau der richtige Zustand. Der erste Punkt beschreibt den Normalfall, nicht die Ausnahme: alles freigeben und nie wieder einschränken.

7:23 Der zweite ist der klassische Fehler bei Zugangsdaten — sie gehören in Umgebungsvariablen, nicht in eine Datei, die im Repository landet. Der dritte ist tückisch, weil er still passiert: Zwei Konfigurationen für denselben Server, und die Projektfassung gewinnt, ohne jemanden zu fragen. Und der vierte ist schlicht Erfahrung: Nach einer Änderung lohnt der Blick, ob die Verbindung wirklich wieder steht.

7:46 Ein Server, der nicht verbunden ist, meldet sich nicht von selbst.

MCP-Server in der Praxis

7:51 Bleibt eine Beobachtung, die im Alltag für Verwirrung sorgt und die man einmal erklärt bekommen haben sollte: Ein eingerichteter Server wird nicht zwangsläufig auch benutzt. Das ist keine Fehlfunktion, sondern eine Folge davon, wie das Werkzeug entscheidet. Man muss es nur wissen, um die eigenen Ergebnisse richtig zu deuten.

8:09 Die Entscheidung, welches Werkzeug zum Einsatz kommt, trifft die CLI. Und sie hat oft mehrere Möglichkeiten: Für eine Frage zu Ihrem Repository kann sie den Server benutzen — oder einfach das lokale Kommandozeilenwerkzeug, das ohnehin installiert ist. Beides führt zum Ziel, aber Sie wissen hinterher nicht, welcher Weg genommen wurde.

8:29 Und manchmal antwortet das Modell einfach aus dem Gedächtnis, weil es glaubt, die Antwort zu kennen. Wer Gewissheit will, nennt den Server ausdrücklich im Prompt. Beide Beispiele haben denselben Bau: erst die Aufgabe, dann der ausdrückliche Hinweis auf die Quelle. Das ist kein Misstrauen gegenüber dem Werkzeug, sondern gute Praxis — bei einer Frage nach dem aktuellen Stand wollen Sie wissen, woher die Antwort stammt.

8:54 Die Fußzeile nennt den zweiten Teil davon: In der Ausgabe steht, welches Werkzeug tatsächlich aufgerufen wurde. Gewöhnen Sie sich an, dort hinzusehen. Es ist der einzige verlässliche Weg, eine Antwort aus dem Gedächtnis von einer Antwort aus der Datenquelle zu unterscheiden. Der zweite Punkt ist mir wichtig, weil er gern untergeht: Live-Daten machen eine Antwort nicht wahr. Sie machen sie nur aktuell.

9:18 Ein Server kann falsche oder veraltete Daten liefern wie jede andere Schnittstelle auch — die Quelle bleibt im Zweifel prüfungsbedürftig. Der dritte und vierte Punkt schließen den Kreis zu Modul drei: Jeder aktive Server kostet Platz im Kontextfenster, und zwar dauerhaft. Ein Server, den niemand mehr benutzt, gehört deshalb abgeschaltet — nicht aus Ordnungsliebe, sondern weil er sonst jede einzelne Anfrage verteuert.

9:42 Diese Aufgabe hat zwei Teile, und der zweite ist der lehrreichere. Der erste ist handwerklich: einen Server anbinden und einen Aufruf nachweisen. Der zweite verlangt eine Begründung für die Freigabeliste — warum diese Werkzeuge und nicht alle? Das ist genau die Frage, die in echten Projekten zu selten gestellt wird. Und der Zusatz lohnt sich: Stellen Sie dieselbe Frage einmal ohne Nennung des Servers. Sie werden sehen, wie oft ein anderer Weg genommen wird, als Sie erwartet hätten.

Das war der Kurs

10:11 Damit sind wir am Ende. Sie haben die CLI eingerichtet, kennen die vier Arbeitsweisen, steuern den Kontext bewusst, schreiben eigene Agenten und Skills und binden externe Datenquellen an. Wenn Sie aus diesen fünf Modulen zwei Sätze mitnehmen, dann diese: Der Modus entscheidet über die Kontrolle, der Kontext über die Qualität.

10:31 Alles andere sind Erweiterungen, und für die gilt: sparsam einsetzen. Der beste nächste Schritt ist jetzt kein weiteres Tutorial, sondern ein echtes Projekt, das Sie eine Woche lang damit begleiten.