MCP als Verbindungsschicht einordnen

MCP als Verbindungsschicht einordnen

0:00 Jedes neue Protokoll bekommt im ersten Jahr mehr zugeschrieben, als es leistet. Beim Model Context Protocol ist das nicht anders: Es wird als Agenten-Framework verkauft, als Sicherheitsarchitektur missverstanden und gelegentlich als Ersatz für die eigene Schnittstelle gehandelt. Nichts davon trifft zu. Dieses Modul zieht die Linie in beide Richtungen — was MCP löst und was es ausdrücklich offenlässt.

0:23 Das klingt nach Haarspalterei, ist aber praktisch: Jede der drei Verwechslungen führt zu einem Projekt, das an einer Stelle scheitert, die man vorher hätte benennen können.

MCP als Verbindungsschicht einordnen

0:33 Wir bleiben noch einen Schritt vor der Technik. Im letzten Modul ging es darum, was ein Agent tut. Jetzt geht es darum, wie er an seine Werkzeuge kommt — und warum es dafür überhaupt ein Protokoll braucht. Wer am Ende dieses Moduls in drei Sätzen erklären kann, wofür MCP zuständig ist und wofür nicht, hat die halbe Diskussion im eigenen Team schon gewonnen.

Das Problem hinter dem Protokoll

0:54 Fangen wir mit dem Problem an, nicht mit der Lösung. Denn das Problem ist alt und kommt in der IT alle paar Jahre in neuer Verkleidung zurück. Die Spezifikation beschreibt MCP als offenes Protokoll für die Anbindung von Anwendungen mit Sprachmodellen an externe Datenquellen und Werkzeuge. Drei Dinge standardisiert es: Kontext mit Modellen teilen, Werkzeuge bereitstellen und beides zu zusammensetzbaren Integrationen verbinden.

1:19 Das Vorbild, das die Spezifikation selbst nennt, ist das Language Server Protocol. Dort war die Ausgangslage dieselbe: Jeder Editor brauchte für jede Sprache eine eigene Anbindung — bis ein Protokoll dazwischentrat und aus vielen Einzelverbindungen eine Schnittstelle machte. Die drei Schichten zeigen den eigentlichen Gewinn. Oben die Hosts — das sind die Anwendungen, die das Modell führen. In der Mitte die Clients, und zwar einer je Server.

1:46 Unten die Server selbst. Der Punkt, auf den es ankommt, ist die mittlere Ebene: Je Server eine eigene, isolierte Verbindung. Das klingt nach unnötiger Buchhaltung, ist aber die technische Form einer Sicherheitsentscheidung — kein Server sieht, was ein anderer liefert. Wir kommen im vierten Kapitel darauf zurück, warum das kein Detail ist.

2:07 Rechnen Sie einmal nach. Fünf Werkzeuge, drei Clients: Das sind fünfzehn Integrationen, die jemand schreibt und pflegt. Mit einem Protokoll sind es fünf. Das ist der ganze Zauber, und er ist alt. Interessant wird es bei der Umkehrung: Wenn Sie nur einen Client haben und nur ein Werkzeug, gewinnen Sie durch MCP nichts — dann bauen Sie eine Abstraktion für einen Fall.

2:29 Die Spezifikation nennt als Entwurfsprinzip, dass Server leicht zu bauen sein sollen. Das ist die ehrliche Antwort auf die Frage nach dem Aufwand: gering, aber nicht null. Der zweite Punkt ist der häufigste und der teuerste: Der Server bildet die interne API eins zu eins nach. Das fühlt sich effizient an, gewinnt aber nichts — Sie haben dann zwei Schnittstellen mit derselben Granularität, die beide gepflegt werden wollen.

2:55 Wir schauen uns in Modul 8 an, wann sich das lohnt und wann nicht. Der letzte Punkt ist organisatorisch: Wenn drei Teams unabhängig voneinander einen Server für dieselbe Datenquelle bauen, hat das Protokoll sein Versprechen nicht eingelöst — es fehlte ein Katalog. Darum geht es in Modul 17.

Abgrenzung zu REST, Function Calling und Frameworks

3:12 Kommen wir zu den Verwechslungen. Es gibt drei, sie kommen zuverlässig, und jede führt in eine andere Sackgasse. Der entscheidende Satz steht in der Architekturbeschreibung der Spezifikation selbst: MCP legt nicht fest, wie die Anwendung das Sprachmodell steuert oder den bereitgestellten Kontext verarbeitet. Lesen Sie den Satz zweimal. Er bedeutet, dass alles, was mit Planung, Orchestrierung, Kontextauswahl und Modellführung zu tun hat, außerhalb liegt.

3:40 MCP ist die Steckdose, nicht das Gerät und nicht das Kraftwerk. Es normiert den Stecker. Die Gegenüberstellung lohnt sich als Merkhilfe für die nächste Diskussion im Team. Links steht, was im Protokoll geregelt ist: wie Werkzeuge beschrieben werden, wie ein Aufruf übertragen wird, wie Ergebnisse strukturiert sind, wie Fähigkeiten ausgehandelt werden.

4:01 Rechts steht, was offenbleibt — und das ist genau das, was die meisten Menschen unter künstlicher Intelligenz verstehen: welches Werkzeug ausgewählt wird, wie geplant wird, wie der Kontext entsteht. Diese rechte Spalte ist Ihre Verantwortung. Sie wird nicht mitgeliefert. Die vier Zeilen sind keine Alternativen zu MCP, sondern Nachbarn in verschiedenen Richtungen.

4:22 Die REST-API liegt darunter — sie bleibt die fachliche Schnittstelle, und der MCP-Server ruft sie auf. Function Calling liegt auf der Modellseite; es ist der Mechanismus, mit dem das Modell überhaupt einen Aufruf formulieren kann, und es nutzt die Werkzeuge, die über MCP hereinkommen. Ein Agenten-Framework liegt darüber und steuert den Ablauf.

4:43 Nur die vierte Zeile ist tatsächlich ein Ersatzverhältnis: Herstellerspezifische Plugin-Formate sind das, was MCP ablösen soll. Der erste Punkt ist der teuerste, weil er ein Projekt kostet: MCP wird als Agenten-Framework eingeführt und enttäuscht dann erwartungsgemäß, weil Planung und Orchestrierung fehlen. Niemand hat gelogen — die Erwartung war falsch.

5:05 Der zweite Punkt ist die Umkehrung und begegnet mir seltener, richtet aber mehr Schaden an: Die REST-API wird abgeschaltet, weil es jetzt Werkzeuge gibt. Damit haben Sie Ihre fachliche Schnittstelle an ein Protokoll gebunden, das für Modellkontext entworfen wurde. Das rächt sich beim ersten Client, der kein Modell ist.

Was MCP ausdrücklich nicht löst

5:24 Jetzt wird es unbequem. Wir reden über die Lücken — und zwar nicht über Lücken, die noch geschlossen werden, sondern über solche, die konstruktionsbedingt offenbleiben. Die Spezifikation ist an dieser Stelle bemerkenswert offen. Sie hält fest, dass MCP seine eigenen Sicherheitsprinzipien auf Protokollebene nicht durchsetzen kann.

5:44 Zustimmung, Datenschutz und der sichere Umgang mit Werkzeugen stehen dort als Anforderungen an die Implementierung — nicht als Eigenschaften des Protokolls. Das ist keine Schwäche, sondern eine ehrliche Arbeitsteilung: Ein Nachrichtenformat kann nicht wissen, wer etwas darf. Aber es bedeutet, dass jedes Projekt diese Arbeit selbst erledigen muss. Und wer sie nicht bewusst erledigt, hat sie nicht erledigt.

6:08 Vier Dinge, die Menschen vom Protokoll erwarten und nicht bekommen. Autorisierung entsteht im Server — das ist Tag drei. Sinnvolle Entscheidungen des Modells garantiert kein Format, egal wie gut die Beschreibungen sind. Fachliche Korrektheit bleibt eine Frage von Tests, das ist Modul 12. Und der vierte Punkt ist der, den man am ungernsten hört: Ein schlecht geschnittenes Zielsystem bleibt schlecht geschnitten. MCP macht Ihre Architektur nicht besser.

6:36 Es macht sie zugänglicher — im Guten wie im Schlechten. Drei Prinzipien in fester Reihenfolge, und die Reihenfolge ist nicht zufällig. Zustimmung kommt zuerst: Nutzer müssen verstehen und zustimmen, was passiert, und die Kontrolle darüber behalten. Datenschutz folgt: Hosts holen ausdrückliche Zustimmung ein, bevor Nutzerdaten an einen Server gehen.

6:57 Und Werkzeugsicherheit bildet den Abschluss — Werkzeuge bedeuten die Ausführung von fremdem Code und sind entsprechend zu behandeln. Bemerkenswert ist der Zusatz, den die Spezifikation dort macht: Beschreibungen des Werkzeugverhaltens gelten als nicht vertrauenswürdig, solange der Server nicht vertrauenswürdig ist. Der zweite Punkt ist der, den Sie sich merken sollten, wenn Sie sich nur einen merken: Berechtigungen werden im Prompt formuliert statt im Server erzwungen.

7:24 Das sieht aus wie Sicherheit und ist keine. Ein Satz wie „du darfst keine Daten löschen" steht im selben Textfeld wie alles andere, das der Agent liest — und konkurriert dort mit dem, was in einem fremden Dokument steht. Der dritte Punkt ist der klassische Zuständigkeitsfehler: Der Host verlässt sich auf den Server, der Server auf den Host, und geprüft hat am Ende niemand.

Verantwortungsgrenzen im Zusammenspiel

7:45 Damit sind wir bei der Frage, die das Modul abschließt und den ganzen dritten Tag vorbereitet: Wer ist eigentlich für was zuständig? Die Architektur trennt das erfreulich klar. Der Host erzwingt Sicherheitsregeln und holt Zustimmung ein. Der Client hält die Grenze zwischen den Servern — er sorgt dafür, dass keiner über den Tellerrand sieht. Der Server arbeitet fokussiert und respektiert die Sicherheitsvorgaben.

8:10 Und das Zielsystem verantwortet Konsistenz und Nachvollziehbarkeit, so wie es das immer getan hat. Vier Rollen, vier Pflichten. Das Problem im Alltag ist selten, dass jemand seine Pflicht verletzt — es ist, dass niemand sie ausgesprochen hat. Lesen Sie die rechte Spalte als Vorschau auf Tag drei. Jeder typische Fehler in dieser Tabelle ist die Eintrittskarte für einen Angriff, den wir uns in Modul 14 konkret anschauen.

8:36 Der Mensch, der das Urteil mitdelegiert, öffnet die Tür für alles, was danach kommt. Der Host, der im Stapel bestätigt, macht die Zustimmung wertlos. Der Server, der dem Aufrufer vertraut, ist das klassische Confused-Deputy-Problem. Und das Zielsystem, das den Agenten nicht kennt, kann im Nachhinein nicht sagen, wer etwas getan hat.

8:57 Die Spezifikation formuliert das als eigenes Entwurfsprinzip, und zwar ungewöhnlich deutlich: Server sollen den gesamten Gesprächsverlauf nicht lesen können und auch nicht in andere Server hineinsehen. Der vollständige Verlauf bleibt beim Host. Das kostet Bequemlichkeit — es wäre praktisch, wenn ein Server wüsste, was vorher passiert ist.

9:16 Aber es ist die Voraussetzung dafür, dass Sie einen fremden Server einbinden können, ohne ihm alles zu zeigen. Wer diese Isolation aufweicht, weil es gerade einfacher ist, verliert genau die Eigenschaft, die das Einbinden fremder Server überhaupt vertretbar macht. Der erste Punkt passiert praktisch immer aus Bequemlichkeit, nie aus Absicht: Ein Server bekommt den gesamten Verlauf, weil die Aufgabe dann leichter zu lösen ist.

9:40 Der zweite ist der, der im Vorfall wehtut — zwei Server mit einer gemeinsamen technischen Identität lassen sich in den Protokollen des Zielsystems nicht mehr auseinanderhalten. Und der vierte beschreibt den Normalzustand in vielen Unternehmen: Das Zielsystem sieht einen Dienstnutzer und keinen Menschen. Ab dem Moment ist jede Frage nach dem Warum eine Rekonstruktion.

Übung

10:01 Zum Schluss übersetzen wir das Gelernte in etwas Konkretes — am besten an einer Integration, die Sie tatsächlich kennen. Die Übung hat einen Nebeneffekt, der oft wertvoller ist als das Ergebnis selbst. Wenn Sie eine bestehende Integration in die Begriffe des Protokolls übersetzen, wird sichtbar, was bei Ihnen heute implizit geregelt ist: Wer entscheidet, wer führt aus, wer darf was sehen.

10:24 Diese Fragen hat auch Ihre heutige Integration beantwortet — nur eben nebenbei und ohne dass jemand es aufgeschrieben hätte. Nehmen Sie eine Werkzeuganbindung aus Ihrem Alltag und zerlegen Sie sie in Host, Client und Server. Ordnen Sie dann jede Funktion einem der drei Primitives zu — Tool, Resource oder Prompt. Und notieren Sie zum Schluss, was weiterhin Aufgabe der bestehenden API bliebe.

10:47 Wer keine eigene Integration zur Hand hat, nimmt das Anliegenbuch mit seinem Architekturhandbuch und seiner Anforderungsablage. Die Zuordnung zu den Primitives lernen wir in Modul 4 formal — versuchen Sie es vorher aus dem Bauch heraus, das schärft den Blick. Der erste Punkt tritt bei fast jedem beim ersten Versuch auf: Alles wird zum Tool. Das liegt daran, dass Tools am bekanntesten sind und am aktivsten klingen.

11:12 Die nützliche Gegenfrage lautet: Wer löst diese Funktion aus — das Modell, die Anwendung oder der Mensch? Daraus ergibt sich die Zuordnung fast von selbst. Und achten Sie auf den dritten Punkt: Zeichnen Sie die Vertrauensgrenze ein. Wenn sie im Bild fehlt, fehlt sie erfahrungsgemäß auch im System. Im nächsten Modul wird aus den drei Rollen dann echte Technik.