Model Context Protocol (MCP) in der Praxis

Model Context Protocol (MCP) in der Praxis

0:00 Bis hierhin hat der Agent im Projektordner gearbeitet — er kennt Ihren Code, aber er kennt Ihre Welt nicht. Das Ticket in Jira, den Pull Request auf GitHub, die Fehlermeldung im Log-System, die Zahlen in der Datenbank: All das liegt außerhalb und wird bislang von Ihnen hin- und hergetragen. Genau diese Botengänge sind das Thema dieses Kapitels. Das Model Context Protocol ist der Standard, über den Claude Code mit solchen Systemen spricht.

0:25 Wir klären zuerst, was dahintersteckt, schauen uns dann Projektmanagement und Dokumentation an und zuletzt die Welt von DevOps und Daten — inklusive der Frage, wo Vorsicht angebracht ist.

Model Context Protocol (MCP) in der Praxis

0:37 Drei Stationen liegen vor uns. Zuerst das Prinzip: Was ist MCP, was ist ein Server, und wie bindet man ihn an? Danach zwei Anwendungsfelder, die unterschiedlicher kaum sein könnten — einmal die Welt der Tickets und Dokumentation mit Jira, Linear und Notion, einmal die technische Seite mit GitHub, Logs und Datenbanken. Der rote Faden dabei: Externe Systeme werden zu Werkzeugen, die der Agent selbst bedienen kann.

Was ist MCP?

1:02 Fangen wir mit dem Prinzip an — und das lohnt sich, weil MCP kein Produkt ist, sondern eine Vereinbarung. Wer einmal verstanden hat, was diese Vereinbarung regelt, versteht auch, warum es plötzlich so viele Server dafür gibt. Denken Sie an USB. Vor dem Standard brauchte jedes Gerät seinen eigenen Anschluss und seinen eigenen Treiber; danach gab es einen Stecker, und alles passte.

1:25 Das Model Context Protocol ist dieser Stecker für KI-Werkzeuge — ein offener Standard, über den Claude Code mit externen Werkzeugen, Daten und Schnittstellen spricht. Die Gegenstelle heißt Server, und davon kann man beliebig viele anschließen. Der praktische Effekt ist der, der auch bei USB zählte: Sie kopieren nicht mehr manuell zwischen Systemen hin und her.

1:46 Der Agent greift selbst zu — und weil der Standard offen ist, hat ihn niemand allein in der Hand. Der erste Punkt ist die eigentliche Leistung: ein Protokoll statt vieler Sonderintegrationen. Wer schon einmal für jedes System eine eigene Anbindung gebaut hat, weiß, wohin das führt — jede einzelne muss gepflegt werden, und keine passt zur nächsten.

2:07 Daraus folgt der zweite Punkt, die Austauschbarkeit: Server lassen sich kombinieren und wieder entfernen, ohne dass etwas umgebaut werden muss. Der dritte beschreibt, wie sich das anfühlt — der Agent nutzt fremde Systeme wie eigene Werkzeuge, ohne dass Sie den Unterschied merken. Und der vierte ist eine Wette auf die Zukunft, die bisher aufgeht: Das Ökosystem wächst, neue Server kommen laufend dazu.

2:31 Fünf Schritte, und beim ersten steht ein Wort in Klammern, das keine Klammer verdient hätte: vertrauenswürdig. Dazu kommen wir im dritten Kapitel ausführlich. Die Registrierung selbst ist ein Einzeiler. Interessant ist Schritt drei, die Wahl des Scope: Gilt der Server nur lokal für Sie, für das Projekt oder für alle Ihre Projekte?

2:51 Diese Entscheidung ähnelt der Hierarchie aus dem CLAUDE.md-Kapitel — es geht wieder um die Frage, für wen etwas gelten soll. Im Projekt-Scope entsteht eine `.mcp.json`, die versioniert wird und damit im Team ankommt. Und die Fußzeile nennt die drei Transportwege: lokal als Subprozess oder gehostet über HTTP und SSE. Zwei Befehle, zwei Welten. Der obere bindet einen gehosteten Dienst über HTTP an — irgendwo läuft ein Server, Sie geben nur die Adresse an.

3:19 Der untere startet einen Server lokal als Subprozess auf Ihrem Rechner; das ist der Weg für Werkzeuge, die Zugriff auf Ihre Maschine brauchen. Der Unterschied ist nicht nur technisch, er ist auch einer des Vertrauens: Im ersten Fall verlassen Daten Ihren Rechner, im zweiten nicht. Behalten Sie das im Hinterkopf, wenn Sie später Server auswählen.

3:40 Und die Fußzeile nennt den Team-Aspekt: Im Projekt-Scope landet die Konfiguration in einer Datei, die alle im Repository bekommen. Binden Sie jetzt Ihren ersten Server an und nutzen Sie eines seiner Werkzeuge — das ist wichtig, die reine Registrierung reicht nicht. Erst wenn eine echte Aktion darüber läuft, wissen Sie, dass die Verbindung steht.

4:00 Der Hinweis ist mehr als Vorsicht, er ist eine gute Gewohnheit: Beginnen Sie mit einem Server, der nur liest. Sie lernen dabei genauso viel, riskieren aber nichts, solange Sie den Umgang noch nicht kennen. Schreibende Aktionen kommen dazu, wenn Sie einschätzen können, was der Agent damit tun wird — und diese Einschätzung braucht ein paar Sitzungen Erfahrung.

Projektmanagement & Doku

4:20 Vom Prinzip zur Praxis. Beginnen wir mit dem Bereich, in dem die meisten von uns täglich Zeit verlieren — und zwar nicht mit Denken, sondern mit dem Wechseln zwischen Fenstern. Rechnen Sie einmal nach, wie oft Sie am Tag zwischen Editor, Ticketsystem und Dokumentation hin- und herspringen. Jeder dieser Wechsel kostet nicht nur die Sekunden, sondern den Faden.

4:42 Über die offiziellen MCP-Server kann Claude Code diese Systeme selbst bedienen: Tickets in Jira oder Linear anlegen und verschieben, Zusammenfassungen in Notion ablegen — Sie bleiben im Terminal. Was das besonders macht, ist nicht die Bequemlichkeit, sondern der Kontext: Der Agent weiß, woran Sie gerade arbeiten. Ein Ticket, das aus dieser Situation heraus entsteht, enthält Details, die man beim nachträglichen Tippen längst vergessen hätte.

5:08 Der erste Punkt ist der offensichtliche — der Kontextwechsel entfällt. Der zweite ist der wertvollere, und er verdient eine kurze Einordnung: Aus dem Code-Kontext wird direkt ein präzises Ticket. Wir alle kennen die Bugreports, die aus drei Wörtern und einem Ausrufezeichen bestehen, weil das Schreiben lästig war. Wenn der Agent die Umgebung ohnehin kennt, verschwindet diese Hürde. Der dritte Punkt betrifft die stille Pflichtarbeit — Status pflegen, ohne die Weboberfläche zu öffnen.

5:37 Und der vierte ist eine kleine Hoffnung, die sich mit MCP tatsächlich erfüllen lässt: Dokumentation entsteht dort, wo die Arbeit passiert, nicht irgendwann später. Statt die Zeilen abzulesen: Die Tabelle zeigt drei Ausprägungen desselben Musters. Jeder Server bringt die Werkzeuge seines Systems mit — bei Jira sind das Vorgänge und Confluence-Seiten, bei Linear Issues und Zustände, bei Notion Seiten und Datenbanken.

6:01 Sie müssen diese Werkzeuge nicht kennen; der Agent liest ihre Beschreibungen aus und wählt selbst. Ihre Aufgabe ist die Auswahl der Server, und dafür steht die Fußzeile: Die Anbindung läuft meist über OAuth, und Sie sollten offizielle Server bevorzugen. Das ist kein formaler Hinweis — Sie geben diesem Server Zugriff auf Ihr Projektmanagement, mit allem, was dort an Interna steht.

6:24 Lassen Sie jetzt aus einem echten Kontext ein Ticket entstehen — am besten aus einem Fehler, dem Sie ohnehin gerade nachgehen. Der Hinweis spart Ihnen Frustration: Prüfen Sie vorab, welche Felder in Ihrem System Pflicht sind. Viele Teams haben Vorgaben zu Komponente, Priorität oder Label, und ein Ticket, das daran scheitert, kostet mehr Zeit, als es gespart hat.

6:45 Achten Sie beim Ergebnis auf die Beschreibung: Enthält sie den Kontext, den ein Kollege bräuchte, um den Fehler nachzuvollziehen? Genau daran erkennen Sie, ob der Agent tatsächlich aus der Situation heraus geschrieben hat.

DevOps & Data Warehouse

6:59 Bleibt die technische Seite: Code-Verwaltung, Betrieb und Daten. Hier wird MCP besonders mächtig — und genau deshalb sprechen wir in diesem Kapitel auch über die Risiken, die damit einhergehen. Drei Bereiche kommen hier zusammen, und sie decken einen guten Teil des Entwickleralltags ab. Über den GitHub-Server verwaltet Claude Code Issues und Pull Requests.

7:21 Über Log-Anbindungen wie Datadog oder Sentry kommt er an das, was im Betrieb tatsächlich passiert ist — Sie erinnern sich an das Debugging-Kapitel: Ohne Logs rät der Agent. Und über Datenwerkzeuge wie DuckDB oder MotherDuck kann er direkt SQL absetzen. Damit ist der Werkzeugkasten geschlossen: Code, Betrieb und Daten liegen in derselben Sitzung.

7:41 Das ist bequem — und es ist der Moment, in dem man über Berechtigungen nachdenken sollte. Die ersten beiden Punkte sind unmittelbar einleuchtend: Pull Requests ohne Browserwechsel und Fehlersuche über echte Logs statt über Vermutungen. Der dritte Punkt öffnet eine Tür, die vielen Entwicklerinnen und Entwicklern bisher verschlossen war — Datenanalysen per SQL, direkt aus dem Terminal, ohne dass jemand ein Dashboard bauen muss.

8:06 Aber der wichtigste Punkt ist der vierte, und er ist mehr als eine Aufzählung: ein Werkzeugkasten für Code, Betrieb und Daten. Genau diese Bündelung ist der eigentliche Gewinn — und zugleich der Grund, warum die nächste Folie von Risiken handelt. Wo alles zusammenläuft, wiegt ein Fehler schwerer. Diese vier Punkte sind mir die wichtigsten des Kapitels.

8:26 Ein MCP-Server ist fremder Code mit Zugriff auf Ihre Systeme — das ist eine neue Angriffsfläche, und sie war vorher nicht da. Der zweite Punkt ist der subtilste: Prompt-Injection. Was ein Server zurückliefert, landet im Kontext des Agenten, und es kann Anweisungen enthalten, die nicht von Ihnen stammen. Ein Ticketkommentar oder ein Logeintrag kann so zum Einfallstor werden. Deshalb der dritte Punkt: Rechte eng fassen, schreibende Werkzeuge bewusst freigeben, nicht pauschal.

8:56 Und viertens die Hygiene — Token rotieren, sensible Aktionen bestätigen lassen. Nichts davon ist exotisch, es ist normale Sicherheitspraxis in einem neuen Kontext. Diese Übung zeigt den Nutzen und die Vorsicht in einem. Lassen Sie eine unbekannte Datenbank erkunden — zuerst das Schema, dann eine erste aggregierende Abfrage, und lassen Sie sich das Ergebnis erklären.

9:18 Sie werden merken, wie schnell man auf diesem Weg zu einem Überblick kommt, für den man sonst eine halbe Stunde in irgendeinem Tool klickt. Der Hinweis ist die andere Hälfte der Lektion: Bleiben Sie bei lesenden Abfragen. Mutierende Aktionen gehören getrennt behandelt und bewusst bestätigt — auch dann, wenn Sie sicher sind, dass der Agent es richtig machen würde.

9:39 Fassen wir zusammen. MCP ist ein offener Standard mit austauschbaren Servern, und das Anbinden ist ein Einzeiler — die eigentliche Arbeit liegt in der Auswahl und im Scope. Für Projektmanagement und Dokumentation bedeutet das: Tickets und Zusammenfassungen entstehen dort, wo die Arbeit passiert, mit dem Kontext, der sonst verloren geht.

9:59 Für DevOps und Daten kommen Code, Betrieb und Analyse in einer Sitzung zusammen. Und quer über alles steht die Regel, die man nicht oft genug sagen kann: Rechte bewusst setzen. Im nächsten Kapitel wird es größer — Sub-Agenten und Agenten-Teams.

Ein Terminal, alle Werkzeuge

10:14 Externe Systeme werden zu Werkzeugen von Claude Code — das ist der Satz, der dieses Kapitel zusammenfasst, und man sollte ihn in beide Richtungen lesen. Nach vorn ist es ein echter Gewinn: weniger Botengänge, mehr Kontext, weniger verlorene Details. Nach hinten bedeutet er, dass Ihr Terminal jetzt Zugriff auf Dinge hat, die vorher hinter eigenen Anmeldungen lagen. Beides gehört zusammen.

10:38 Mein Rat für den Einstieg: Fangen Sie mit zwei, drei Servern an, die Sie wirklich brauchen, statt alles anzuschließen, was verfügbar ist. Fragen und das Material finden Sie unter www.HCO.de.