Episode 107: Model Context Protocol in der Praxis

00:00:02: Software Architektur,

00:00:05: der Podcast für Software

00:00:07: Architekten

00:00:09: auf Heiser Developer.

00:00:17: Willkommen zu einer neuen Folge des Heise Software Architektur Podcasts.

00:00:22: Heute geht es um das Model-Context-Protokoll, kurz MCP, ein neuer Standard, der Large Language Models, denn Zugriff auf Tools und Datenquellen ermöglicht quasi der USB-Stecker für KI.

00:00:38: Spannend ist das vor allem aus Sicht der Softwarearchitektur.

00:00:42: Welche Rolle spielt MCP in zukünftigen Systemlandschaften?

00:00:47: Welche neuen Architekturentscheidungen entstehen, wenn KI nicht mehr nur konsumiert, sondern aktiv mit unseren Systemen intragiert?

00:00:55: und welche Chancen, aber auch Herausforderungen, ergeben sich daraus.

00:00:59: Darüber spreche ich heute mit Ole Wendland von InnoQ.

00:01:03: Hallo, Ole.

00:01:04: Schön, dass du da bist.

00:01:05: Lass uns kurz mit der Vorstellung starten.

00:01:08: Wer bist du und was machst du?

00:01:10: Ja, mein Name ist Ole Wendland.

00:01:12: Ich bin bei der InnoQ Schweiz angestellt als Softwarekonzert, als Seniorkonzerten für Softwarearchitektur.

00:01:19: Ich mache viele kurten Projekte, was mir sehr wichtig ist.

00:01:22: Ich versuche, Das ist immer noch ein Großteil meiner Arbeit zu behalten.

00:01:28: Ich spreche aber auch auf Konferenzen, schreibe Artikel oder nehme jetzt Podcast wie mit dir auf.

00:01:34: Cool bist du da, freu mich extrem da.

00:01:36: Die nächsten, würde ich sagen, die nächste Stunde mit dir über das Model-Context-Protokoll.

00:01:42: zu sprechen.

00:01:43: Ja, lass uns direkt kurz die Basics da streifen.

00:01:47: Vielleicht kannst du mal auch in deinen eigenen Worten erklären, was ist das Model-Context-Protokoll?

00:01:53: Das Model-Context-Protokoll, das ist erstmal offiziell offener Standard von Antropic, der am Ende letzten Jahres, Ende November letzten Jahres, also im Jahr zwanzig, rausgekommen ist.

00:02:05: Die Idee ist es, wie du schon angedeutet hast, den large language models zugriff auf deine daten zu geben.

00:02:13: also diese language models sind ja universell einsetzbar aber sie haben halt ein großes problem.

00:02:20: damit sie für dich produktiv sein können müssen sie dich kennen müssen sie die daten deiner firma können und das model kontext protokoll ist jetzt ein standard wie du umsysteme.

00:02:34: verschiedenste arten anbinden kannst und es ist quasi ein layer der häufig also nicht zwingend immer aber in den allermeisten fällen auf bestehenden apis aufbaut und sie für die large language models aufbereitet.

00:02:49: Ich würde es gerne trennen in eine technische sicht und in eine funktionale sicht darauf.

00:02:54: noch später wenn wir zu dem problem kommen sollen erzähl du erstmal was

00:03:01: also wir geben eigentlich quasi dem system.

00:03:04: Kontext.

00:03:05: Es hat zwei Seiten.

00:03:06: Es gibt dem Modell Kontext und es gibt dem Modell auch die Möglichkeit zu handeln.

00:03:13: Das ist relativ wichtig.

00:03:14: Anders als zum Beispiel ein Racksystem, was ich weiß nicht, müssen wir erklären, was Rack ist.

00:03:20: Anders als Datenbanken, die nur Informationen enthalten, bekommt er hier auch erstmals die Möglichkeit zu agieren, Tools zu benutzen und aufzurufen.

00:03:33: wobei Tooluse jetzt auch nichts direkt Neues ist, aber die Standardisierung des Tooluses ist auf jeden Fall

00:03:39: neu.

00:03:39: Man hatte vorher so die frühen AI-Projekte, da hatten häufig das Problem des End Times, End Integration Problem, was man sonst aus der Architektur auch kennt, zum Beispiel Online-Shop- und Bankensystem.

00:03:54: Jeder Online-Shop soll End-Bankensysteme anbinden und das Bankensystem wird von End-Online-Shops angebunden.

00:04:02: Und das führt halt dazu, dass du immer x Integration baust und jeder baut seine Integration selber.

00:04:07: Und das Model-Context-Protokoll versucht das zu lösen, indem sie die Integration zur Seite des Service-Anbieters schiebt.

00:04:15: Das ist auch ein Schema, was wir sonst auch schon gesehen haben.

00:04:19: Gerade jetzt bei den Data Contracts sieht man es in letzter Zeit sehr akut.

00:04:24: Der, der die Sache bereitstellt, sollte auch die Integrationsschicht bereitstellen, weil er weiß am besten drüber, welche Updates es der API es gibt.

00:04:31: wie man diese Sachen verwenden soll.

00:04:33: und diesem Konzept folgt das Model-Context-Protokoll eigentlich

00:04:36: auch.

00:04:37: Kann man es vergleichen, hinsichtlich Standardisierung, wie zum Beispiel ein Open API-Kontrakt aufgebaut ist?

00:04:46: Ist das vergleichbar?

00:04:47: Ähnlich, würde ich sagen.

00:04:51: Die Service-Seite, die es anbietet, hat verschiedene Capabilities, die es anbieten kann.

00:04:56: Mit den Capabilities kommen auch schon verschiedene Constraints.

00:05:00: womit der Anbieter das Modell etwas leiten kann oder den User schon etwas leiten kann.

00:05:06: Es kann selber schon festlegen, wie es verwendet werden sollte, idealerweise.

00:05:10: Und das ist halt so die, was ich nenn's mal, die fachliche Schicht.

00:05:14: Man bietet verschiedene Capabilities an.

00:05:17: Mit dem Capabilities kommen verschiedene Annahmen und Constraints mit, wie die API verwendet werden soll.

00:05:24: Genau.

00:05:24: Und wie die einzelnen Tools dann aufgebaut werden und wie sie beschrieben werden, das ist dann halt wieder offen.

00:05:30: Okay.

00:05:31: Aber es bietet eine gewisse Standardisierung.

00:05:34: schlussendlich, wie man es verwendet.

00:05:37: Okay.

00:05:38: Wir sind schon ein wenig abgeschweift.

00:05:40: Lass uns zuerst noch ein wenig Richtung der zentralen Bausteine von MCP gehen.

00:05:47: Welche zentralen Bausteine?

00:05:49: kropagiert mcp schlussendlich?

00:05:51: also wenn wir das erst mal von der architektur sicht betrachten dann hat man in der regel den host oder den client.

00:06:00: der ausdruck hat sich in der neuesten spezifikation gewandelt.

00:06:02: früher nannten sie es immer den client mittlerweile heißt es der host.

00:06:07: die beiden ausdrücke sind jetzt so vertauschbar da darf man sich nicht verwirren lassen.

00:06:12: also wenn man zum beispiel jetzt die liste der Post suchst, muss man eigentlich nach der Liste der Klein suchen, da ist die Spezifikation gerade nicht eindeutig, weil sich das im Juni noch geändert hat.

00:06:24: Das ist aber die Seite, die das aufruft quasi.

00:06:27: Das kann ein Mensch vor einem Cloud Code sein.

00:06:30: Da sitzt auf jeden Fall in der Regel immer das Lash Language Model.

00:06:34: Dann gibt es den MCP Server, der von der Applikationsseite meistens angeboten wird oder der die Applikation anbietet.

00:06:43: Es gibt Viele freie MCP Server auch im Netz, aber auf Security kommen wir noch.

00:06:48: Da muss man immer vorsichtig sein, dass die aus verlässlichen Quellen kommen.

00:06:52: Und es gibt natürlich dann noch als dritte Partei die Anwendungsseite, dein Gira, dein Confluence, dein File System, Datenbank, was immer man noch anbinden möchte.

00:07:03: Das sind eigentlich so diese drei Blöcke, Client, Server und Application.

00:07:08: Und wenn wir jetzt so in die Logik eingehen, gibt es auch drei Punkte.

00:07:13: Es gibt die Tools, das ist das, was eigentlich in achtzig bis neunzig Prozent der Fälle benutzt werden.

00:07:20: Das sind Aufrufe des Clients Richtung Seite des MCP-Servers, der es dann an die Anwendung weiter leitet.

00:07:28: Das ist eigentlich das, was jeder macht.

00:07:31: Tools werden vom... Kleint gesteuert und du kannst damit auch Streiboperationen oder Delete-Operationen und nicht nur Leserooperationen ausführen.

00:07:41: oder halt auch eine Query mit verschiedenen Parametern.

00:07:44: Dann gibt es Ressourcen.

00:07:47: Ressourcen sind Informationen, die man abruft.

00:07:49: Man nennt das auch Application-Based, weil die Applikation eigentlich festlegt, wie diese Ressourcen zusammengestellt werden, die man dann abrufen kann.

00:07:59: Gute Beispiele sind dafür irgendwelche FAQs oder irgendwelche Architekturdokumentationen, Glossars, Datenbankviews.

00:08:07: Das fällt klassisch unter Ressourcen.

00:08:10: Und dann das Dritte, was allerdings relativ selten verwendet wird, sind Promts.

00:08:15: Promts verbinden keine Action, sondern Promts bieten dem Client, der das der Client leicht ist, dann meistens einen User weiter.

00:08:25: mehr so Workflows an oder Anleitung, was zu tun ist, welche Schritte er als nächstes machen kann, welche Filter er verwenden könnte, um seine Sichtweite einzuschränken, sonst sind er Anleitungen.

00:08:39: So kann man sich das ungefähr vorstellen.

00:08:41: Okay, cool.

00:08:43: Super Übersicht.

00:08:44: Das heißt, wenn ich jetzt aus dem Client stelle ich eigentlich oder registriere oder Ich mache ihm kämtlich welche Tools er eigentlich über meinen Server ausführen kann.

00:08:57: Stimmt das mit dem MCP Protokoll?

00:09:00: Genau, also wenn man sich das einfach vorstellen kann, führt der Server und der Client eine Konversation wie ein Chat.

00:09:10: Ganz einfach, weil Large Language Models darauf trainiert sind.

00:09:13: Vor allen Dingen auch eins zu eins Konversationen zu führen.

00:09:16: Und sie haben sich es einfach gemacht, sie haben Dieses Feature, worin sie immer schon gut sind, genutzt und gesagt, gut, jetzt erweitern wir das.

00:09:24: Und so ist das intern auch ein bisschen aufgebaut.

00:09:27: Also man hat so, technisch ist das einfach ein JSON-RPC-Protokoll, was eigentlich Antwort und Frage, Antwort und Frage, Antwort und Frage hintereinander einfach kombiniert.

00:09:38: Und relativ simpel gibt es dann irgendeine Form von Textbuffer, wo es drin steht.

00:09:43: Und ja, man kann es sich quasi als Chat zwischen dem Server und dem Klein vorstellen, was einfach der sinnvollste Anwendungsfeier war oder einfach die Fähigkeiten, die das Modell eh schon hat, nutzt.

00:09:57: Okay, das war spannend.

00:09:59: Rainer, als eigenem Interesse, ich habe mir überlegt, so ein MCP-Ebeispiel für meine Architektur-Dokumentation zu schreiben.

00:10:07: Und in meiner Architektur-Dokumentation habe ich zum Beispiel ADRs, Architecture Decision Records.

00:10:13: Jetzt gemappt, auf diese Konstrukte wäre quasi Das Tool wäre erstellen wir ein ADR, dann die Ressourcen wären alle meine Architekturdocumentationen.

00:10:28: Und der MCP oder der Server stellt mir eigentlich die Möglichkeit oder stellt dann klein die Möglichkeit zur Verfügung, quasi die ADRs zu erstellen, editieren und quasi mit der Dokumentation zu intragieren.

00:10:42: Und der Klein ist mehr oder weniger... das Interface, welche die Konversation zur Verfügung stellt.

00:10:48: Stimmt das?

00:10:49: Ganz genau.

00:10:53: Eine Sicht, auf die ich noch nicht eingegangen bin, ist die Laufzeit Sicht.

00:10:57: Was ein bisschen die Besonderheit ist, da kommen wir jetzt auch zu der USB-Analogie.

00:11:02: Anfang mochte ich sie nicht so gerne.

00:11:04: Mittlerweile finde ich sie eigentlich ganz gut, weil es zwei Limitationen darstellt.

00:11:10: In den meisten Fällen läuft, hat ein Server ein Kleint als Verbindung.

00:11:16: Also eine Eins-zu-Eins-Verbindung, ähnlich wie beim USB-Protokoll, wo du nicht jetzt auch zwei Computer an deinen Drucker anschließen kannst bei USB-Douts, sondern du müsstest über irgendein Splitter oder ein anderes Gerät gehen.

00:11:29: Und das, ich finde diesen Ausdruckserver ehrlich gesagt nicht besonders gelungen, weil wir assoziieren was mit dem Ausdruckserver.

00:11:37: Und meistens ist das irgendwie eine hochskalierende M-zu-N-Verbindung.

00:11:42: Zehn Clients nutzen einen Server und so ist es halt eher nicht gedacht, sondern ein Client benutzt eher einen Server.

00:11:51: Also Adapter wäre für mich glaube ich oder zumindest in meiner Vorstellung der bessere Ausdruck gewesen.

00:11:57: Es gibt ein bisschen den Versuch das gerade aufzuweichen.

00:12:02: Also mit der letzten Neuerung wird eine Session ID zum Beispiel immer mitgegeben.

00:12:09: Aber das deckt noch nicht den ganzen Scope ab, weil Prinzip müsste man dann die Sessions trennen.

00:12:16: Man muss halt so bleeding verhindern, die Session Kontext und wie das gemacht wäre, also das technisch kann man das alles machen.

00:12:23: Aber eins der Design Principles von den MCP-Servern war eigentlich, dass sie besonders lightweight sein sollten und einfache Implementierungen sind häufig nur dreihundert, vierhundert Zeilen.

00:12:33: Also es gibt von Entropics, so Beispiel, Implementation für File System, Access, ich glaube, Das sind nur zu hundertfünfzig Zeilen oder so.

00:12:41: Und wenn du jetzt halt den ganzen, den ganzen Session Management, deine Authentifizierung für End-User integrieren musst, dann sind sie halt nicht mehr wirklich lightweight.

00:12:50: Darum bringt dir diese, also es wird vermutlich in diese Richtung gehen, weil es ganz viel Bedarf dazu gibt.

00:12:58: Aber historisch gesehen waren die MCP Server auch häufig in Agent Kontexte gedacht.

00:13:07: Und dass der Klein und der Server tatsächlich in einem Artifakt läuft, einem Agent und bestimmte Aufgaben macht.

00:13:15: Darum war Security nicht der erste Konzern.

00:13:21: Und eines der Standard-Protokolle ist auch Standard-IO, weil es eigentlich in irgendeinem Böcker-Container zusammen mit dem Language-Model laufen sollte.

00:13:30: Und der historische Kontext empfiehlt sich übrigens kleiner Lifehack immer den ersten Talk zu einem Protokoll anschauen.

00:13:37: Weil da häufig wird drüber geredet, was die Anforderung war, der wird übrigens auch in den Shownotes verlinkt, hatte ich dir mit reingepackt.

00:13:46: Und da alle Beispiele drehen sich darum, Agents.

00:13:49: Sie erwähnen zwar, dass es auch dazu gedacht ist, Anwendung anzusteuern, aber der initiale Gedanke war Agents eigentlich und wie man Agents Systeme verfügbar machen kann.

00:14:00: Und so war es, dass man sieht es in den Designentscheidungen, welche Designentscheidungen sie getroffen haben.

00:14:05: Und dann ist das... der MCP-Server halt abgehoben wie eine Rakete und ich verstehe Entropage.

00:14:11: Das ist ein Start-up.

00:14:12: Sie sind von Investoren Geld abhängig.

00:14:14: Sie machen kein Geld.

00:14:15: Das Marketing kommt natürlich auf die Leute zu.

00:14:17: Ihr habt was, das zieht Aufmerksamkeit ohne Ende.

00:14:20: Jetzt gibt den Leuten das, was sie wollen.

00:14:22: Aber viele der frühen Designentscheidungen zeigen halt nicht daraufhin, dass ein Server n-clients bedienen kann.

00:14:29: Das war eigentlich nicht so mitgedacht.

00:14:31: Und jetzt haben sie halt Das ist eine suboptimale Designentscheidung für diesen Anwendungsfall, aber wir stricken es gerade in die Richtung um, dass man ein Server wahrscheinlich mehrere Clients bald haben

00:14:44: kann.

00:14:45: Das ist spannend, weil als ich mich damit einlass, fand ich eben auch komisch, wenn du da dein MCP Server registrierst, zum Beispiel Cloud Desktop.

00:14:55: Er fährt den Server bei sich quasi hoch und dort sieht man eben, dass dieser Serverbegriff eben auch misleading sein kann, dass es eher ein Rapper um eine gewisse Funktionalität entsprechen ist, um diese Ressourcen herum.

00:15:10: Danke für den Lifehack, das ist ein Augenöffner, dass man eben die Initialen Ideen hier kennenlernt.

00:15:19: Was ist ursprünglich gedacht?

00:15:20: Ja, da hat man das Marketing meistens noch nicht eingegriffen, sondern da reden die Entwickler frei weg von der Leber, was sie sich eigentlich dabei gedacht haben.

00:15:28: Genau, der Chef-Entwickler oder der Erfinder zeigt seine Ideen ohne Marketing rundherum.

00:15:36: Was mich natürlich jetzt brennend interessiert sind, konkrete Anwendungsfälle vielleicht direkt aus deinem Arbeitsumfeld, aus deinem Projekt, wo man, wo MCP schon im Einsatz ist oder vielleicht bald eine Rolle spielen wird.

00:15:52: Also aufgrund beim Kunden haben wir bis jetzt mehrere lesende MCP Server im Einsatz.

00:15:59: Da können wir gleich bei den Security Themen nochmal darauf eingehen, warum das so ist.

00:16:03: Und bei uns in der Firma haben wir tatsächlich für die Zeiterfassung einen MCP Server relativ früh schon implementiert, der mir auch, den ich täglich benutze, der mir relativ viel Freude bereitet, weil es einfach den Workflow beim Arbeiten viel leichter macht.

00:16:19: Also am Ende beim Kommit kann ich halt, ich arbeite viel mit Cloud Code in letzter Zeit, kann man Cloud Code sagen, jetzt buch bitte mit die letzten fünf Stunden auf dieses Projekt diese Kostenstelle.

00:16:32: Und das macht tatsächlich das Leben deutlich, ich war nie ein Freund davon, irgendwelche Zeiterfassungsschieds auszufüllen.

00:16:40: Und seitdem läuft das halt viel besser, wo ich gleich am Ende sagen kann, wo ist mir dahin?

00:16:45: Ich muss nicht durch die zwei Fakta-Authentifizierung, das macht mein Cloud Code alles für mich.

00:16:50: Damit habe ich viel Freude und das erhöht tatsächlich auch meine Produktivität.

00:16:53: jetzt nicht, dass ich damit stunden jeden Tag spare, aber ich mache das Leben einfach angenehm.

00:16:59: Reino ist Interesse, also dort einfach reine, die reine Zeitenfassung.

00:17:04: oder Weiß, Klood auch Welche Kundenprojekte ihr habt und so weiter.

00:17:10: Deswegen sagst du vier Stunden auf Projekt X beim Kunden an zum Beispiel.

00:17:15: Claude Weiß kennt auch die ganzen Kundenprojekte, das kennt die Stunden-Sätze, das erkennt, wenn eine Kostenstelle überbucht ist oder geschlossen wurde.

00:17:25: Und dann gibt es eine entsprechende Warnung zum Beispiel, oder?

00:17:28: Ja,

00:17:29: wäre möglich, sagen Sie mal.

00:17:32: Doch, es gibt mittlerweile entsprechende Warnungen.

00:17:39: Es wird immer interessant, wenn MCP Server oder Agenten Dinge tun können.

00:17:44: Weil wir dann in die Probleme der Robotik reinlaufen.

00:17:48: Sie verändern ihre Umfeld.

00:17:51: Und was fünfmal geklappt hat, kann beim sechsten Mal schief gehen.

00:17:54: oder teilweise machen sie halt auch Dinge, die nicht gewollt sind.

00:18:00: Und die Zeit der Fassung macht zum Beispiel auch einen Vorkast.

00:18:05: Vorkast für die nächsten Monate werden in einem selben Tool erfasst und wenn er das dann auf die Kostenstelle nicht mehr buchen kann, bucht das eventuell als Vorkast oder er kommt auf die Lösung, dass er eine gleichnamige Kostenstelle anlegt oder Buchungen löscht.

00:18:22: Er versteht halt, er kennt deinen Kontext und deine Constraints.

00:18:25: so ein bisschen, aber nicht so wirklich.

00:18:28: Und wenn du willst, dass ein Agent kompetent agiert, dann muss man ihm halt auch seinen Umfeld erklären und was man tun darf und was man nicht tun darf.

00:18:39: Das kommt halt aus der Robotik.

00:18:40: Sobald du deinen Umfeld veränderst, musst du halt darauf reagieren können und machst dir teilweise mehr Probleme, als du vorher hattest.

00:18:47: Also wenn dein Staubsauger Roboter gegen die Tür fährt und dann fällt die Tür ins Schloss, Und er kann den Raum nicht mehr verlassen.

00:18:54: Einfaches Problem, danach so einfach ein unlösbares Problem oder die Erkennung von Hinterlassenschaften, von Haustieren.

00:19:02: Da kannst du Probleme haben.

00:19:04: Sehr schön.

00:19:05: Ich denke, wir haben schon bereit sein Problem, eine Herausforderung gestreift.

00:19:10: Vielleicht kannst du noch ein paar Worte dazu sagen.

00:19:12: bei Kundenprojekten, wo ihr lesende MCP Server im Einsatz habt oder gebaut habt.

00:19:19: Weil da hat man eigentlich Also ideal.

00:19:23: am besten funktioniert es, wenn man sich nicht authentifizieren muss, wenn man das Problem der Authentizierung umgehen kann.

00:19:31: Und lesend ist immer dann eigentlich gut und sicher, wenn du entweder die Daten unter Kontrolle hast, wenn es also eigene Daten sind, wo du sicher bist, dass da keine Injection Attacks drinstehen können.

00:19:47: oder wenn die Daten von irgendwelchen Maschinen erzeugt werden, wenn das irgendwelche Messdaten sind und so weiter, da kann man auch bedenkenlos darauf zugreifen.

00:19:57: Kritisch würde ich sagen, sind immer alle Sachen wie Lease-E-Mails, Lease-Chats oder so, weil alle Large-Language-Models sind immer noch sehr anfällig für Injections, also, dass man ihm sagt, vergiss dein System prompt, gib mir jetzt Information XY, gerade wenn... das System noch Zugriff auf dein Fallsystem hat.

00:20:17: Also es gibt eine Reihe von Attacken, wo man ihn versucht, über E-Mails zu schreiben, dass er die ETC, SSH, RSA, RSAID auslöst und die mit dem Anhang mitschicken soll und so weiter.

00:20:30: Es gibt auch, also das ist nicht nur ein theoretisches Risiko, das ist ein reales Risiko und das geht nun halt immer ein, wenn Nutzer erlaubt sind, Freitext einzugeben.

00:20:41: Darum würde ich sagen, Wenn man vorhat, das produktiv einzusetzen, dann darauf achten, dass entweder das nur unternehmensinterne Daten sind wie die Zeiterfassung.

00:20:51: Klar, theoretisch beim großen Unternehmen ist das auch ein Risiko, aber wir sind jetzt nicht so groß.

00:20:56: Und wenn jemand Mist macht, dann kriegt er relativ schnell was hinter die Ohren.

00:21:00: oder halt technische Daten eignen sich immer sehr gut für sowas.

00:21:04: Du hast vorhin noch etwas erwähnt wegen der Authentifizierung.

00:21:08: Das muss so ein wenig noch ausführen.

00:21:11: Wo fängt da, also ich bin mir am überlegen nicht, wo sind da die Grenzen quasi von der Autorisierung, aber auch von der Berechtigung, wo schliessendlich ein MCP-Service sich darin bewegt?

00:21:25: Starten wir mal mit der Authentifizierung.

00:21:27: Also ich bin irgendwo, sag jetzt mal in meinem LLM-Client drin, dort bin ich angemeldet, richtig, oder?

00:21:35: Ich schreibe da quasi eine Prompt.

00:21:39: sagen wir zum Beispiel jetzt die Zeiterfassungsgeschichte.

00:21:43: Und dann erfassen wir zum Beispiel Zeitbuchung XY, der will ein Tool ausführen, quasi auf diesen Zeiterfassungs-MCP.

00:21:57: Und dort ist schon mal eine Frage, wie authentifiziert man sich dort?

00:22:01: Oder gibt es dort keine Authentifizierung?

00:22:04: Sagen Sie, okay, intern ist man vielleicht ... Anders behandeln aus, wenn es wirklich extern wäre.

00:22:11: Vielleicht kannst du mir dazu sagen.

00:22:14: Das ist eine sehr gute Frage.

00:22:16: Eigentlich haben wir es hier mit einem doppelten Authentifizierung zu tun.

00:22:20: Einmal muss sich der Client gegenüber dem Server authentifizieren, dass es mit den neuen Spezifikationen relativ gut gelöst, weil die MCP Server jetzt neuerdings als O-Aus-Resource-Server fungieren müssen.

00:22:36: Das Problem würde ich mal als mehr oder weniger gelöst betrachten, aber jetzt kommt der zweite Teil.

00:22:43: Der MCP Server soll ja in deinem Namen an einer API irgendwas auslösen.

00:22:50: Und das ist eigentlich die doppelte Authentifizierung, für die man bis jetzt in den meisten Fällen keine gute Lösung hat.

00:22:56: Also was viel zurzeit gemacht wird oder was ich auch gemacht habe, ist so Personal Access Tokens.

00:23:02: Man kennt das so von Git, dass man sich in der Anwendung in seinem Git Repository einen Access Token generieren lässt und die in die Konfiguration des MCP Servers reinschreibt.

00:23:13: Das ist nicht großartig, weil das langlaufende Token sind, die wir eigentlich nicht geil finden.

00:23:18: Ja, absolut.

00:23:19: Aber das ist so die Lösung, wofür sich die meisten behelfen.

00:23:23: Allerdings, wenn du jetzt denkst in einem großen Unternehmenskontext, wo zig User sich Personal Access Tokens generieren müssen, die dann irgendwann ablaufen, nicht machbar.

00:23:34: Eine Chance, ja.

00:23:35: Es gibt einige Sachen, die reichen die Tokens einfach weiter und sagen dann halt dem der Applikation, wenn von dem Server ein Token kommt, dann akzeptiert das einfach, was auch nicht gut ist.

00:23:49: Langfristig, es gibt gerade zwei Erweiterungen des O-Ausstandards, die halt in Richtung Agents tendieren und die dann darauf basieren, dass man Tokens weiter reichen kann.

00:24:03: womit sich dann der Server bei deinem Identity Provider Rechte für dich geben kann.

00:24:09: Also das Szenario gab es bis jetzt halt noch nicht.

00:24:11: Also, wann hat mal jemand in deinem Namen eine E-Mail geschrieben oder die Regierer an Ticket angelegt?

00:24:17: Das war vielleicht mal eine Team-Assistentin, aber die war in der Regel in den aktuellen Strukturen.

00:24:23: Immer hatte sie ihre eigenen Accounts und vielleicht viele Rechte, aber das war bei auch aus bis jetzt noch nicht mitgedacht.

00:24:30: Und zurzeit gibt es halt zwei Erweiterungen.

00:24:32: Also A aus Agent Authentication und von O aus, so eine extension with write propagation, wo du halt Tokens an dein Server weiter erreichen kannst und der Server sich dann wieder, also der MCP Server sich dann wieder beim Identity Provider melden kann und dann wieder Tokens und Refresh Tokens für bestimmte Operationen bekommen kann.

00:24:55: Und solange das eigentlich nicht gelöst ist, haben wir da noch keinen wirklichen, sauberen Weg dafür.

00:25:01: Okay.

00:25:02: Also den einen, der in einem Unternehmenskontext trägt, würde ich mal sagen, weil du halt von den Leuten nicht verlangen kannst, dass sie sich alle paar Monate in Private Access Token bezorgen.

00:25:13: Eine Chance, ja, kleine Chance.

00:25:15: Aber diese Spezifikationen, die sind aktuell in Bearbeitung, also in einem Draftmodus, oder sind die bereit?

00:25:22: Genau,

00:25:23: die sind RFCs, glaube ich, gerade.

00:25:26: Ich hoffe, Octa ist relativ weit vorne.

00:25:29: Die sind da auch ganz treibend bei der RFC gewesen.

00:25:34: Ich hoffe, dass die ersten Implementierungen bald rauskommen.

00:25:37: Für mich ist das eigentlich eine Notwendigkeit, bevor du das groß ausrubst.

00:25:40: Absolut.

00:25:41: Was ich auch noch spannend finde, neben Identifizierung und Autorisierung, dass das auch in den Notes geschrieben ist unter Security, was ist so ein malisches MCP Server, Rack, Pull, also dort erwähnt, welche Gefahren können da noch entstehen?

00:26:01: Welche Risiken sind das?

00:26:02: Ich sage jetzt mal, wenn ich da eine Web-Applikation baue und irgendwie eine Security-Audit habe, dann kommt da relativ schnell irgendwie OWAS, oder du musst dann OWAS befolgen und dann bist du mehr oder weniger safe überspitzt formuliert.

00:26:16: Wie ist das bei diesen ganzen MCP bezogenen Dingen?

00:26:21: Ja, MCP hat verschiedene, also wenn man sich den von externen Quellen besorgt, hat man immer gewisse Risiken, sich Software installieren und gerade den Tokens weiter zu reichen, ist nicht ganz so ungefährlich.

00:26:39: Darum sollte man immer sehr darauf achten, welche MCP Server man nutzt und dass die tatsächlich aus vertrauenswürdigen Quellen kommt.

00:26:46: Mein Tipp ist, es wird irgendwie so in die Richtung von Repositories laufen wie Artifactory oder Nexus.

00:26:53: das für eine Firma dann bestimmte MCP Server freigegeben werden, dass es dann Audit stattfindet, dass man sich das anguckt, dass sie auch wirklich keinen Mist machen und ansonsten halt auch vertrauenswürdige Quellen setzen.

00:27:05: Da hat man halt wieder implizit dieses Injection-Problem, dass sie dem Large Language Model sagen, es soll bestimmte Dinge tun.

00:27:15: und so Large Language Model sind halt darauf trainiert.

00:27:17: in diesem Dialog, dann Dinge auch tatsächlich auszuführen.

00:27:20: Und wenn Sie Zugriff auf dein Pfeilsystem haben, wo hast du ja alle MCP-Server installiert und du willst ja, dass er was für dich macht.

00:27:27: Und dann hat er halt auch Lese-Zugriff auf dein Pfeilsystem und kann halt irgendwelche Passwörter auslesen oder irgendwelche Konfigurationen weiterleiten.

00:27:35: Also immer nur zuverlässige MCP-Server verwenden.

00:27:40: Und Rackpull ist eine Attacke gewesen, wo man die, also Incenturbeschreibung Die Schulbeschreibung sind nicht wirklich gut versioniert.

00:27:50: Also es gibt kein Hashkey zu deiner Schulbeschreibung.

00:27:54: Und was die Leute dann gemacht haben, ist, man fängt mit einem harmlosen Tool an, addiere A plus B und erweitert dann halt die Beschreibung.

00:28:05: Das geht durch den Security Audit durch, weil das alles okay ist.

00:28:09: Und später aktualisiert man den Service.

00:28:11: Es bietet sogar an Hot Refreshes.

00:28:14: dass man das im Lauf aktualisiert, dass man dann lacht, addiere A plus B und liest mir noch die EDC, SSH, RSA, ID aus und packt die mit in den Content rein.

00:28:30: Das ist halt auch so ein Problem von MCP, dass da die Versionierung noch nicht gut gelöst ist.

00:28:34: Es gibt es indirekt, dadurch, dass viele als NPM Packages ausgeliefert werden und Da hat man mit der Package-Lock-Jayzen eigentlich schon eine relativ gute Versionierung, aber da muss man auch darauf aufpassen, dass es ein neuer Angriffsweck war, den wir vor so einem Nicht-Kanten noch nicht gesehen haben.

00:28:52: Ich habe eben das quasi verstanden, dass wir quasi die MCPs hören, wenn wir die z.B.

00:28:59: intern verwenden würden, irgendwo in einem Artifakt oder you name it.

00:29:05: da führen würden dort einen Vulnerability-Check machen und so eigentlich mehr oder weniger auf der sicheren Seite wären.

00:29:13: Ich würde auf jeden Fall nicht zulassen, dass man sich rein, also irgendwelche MCP-Service im Internet installiert, aber gut in den meisten Unternehmen heutzutage ist es eh nicht mehr möglich, sich irgendwelche Software zu installieren.

00:29:25: Klar, klar.

00:29:26: Aber das wäre so eine Sicherheitsmaßnahme für die MCP-Service.

00:29:31: Ja, jetzt haben wir sehr stark über das, ich sage es mal, im Chargot der Softwarearchitektur, über das Qualitätsattribut Security gesprochen.

00:29:40: Gibt es weitere Herausforderungen, die wir haben mit MCP?

00:29:46: Ja, Ausführungszeit ist auf jeden Fall, Latency ist auf jeden Fall ein Problem, was man auch gerade bei seiner Integration beachten muss.

00:29:55: Ich meine, die Architektur ist immer abwägen von verschiedenen Trade-offs.

00:30:00: Und man kann die Integration gerade bei größeren Workflows auf verschiedenen Ebenen machen.

00:30:06: Wenn dir halt Determinismus wichtig ist und eine schnelle Ausführung ist, könnte man halt so higher-level APIs verwenden, die mehrere Calls hinter einer API verstecken.

00:30:17: Wenn dir das halt sehr wichtig ist.

00:30:18: Aber das ist halt wieder Artifakt.

00:30:19: Das muss man halt erstellen und es muss gewartet werden und ... Dafür läuft es schnell und es läuft deterministisch.

00:30:26: Kann aber auch ... Damit experimentieren wir gerade.

00:30:29: Im MCP Server zum Beispiel eine Workflow-Defination in den Ressourcen mitgeben.

00:30:33: ARAZO bietet sich da an das relativ neue Mer.

00:30:37: Es gehört in dem Dunstbereich der OpenAPI-Spezifikation, was einfach eine Workflow-Beschreibung ist.

00:30:46: Was heißt das Workflow-Beschreibung?

00:30:48: BPMN.

00:30:49: Also wenn A dann macht B, wenn ein Fehler-Szenario auftritt, Geh zurück zur Schritt A oder so, da kann man relativ sauber und Maschinen lesbar Workflows mit beschreiben oder halt verschiedene Tool Calls hintereinander.

00:31:06: Das beschreibst du deklarativ dann oder?

00:31:09: Genau,

00:31:10: genau, das ist Jason Arratso.

00:31:12: Sollte man sich mal angucken, ist ein ziemlich cooles Format und das kann man halt zum Beispiel in die Ressourcen des MCP-Servers packen und dann kann man halt relativ schnell Agents raushauen.

00:31:25: indem man halt eine relativ low-Levory, also kurzlastige API nimmt und diese verschiedenen Workflows nur anhand dieser Beschreibung verknüpft.

00:31:39: Der Preis, den man bezahlt, ist, dass es nicht hundert Prozent deterministisch ist und dass es langsam ist, weil die Latency ist.

00:31:47: Es geht halt immer über Late-Language-Models, je nachdem, welches Model verwendet.

00:31:52: bist du immer in der Regel von einer halben bis einer Sekunde, also Latency, die wir bei anderen Systemen in der Regel nicht akzeptieren würden.

00:32:01: Kontextlänge spielt auch noch ein wichtiger Faktor dabei.

00:32:05: Aber genau da muss man sich halt solche Überlegungen machen, wieviel Determinismus braucht man, wieviel Latency ist für dich akzeptabel?

00:32:12: oder entwickele ich nicht doch eher klassischen Codes, so eine höherwertige API und verstecke das alles und mache das mit einem Tool auf Booth.

00:32:21: Was ich spannend finde, ist, dass wir eigentlich die gleichen Themen auch rein aus Software-Architekturarbeit haben.

00:32:28: Oder wir müssen das eigentlich runterbrechen, zum Beispiel Performance.

00:32:32: Was ist akzeptabel?

00:32:33: oder auch für den Benutzerschluss endlich?

00:32:36: Ich habe dir das Eingangs gesagt, ich habe da mal beispielhaft die Google Places API als MCP Server bereitgestellt und ich war schon erstaunt.

00:32:46: wie langsam das war.

00:32:47: D.h.

00:32:48: der Kleint ruft mal auf, welche Tusen sich haben, dann ruft er das Tool auf und daneben kommt quasi der Rapper, der die API aufruft und dann kommt das Resultat wieder, er muss wieder interpretieren und da sind schon einige Suchtkunden raufgegangen.

00:33:02: Im Kontext einer Web-Applikation undenkbar, wie du ausgeführt hast.

00:33:08: Und das ist schon spannend.

00:33:10: Und ich glaube, dort laufen wir neben dem Security eben auch in eine Herausforderung rein.

00:33:15: Definitiv.

00:33:15: Erich Wilder hat tatsächlich auch einen Ex-Inno-Q-Kollege, hat da relativ guter Artikel drüber über die verschiedenen Integrationsmuster von MCP geschrieben.

00:33:24: Wen das interessiert, kann er gerne nochmal nachgucken.

00:33:27: Auf LinkedIn hat er erletzend ein Artikel dazu.

00:33:30: Würde ich sagen, verpacken wir auch in die Show Notes rein.

00:33:33: Packen wir auch in die Show Notes, definitiv.

00:33:35: Was ich mich auch noch gefragt habe, haben wir weitere Herausforderungen rund um MCPs, haben wir Security, wir haben Performance.

00:33:43: Gibt es da noch weitere Attributs?

00:33:46: Wie du schon sagst, damit sie wirksam sind, muss man im Verständnis für den Kontext mitgeben.

00:33:54: Also, dass in der Regel so ein bisschen, wie man das Majority-Model von Rest kennt, hat man auch bei MCP verschiedene Level.

00:34:03: Okay.

00:34:04: Der erste Schritt ist, jemand nimmt erstmal seine API und rappt die in einem MCP Server.

00:34:10: So, das ist Level Neu.

00:34:11: So, das funktioniert auch für viele Sachen schon okay, aber er stellt dann halt fest, wie ich auch feststellen musste, dann kommt man zu einem iratischen Fehlerverhalten, dass er nicht wirklich deinen Kontext versteht und dann mit Try and Error versucht die Aufgabe zu erfüllen, aber meistens mir Dinge kaputtmacht.

00:34:30: Und dann Level zwei ist, du gibst ihm sinnvolle Fehler, also Beschreibung und so Tipps mit in der Description, wenn die Kostenstelle geschlossen ist, lege keine neue an, lösche keine alten Buchungen, um wieder Raum zu verschaffen und so weiter.

00:34:48: Aber das ist halt auch kurz gesprungen, weil mit jeder neuen Fähigkeit, wo er Mist machen kann, müsste man halt bei allen Tools die Beschreibung ergänzen und ihm sagen, tu das nicht.

00:34:59: Und eigentlich Level drei ist, dass wir ihm wirklich was von dem Kontext erklären, dass er weiß, wie unsere Modelle aussehen, Fachmodelle aussehen, was er tun darf, was er nicht tun darf.

00:35:10: Da gehen wir halt so in die Richtung Workflow-Beschreibung.

00:35:12: Und dass man ihm mitgibt, was er in welchen Situationen tun kann.

00:35:17: Und Level vier gehen wir auch so in die Richtung von Hypertext, dass er halt selbstständig weiß, zu welchen URLs ergehen kann oder seine Fähigkeiten selbstständig erweitern kann.

00:35:30: Das war eigentlich auch schon eine der frühen Visionen mit MCP, dass man ein Protokoll hat, womit ihre Agenten ihren Workflow selbstständig weiterentwickeln können, was mit Risiken kommt, auf jeden Fall mit Vorsicht zu genießen sind und auch, wie der Hypertext sich bei REST nie wirklich durchgesetzt hat, sich das auch... Schwierig bei MCP.

00:35:55: Da müssen wir mal schauen, ob das alles kommt.

00:35:58: Schön aufgezeigt.

00:35:58: mit diesem Maturity-Model, bin ich spannend.

00:36:01: Ja, vielleicht ist das auch nach einem guter Übergang.

00:36:04: Ich habe mir gerade die Frage notiert, wie wir als Softwarearchitekten und Architektinnen über so vendorlocking oder eben Abhängigkeiten nachdenken müssen oder berücksichtigen müssen.

00:36:17: Ich sage jetzt mal MCP, okay, ist von OnTropic.

00:36:21: Es wird quasi als der Standard verkauft, aber gehen wir dort nicht irgendwie ein, sagts mal, Vendorlock.

00:36:30: Es ist als offen verkauft, aber auch, was wir gesehen haben, wir haben mit verschiedenen Lad-Language-Modellen experimentiert.

00:36:38: Man sieht eine hohe Schwankungsbreite zwischen den unterschiedlichen Modellen und effektiv haben wir sowas wie ein Vendorlock in, also Proms.

00:36:49: die dafür optimiert sind, mit Antropic-Modellen, also mit Cloud-Modellen zu arbeiten, funktionieren auch am besten mit Cloud-Modellen und mit eventuell noch mit OpenAI-Modellen, weil die beiden sehr high-levelig sind.

00:37:05: Aber wenn man dann auf Dinge wie Mistral runterbricht, was sie eigentlich von der Idee total super finden und total gerne einsetzen würde, sieht man schon deutliche Performance-Verluste.

00:37:17: bei der Ausführung vom Tool und vom Verständnis her.

00:37:21: Also, man geht definitiv in die Richtung, wenn der Lock-in, wenn nicht offiziell, aber dann doch so, wenn man sich die Performance inoffiziell anguckt, ist das ein Risiko, worüber man nachdenken sollte.

00:37:34: Das ist cross-world.

00:37:34: Das ist eigentlich, ich glaube, das beachtet man nicht.

00:37:37: Oder wenn man mit der MCP startet, ja cool, neuer Standort, ich kann da alles integrieren, easy.

00:37:43: Aber das ist man sich, also... Zumindest mir war das überhaupt nicht bewusst.

00:37:49: Wenn wir schon beim Berücksichtigen sind als Software Architekt oder Architektin, wenn du da quasi in einem Kundenprojekt bist, wie gehst du da vor auch fachlich?

00:38:03: Weil es ist ja schon anders, wenn du da mit deinem Kunden in ein Projekt gehst und der sagt, ja, wir haben da Unser System, wir möchten vielleicht irgendeine neue Web-Applikation machen und irgendwie die Systeme quasi mit K einnutzen.

00:38:18: Wie gehst du da vor?

00:38:19: Sagst du ja, okay, du kannst dann alles prompten und dass die Systeme, die Daten kommen, dann sehr einfach quasi in deinen Chat-Pott rein.

00:38:29: Du weißt doch oral, was ich hin will.

00:38:32: Wie gehst du da in einen Kundenprojekt rein?

00:38:35: Meistens muss ich erst mal Herzen brechen, indem ich ihn erzählen muss, dass es nicht alles Magic ist und nicht alles toll funktioniert, sondern wie immer noch gutes Engineering leisten müssen.

00:38:44: Lassische Software-Architekten-Aufgabe herzubrechen.

00:38:47: Ja.

00:38:49: Dann ganz wichtig ist, dass man messbar bleibt.

00:38:53: Also erst mal strecken wir den Fokus ab.

00:38:56: Was ist securitymäßig überhaupt vertretbar?

00:38:58: Was kann man machen?

00:39:00: Dann ganz wichtig ist, dass man messbar ist, dass man halt auch nicht wirklich an so ein Prompt einfach rumschraubt, sondern man sich vorher ein Test überlegt, eine Metrik, was auch immer, aber sonst sind wir halt nur Frickler.

00:39:14: Sonst, wenn wir da nicht ständig messen können, wie die Verbesserung aussieht, wie das Ergebnis aussieht, standardisierte Tests ist glaube ich ganz wichtig, wie jedes AI-Projekt, das man zu Ergebnissen kommt.

00:39:27: Ansonsten dadurch, dass wir jetzt eigentlich schneller sind als früher, würde ich auch mit einem schnellen Start.

00:39:34: Sag ich eigentlich immer, lass schnell starten.

00:39:37: Wir brauchen weniger Wochen als früher und dann halt das Klassische, was man kennt, iterativ entwickeln.

00:39:43: Und das funktioniert halt nur, wenn man sich am Anfang über halt irgendwelche Tests und Qualitätskriterien Gedanken macht.

00:39:51: Sonst ist es halt Engineering, wie wir es auch kennen.

00:39:54: Also jetzt vielleicht schneller, wie gesagt, mehr aufs Testen achten und die Sicherheit und die Guardrails nicht vergessen.

00:40:03: Wenn wir hier zum letzten Punkt kommen, Ausblick.

00:40:07: Ich habe da so ein Gedanke, ich weiss gar nicht, woher ich den habe.

00:40:12: Einfach so als Gedanke, glaube ich, hat das mal mit den Kollegen diskutiert.

00:40:16: So, wenn sich jede Kai mit jedem Tool verbinden kann, was bedeutet dann wirklich Software noch?

00:40:23: Das ist dann wenig philosophisch, aber das weißt du, wo ich hin will, oder haben wir in Zukunft noch mehr Applikationen, wenn wir?

00:40:31: oder Applikationen generell, wenn wir das eigentlich über AI machen.

00:40:37: Ich glaube eher, dass wir mehr Software haben.

00:40:40: Wir dürfen KI nicht als den Golden Hammer sehen, wie er jetzt gerne von vielen gesehen wird.

00:40:46: Es bietet uns Fähigkeiten, die wir vorher nicht hatten und diesen großartig.

00:40:50: Also gerade das Software-Umgehen mit Dingen, also die Interpretation von PDFs.

00:40:56: die Interpreter der Umgang mit irgendwelchen Dokumenten, Berüchen, der Umgang mit Longtail-Problemen.

00:41:03: Wir müssen nicht mehr ewig lange Rack-X schreiben, um alle möglichen Longtail-Probleme abzudenken, sondern jetzt haben wir mit AI tatsächlich ein Tool, was das für uns machen kann und was mit ein bisschen Fingergespitzengefühl agieren kann.

00:41:16: Auf der anderen Seite dürfen wir auch nicht vergessen, was wir vorher schon hatten.

00:41:20: Also Performance, Security, Determinismus, das sind ja alles Dinge, die wir auch weiterhin... für ganz viele Dinge haben wollen.

00:41:28: Und da sehe ich eher AI als Enabler.

00:41:31: Das wird schneller Software schreiben als früher.

00:41:34: Aber ja, die Kriterie, also das wird nicht weggehen.

00:41:37: Diese Constrains haben wir immer und die werden immer sinnvoll sein und die alles jetzt KI zu übergeben, halt ich bin nicht sinnvoll.

00:41:47: Das heißt, eher mehr, aber quasi einfach integriert quasi in eine, sagen wir mal, AI.

00:41:56: keine unterstützten Systemlandschaft irgendwie so.

00:42:00: Okay, ich habe mich noch notiert.

00:42:02: Jetzt haben wir viel über das MCP-Protokoll gestartet und ich bin überzeugt, dass die eine Hörerin oder der eine Hörer gar noch nie mit dem MCP gestartet oder etwas gemacht hat.

00:42:15: Was empfiehlst du ihm, mit dem MCP zu starten?

00:42:20: Was braucht er, um mit dem MCP starten zu können, vielleicht auch mit in seine Unternehmung zu nehmen, Vorteile aufzuzeigen und so weiter?

00:42:29: Ich würde klein beginnen.

00:42:32: Also jetzt nicht versuchen gleich, einen Multi-Agent-Frame-Work aufzubauen.

00:42:40: Gestern gab es von Franz War-Schollet auf X einen Kommentar, dass es mittlerweile mehr Agent-Frameworks als funktionierende Agent-Inflementierung gibt.

00:42:49: Wo ich sogar zustimmen würde, dann könnte er recht haben.

00:42:54: Ja, sie sind besonders stark drin, die kleine, nervige Aufgaben abzunehmen.

00:42:58: Also in meinem Fall Zeiterfassung oder der Kunde überlegt sich, wir buchen das dann doch alles auf eine Kostenstelle rum und auf einmal muss man Fünfzig Buchungen anfassen.

00:43:08: Den Dingern wird nicht langweilig.

00:43:11: Die ändern deine Fünfzig Buchungen, wenn du ihn genau sagst, wie.

00:43:15: Also sie sind besonders gut irgendwie, also zumindest im Anfang sind sie besonders gut, nervige kleine, repetitiver Aufgaben, die abzunehmen, die dich immer schon genervt haben.

00:43:25: Damit würde ich mal drüber nachdenken, ob man da irgendwelche Pain Points hat.

00:43:29: Und ja, Human in the Loop ist immer noch wichtig, man muss die beaufsichtigen und mit was kleinem anfangen.

00:43:37: zeigen, welche Mehrwerte es bringt und dann überzeugt man die Leute auch schon.

00:43:40: Ich bin ein cooler Ratschlag, auch wenn ich sage, okay, ich bin irgendwie Enterprise-Archidekt und ich muss irgendwie auf meinem Technologieradar, das MCP, drauf klein anfangen.

00:43:53: und dann, wenn es sich vielleicht an einem Ort, wo jetzt nicht so risikobehaftet ist, sich etabliert, sich als wertvoll erachtet, dass man es dann weiter... quasi ausbreitet für weitere Applikationen oder so in diesem Stil.

00:44:12: Definitiv.

00:44:13: Man hat auch selber eine Lernkurve immer drin.

00:44:15: Also weil man mit so einem Problem, man muss immer betrachten wie so ein Assistenten, der neu in die Firma ist, der zwar alle Bücher gelesen hat, der aber nicht weiß, wie deine Firma funktioniert, der nicht genau die Constraints weiß und er ist halt sehr motiviert und versucht immer irgendwie, dass er einen Auftrag auf kreative Weise zu erfüllen.

00:44:34: Das sind so Fehler-Szenarien.

00:44:37: Darauf muss man erst mal eingehen.

00:44:38: Die hat man vorher so noch nicht gehabt.

00:44:40: Das hat mich selber auch immer wieder überrascht, wie kreativ er versucht, Lösungen zu finden, wenn ich ihm bestimmte Dinge verboten habe.

00:44:47: Wo ich denke, nein, das ist nicht das, was ich heute so ...

00:44:52: Ich finde das schön, wie du es gesagt hast, oder eben wie als Assistent da rein gehen in dieses Thema.

00:44:57: Und ich glaube, das gilt für einen persönlich, wie auch für die Unternehmung selbst, oder dass man da einen kleinen Anfang, Erfahrungen sammelt, sieht, was funktioniert, was nicht funktioniert und so dann entsprechend iterativ weitergeht.

00:45:17: Super spannende Insights Ole, muss ich wirklich sagen hat.

00:45:21: die einige Augen öffnet und die Zeit verfliegt wie im Flug.

00:45:26: Also wir sind jetzt schon drei Viertelstunden über das Model-Context-Protokoll am Sprechen und Diskutieren.

00:45:33: Und ich denke, wir haben die wichtigsten Elemente erwischt.

00:45:37: Weiß nicht, wie du das siehst.

00:45:39: Hast du doch Ergänzungen oder deine Sicht auf den Podcast oder die drei Viertelstunden?

00:45:46: Also vielleicht, wenn ich noch was mitgeben kann, auch wenn ich teilweise vielleicht ein bisschen... Defluenced habe und negativ klang ich glaube ist es schon wichtig sich damit zu beschäftigen.

00:45:56: und auch wenn das mcp Protokoll technisch dadurch dass es date voll ist.

00:46:01: Halt ich es noch nicht für das perfekte Protokoll aber an dem fachlichen Prinzip glaube ich ist was dran und ich glaube es ist gut wenn wir jetzt beginnen uns damit zu beschäftigen weil es wird so viel Geld gerade in investiert.

00:46:15: und ja es ist eine bubble die.

00:46:19: eines der großen Probleme mit large language models ist es wird ja mal so jagged edge auf capabilities genannt.

00:46:25: das ist ganz schwer ist vorher zu sehen woran sie es gut sind und wo sie nicht so gut sind.

00:46:29: und das ist dass sie teilweise genial sind oder teilweise Doppelfehler machen auf die kein Mensch reinfallen wird.

00:46:37: und so wird glaube ich auch die bubble platzen irgendwann von ai.

00:46:40: es wird nicht einfach pop machen sondern auch die wird jagged platzen.

00:46:44: also einige dinge werden sich als sinnvoll herausstellen.

00:46:48: Und gerade bei diesen Investitionen, damit sich das alles lohnt, müssen sie Aufgaben langfristig uns abnehmen können.

00:46:54: Also deine Textmonster können sie nicht bleiben.

00:46:57: Darum glaube ich schon darauf, dass Agents und Aufgaben ausführen, ein zentraler Bestandteil von AI werden wird.

00:47:05: Und darum ist es gut, sich rechtzeitig damit zu beschäftigen.

00:47:11: Vielen Dank für diese coolen Insights.

00:47:14: Ich denke, der Podcast und diese Folge gibt echt mehr Wert für unsere Hörer und Hörerinnen im Heises Software Architektur Podcast.

00:47:23: Und wir können mit diesem Schlusswort entsprechend schließen.

00:47:28: Ich wünsche allen schönen Abend.

00:47:30: Tschüss!