Stefan: 0:09

Hallo und herzlich willkommen zu Coffee Code Consult. Ihr habt es alle mitbekommen, wir haben KI. KI kann richtig coole Dinge vollbringen, wahre Wunder teilweise. Wenn man nur den richtigen magischen Prompt hat und dann die KI noch irgendwie einen wohl definierten Zugang zu IT-Systemen und dann zack hier hast du deine Antragsstrecke die genau so aussieht wie in Figma im Designsystem definiert oder du kannst einfach deinen Backpacking-Urlaub planen und bucht dir direkt alles, was du dafür brauchst. Naja gut, damit es halt funktioniert, brauchst du diese wohl definierten Zugänge. Und da hat sich in letzter Zeit MCP, Model Context Protocol, so ein bisschen als Standard behauptet Und jetzt hat sich mir tatsächlich die Frage gestellt, was ist denn Model-Kontext-Protokoll überhaupt? Und damit starten wir rein. Mein Name ist Stefan Groß. Ich bin angehender Architekt bei GoFindPro und bis jetzt ist KI jetzt nicht so das, mit dem ich mich alltäglich beschäftige. Ich bin da eher so ein bisschen zurückhaltender unterwegs, sowohl im privaten als auch im Arbeitsalltag und bin dann eben genau über solche Probleme gestolpert. Und deswegen sitzt hier neben mir der liebe Benjamin Tenkel. Ein Senior-Architekt bei Unterkofen Pro, der sich mit dem Thema schon intensiv beschäftigt hat. Und mir hoffentlich alle Fragen zu MCB heute beantworten kann. Hallo Benjamin, schön, dass du da bist.

Benjamin: 1:31

Hi Stefan, schön hier zu sein. Freut mich. Und bei diesem ganzen Thema Model-Context-Protokoll, weil du es schon vorhin gesagt hast, dass es ein Standard ist, habe ich auch überlegt, wie steige ich da überhaupt ins Thema ein? Weil ich glaube, bevor wir überhaupt über Model-Context-Protokoll sprechen können, müssen wir erstmal einen Schritt zurück machen und darüber reden, was Agents sind. Und... Bevor wir darüber reden was über einen Agent ist, habe ich mir überlegt naja, man muss auch verstehen, wie es sich dahin entwickelt hat. Also ganz am Anfang, wenn du dich erinnerst, TGPT kam raus, man hat einfach eine Box, wo man was reinschreibt. Ja. Dann antwortet die KI eine mit Text, das heißt Text in, Text auch. Man einen Input, man hat einen Output. Mehr konnten die auch nicht. Also ich meine, man hat keine Inbindung gehabt, nichts. Die waren relativ, Anführungszeichen dumm Da

Stefan: 2:17

kommt ja auch dieser Begriff Conversational AI her, nehme ich an.

Benjamin: 2:21

Ja, genau. Das war so der Anfang an der großen Hype. Dann wurden die Dinger ein bisschen smarter Was ist passiert? JGPT hat gesagt, okay das ist natürlich schlecht, dass das Model nur auf Daten von 2022 trainiert wurde. Vielleicht bräuchte man auch irgendwie noch Access zum Internet, dass man halt irgendwie Daten aus dem Internet reinbekommt. Das war so die nächste Ausbaustufe, dass Tools, dass diese ganzen Anbieter wie JGPT oder Terminal oder Cloud auf ihren Web-Oberflächen im Hintergrund noch irgendwelche Tools vor ihren LLMN eingebunden haben. Um diesen Input anzureichern mit zusätzlichen Informationen, damit dann die Antwort von dem Element halt wahrer war oder mehr zu dem gepasst hat, was ich halt wollte.

Stefan: 3:03

Das heißt, meine KI... Ist jetzt hingegangen und hat dann einfach eine Google-Suche gemacht, so wie ich es auch machen würde, zu dem, was sie gedacht haben, das sinnvoll ist und hat dann das mit angeweichert an der Formation. Genau, und da muss

Benjamin: 3:16

man aber richtig verstehen, das Modeln macht das nicht, sondern da hat einfach, zum Beispiel jetzt um bei JGPT zu bleiben, da hat halt OpenAI einfach ein Stück Software Beschrieben was zwischen deinem Chat-Interface und dem Model sitzt und diese Suche im Internet macht und diese Daten da rauszieht in dieses Kontextfenster reinwirft, also diesen Input fürs LNN und dadurch... Kannte er plötzlich diese Information, die du benötigt hast. Aber das Modeln selber hat sich nie geändert. Also es ist bis heute auch gleich geblieben

Stefan: 3:45

wie die funktionieren. Da nur kurz, um die verschiedenen Begrifflichkeiten einzuordnen wir sprechen von KI beziehungsweise AI. Dann hast du jetzt schon zweimal LLMs, Large Language Models, erwähnt und von Agents. Nur diese drei Begriffe kurz einzuordnen... Dass wir sie gleich benutzen und ein gleiches Verständnis haben. Sind die Deckungsgleich oder wo ist da kurz die Differenzierung?

Benjamin: 4:07

Genau, da wollte ich gerade hin, was dieser Agent ist, weil das Large Language Model ist ja genau, am Ende ist es ja eine Vorhersage von den wahrscheinlichsten Text- oder Antwortmöglichkeiten auf deine Eingabe. Das ist ja ein bisschen kompliziert zu erklären, wie Large Language Models genau funktionieren, aber das wird so in der KI als, Modeln bezeichnet. Und das ist eigentlich in der Ansicht die Intelligenz dahinter. Das ist die, die mir antwortet Wenn ich nichts angebunden habe Die generiert den Output. Und was sich jetzt geändert hat, also ich habe jetzt Stufe 1 war Input-Output, Stufe 2 war Input-Tools plus Output und so die Stufe 3, wo wir gerade sind, würde ich sagen, ist so die Ära der Agents und Agent ist nichts anderes, als dass man... Wie ich es vorhin schon angeteasert hatte, Stück Software vor dem Model hat. Und dieses Stück Software hat den einzigen Sinn, diesen Input, den du zum Model gibst, mit Informationen anzuweichern oder zu verändern. Und so ein Agent, meinst, sagen das, es gibt keine einheitliche Definition Aber viele sagen, man kann es sich wie eine While-Schleife vorstellen. Es ist einfach ein Stück Software, das endlos läuft, bis es eine Kondition erreicht hat, wo man sagt, okay, es hat zum Beispiel ein Ziel erreicht. Viele sagen, Agents sind autonom, erfolgen Ziele. Also man gibt einem Agent ein Ziel und es erfüllt das eine. Also so kann man es für jemanden erklären, der jetzt nicht so in der Softwareentwicklung ist. Aber für einen Softwareentwickler würde ich sagen, es ist eine While-Schleife, wo viele Ifs Bedingungen drin sind. Wo die Software durchläuft und dann einfach immer wieder prüft, hey, ich habe ein State, also ich schicke was zum LLM, er kriegt eine Antwort, die Antwort wirft er wieder in seinen State, überlegt was mache ich als nächstes ruft vielleicht noch irgendwelche Tools auf, um irgendwas zu erledigen, auf Dateien zuzugreifen, E-Mails zu verschicken, irgendwie auf den Kalender zuzugreifen, was auch immer man als Tool angebunden hat in diesem Agent. Und das ist halt die Software, dieser Agent, was man selber schreibt vor dem LLM. Was aber immer passiert ist, dass dieser Agent... Zum Model was schickt und eine Antwort vom Model bekommt. Und das macht er in Schleife so

Stefan: 6:09

lange, bis er sein Ziel erreicht hat. Das heißt, ich habe hier so meinen Agent vor allem davor, der spricht dann mit meinem Large-Language-Model, dem LLM und das hat theoretisch auch noch Zugriff auf mein Dateisystem, auf das Internet in irgendeiner Form, auf zusätzliche Tools, wie du gesagt hast. Und dieses Dreigespann Agent, LLM und Tools, die zusammen machen dann das warum... Eine KI wie JGPT heutzutage sich schon fast anfühlt wie ein Mensch, wenn man damit redet. Genau.

Benjamin: 6:37

Und vor allen Dingen bei JGPT momentan hauptsächlich dieses Conversational Interfaces, Conversational AI. Aber ich Code ist ein gutes Beispiel für diesen Agent, den die meisten kennen, weil dem kann man einfach sagen, tu das. Und der macht das dann, versucht das zu erreichen, welche Aufgabe du gegeben hast. Und der antwortet halt nicht nur mit Text, sondern der führt wirklich Aktionen aus, autonom und trifft auch Entscheidungen. Wohingegen das beim Conversational Interface halt nicht heißt, da kriegst du immer nur Text zurück. Genau. Und diese Agents, die gab es die gibt es schon länger, die gibt es glaube ich schon über ein Jahr, haben ganz am Anfang auch Leute einfach, wie gesagt, es ist halt einfach eine Software for the model, angefangen diese zu bauen. Und diese ganzen Tools, die man angebunden hat, weil klar kann ich jetzt in einem Agent sagen, ich möchte jetzt mit der Google Kalender API, der Microsoft Outlook API sprechen, um E-Mails um meinem Agent zu ermöglichen meinem Element E-Mails zu verschicken oder auch E-Mails abzurufen, diese wieder in den Kontext zu werfen, sodass das Element weiß, was in meinen E-Mails drin steht und darauf basierend mir Antworten geben kann. Kann man dann machen, also dass man es jedes Mal, jeder, der ein Agent baut, dieses Tool selbst anbindet oder wie alle wissen, so eine Integration von einem Drittsystem, das ist immer mit Herausforderungen verbunden, das ist immer ziemlich aufwendig das herauszufinden und Ja, das ist halt ein Standardproblem, Integration von Drittsystemen

Stefan: 7:58

Gerade wenn es auch solche Standardsoftware sind, wie eben die Mail-Anbindung, wie eben eine Internet-Anbindung und so weiter und so fort. Genau. Die man auch wirklich in einiger Ansatzweise templatisieren, standardisieren oder sonst irgendwas kann. Natürlich nicht, wenn ich jetzt mein eigenes Deckern anbinde, nehme ich an von irgendeiner Software die ich entdecke. Genau. Wobei das

Benjamin: 8:17

kann man auch in MCP... in erster Linie ist NCP ein Standard Für diese Tool-Anbindung, weil die Leute dann irgendwann gesagt haben, sie wollen halt nicht jedes Mal das Rad da neu erfinden, sondern einfach diesen Standard schaffen, wie Tools in Agents eingebunden werden. Also man kann es so formulieren, das Hauptziel von MCP ist es, die Kommunikation zwischen KI-Modellen und externen Systemen also Tools, Datenbanken und APIs und anderen Datenquellen zu standardisieren. Damit dann nicht jedes Mal diese Integration von Neuem von jemandem erfunden werden muss. meine, dafür sind ja auch Frameworks entstanden, dass man nicht immer wieder die gleichen Probleme löst.

Stefan: 8:57

Und nur um da die Schnittstelle nochmal zu definieren, MCP ist dann an der Schnittstelle zwischen meinem LLM und den Tools die angebunden werden, oder hat MCP irgendwie mit dem Agenten zu tun? MCP hat

Benjamin: 9:09

mit dem Agenten zu tun. Deswegen ist es hauptsächlich auch in diesem Agentic AI, in der Verwendung, weil man diesen Agenten halt ermöglicht Tools zu nutzen, um wirklich Aktionen auf dem Rechner oder in der realen Welt auszufüllen. Das ging halt vorher einfach nicht. Also es geht, auch ohne NCP, aber da muss man es halt selber schreiben. Mit NCP wird es einfach deutlich vereinfacht. Es löst halt dieses End-zu-End-Problem, dass man ganz viele Leute hat, die dieses Tool nutzen möchten und jeder das halt selber implementieren müsste. Gibt ja viele Frameworks, die solche Probleme gelöst haben. Aber vielleicht steigen wir kurz in den MCP auch ein, auch so architektonisch dass man ein bisschen versteht okay, was kann das so, was definiert denn dieser Standard, damit man vielleicht noch ein bisschen Verständnis bekommt, was das wirklich

Stefan: 9:55

tut. Ganz kurz, bevor wir einsteigen um das einzuordnen MCP, wir reden die ganze Zeit davon, als wäre es ein Standard, aber es ist ja nicht von irgendeinem Konsortium definiert als Standard USB oder sonst was, sondern wenn ich das richtig verstanden habe, dann ist MCP von einer Firma entwickelt worden, von Anthropic in dem Fall und die sind einfach nur so, die haben so einen guten Job gemacht oder sind so populär zumindest, dass es der de facto Standard geworden ist richtig? Ja

Benjamin: 10:23

Ja genau, es gab noch andere Bestreben aber die haben sich durchgesetzt. Also OpenAI hat es adaptiert, Google hat es in Gemini adaptiert, also die ganzen großen Anbieter sind auf den Zug aufgesprungen, die halt auch diese ganzen KI-Modelle so in der Breite machen und dadurch ist es zum de facto Standard geworden. Entwickelt sich alles dahin dass ich meine, selbst vorwegzunehmen, die die am OAuth-Standard arbeiten, haben eigene RFCs mittlerweile geschrieben oder Anpassungen von diesem OAuth-Spec nur für diesen MCP-Use-Case. Und ich glaube, damit kann man schon sagen, es hat einen gewissen Einfluss

Stefan: 11:02

Das auf jeden Fall. Ich wollte nur das einordnen, damit nicht irgendjemand denkt, okay, ich lade mir jetzt hier irgendwo die Definition dieses Standards runter, so wie ich es bei USB halt zum Beispiel machen könnte, sondern es hat sich nur etabliert und es mag für mehr oder weniger.

Benjamin: 11:15

Genau, in dieser Agent-Welt würde ich sagen, hat es sich neben anderen Protokollen wie Agent-to-Agent-Communication-Protokoll gibt es noch oder Agent-to-Agent-Protokoll. Die löst dann die Problemstellung, wenn Sie mir die Namen sagen, die beiden sind jetzt eher, wenn... Zwei Agenten miteinander reden möchten. Dann gibt es noch Agent-to-Human-Protokoll, weil ein Agent mit einem Menschen sprechen wollte. Und MCP ist das Protokoll wenn ein Agent mit Tools sprechen möchte. Und da kann man sich das vorstellen, also es gibt momentan so diese drei Richtungen, einmal mit Menschen, einmal Agent mit Agent und einmal Agent mit Tools. Gut, dann steigen wir vor den MCP an. Genau. Bei MCP man muss mal auch Begrifflichkeiten klären, also ich würde auch jetzt nicht zu tief sagen In die Gesamtarchitektur einsteigen. Ich glaube, so auf die wichtigsten Bestandteile von MCP eingehen die man gehört hat. Dann können wir vielleicht eher noch über Use Cases oder auch so, wie es im Enterprise-Kontext heute werden reden. Der MCP-Host ist so als Begriff etabliert Kam jetzt auch erst seit ein, zwei Monaten neu in der Spec. Ein MCP-Host ist zum Beispiel die IDE. Also IntelliJ, Visual Studio Code oder Cloud Code könnte als Host dienen. Und so ein Host tut in der Regel einen MCP-Client initialisieren und irgendwo gibt es einen MCP-Server. Der Client verbindet sich mit diesem MCP-Server, die reden miteinander und die Kommunikation mit den beiden ermöglicht es, dass die Funktionen dieser MCP-Server zur Verfügung stellen, vom Client konsumiert werden können. Die Clients sind meistens wenn man jetzt nicht gerade eine IDE baut oder einen Agent baut, muss man sich mit dem Client normal nicht beschäftigen. Wenn man natürlich einen Agent baut, braucht man auch den Client. Die meisten Leute sind eher so auf dieser MCP-Server-Seite und die Server entwickeln. Damit du zum Beispiel einfach, wenn du so einen Server entwickelst den Cloud-Code einbinden kannst und direkt nutzen kannst. Das sind so die drei grundlegenden Bausteine. Das ist der MCP-Host, der MCP-Client und der MCP-Server. Die Die Architektur beschränkt sich bei denen, die haben so ein Zwei-Layer-System, die haben so ein Data-Layer, einen Transport-Layer. Der Spec, die haben sich entschieden, im Data-Layer JSON-RPC zu verwenden, also JSON Remote Procedure Codes. Das sind Methodenaufrufe um in JSON-Format halt Daten übertragen werden. Warum haben sie sich dafür entschieden? Die wollten halt den Transport-Layer bewusst so halten, Protokoll-Agnostik ist, dass du verschiedene Sachen verwenden kannst, dass du jetzt nicht HTTP gebunden bist, sondern auch andere Sachen verwenden kannst. Genau, das ist so der Inner-Layer, der Data-Layer, dann gibt es den Transport-Layer. Wie gerade geteasert, es gibt nicht nur HTTP, sondern es gibt auch Standard In-N-Out, das ist, wenn der MCP-Server lokal auf deinem Rechner läuft und der Client, dass die dann einfach Inter-Prozess-Kommunikation machen können, hat man kein Netzwerk-Overhead. Ja. Das heißt, wenn man das nur lokal alles aufsetzt, kann man das nutzen. Wenn es ein Remote-MCP-Server ist, der Begriff hat sich etabliert Also nicht wundern wenn jemand von Remote-MCP-Server spricht, heißt das meistens nur, dass dieser MCP-Server irgendwo im Internet, in der Cloud, irgendwo gehostet wird und der Client per HTTP mit dem Server spricht.

Stefan: 14:19

Ganz kurz vielleicht an der Stelle nochmal zur Einordnung. Dieser MCT-Server ist tatsächlich ein in Anführungszeichen physischer Server oder eben auch in der Cloud oder auf meinem lokalen Rechner. Zu dem ich mich verbinden kann und der dann dafür sorgt, dass ich Zugang zu diesem Tool bekomme. Genau. In irgendeiner Form. Also wenn wir zum Beispiel Google Kalender nehmen, dann gäbe es diesen MCPServer Mit dem verbinde ich mich in irgendeiner Form und der koordiniert den Zugang zu meinem Google-Kalender und schickt mir dann potenziell die Informationen so zurück, dass ich sie weiterverarbeiten kann und damit an meinen Agenten in irgendeiner Form anbinden kann.

Benjamin: 15:00

Genau, weil dieser MCP-Server spricht einfach, ich würde es so einfach ausdrücken, also stark vereinfacht die Sprache von den Large-Language-Models und ist einfach gut kompatibel mit Mit diesen Agents und übersetzt so ein bisschen Richtung der API, wenn es jetzt zum Beispiel eine REST-API ist und macht dann die Calls Richtung der Google-Kalender-API im Auftrag vom Client. Formt es nochmal um in eine andere Art von Response, mit der ein LLM halt besser umgehen kann. Und das ist dann der Riesenvorteil.

Stefan: 15:29

Und der Client der ist dann potenziell dort, wo auch eben mein Agent ist, damit mein Agent auf diesen Client zugreifen kann. Das heißt, dieser Agent Agent ist in dem Fall auch der MCP-Host in der Regel. Okay. Das heißt, mein Agent würde auch über diesen Client mit dem Server entsprechend reden. Das heißt, wenn er beschließt okay, ich will jetzt gerne mit dem Google-Kalender reden, dann sagt er, hey, lieber Client, bitte sprich mit dem Server, krieg die Informationen zurück, der Client gibt sie wieder an den Agenten alles ist fine.

Benjamin: 15:55

Genau. Und wenn einmal so ein MCP-Server jetzt gebaut wurde für einen Google-Kalender weil wir vom Standard sprechen, dann der irgendwo gehostet wird, Wenn man Zugriff darauf hat, können halt beliebig viele Clients sich damit verbinden und damit arbeiten. Und auf kleinen Seite ist das einfach nur ein Config-Eintrag. Also es kommt darauf an, wie man das natürlich implementiert, aber bei Cloud Code ist das zum Beispiel eine JSON-Datei ein Einzeiler oder ein kleines Objekt, was man da einträgt und zack ist man an den MCP-Server angebunden.

Stefan: 16:22

Und der letzte Punkt, in diesem Dreigespann der MCP-Host, da hattest du ursprünglich Beispiele genannt mit IntelliJ, Cloud Code und so weiter, das sind ja meine IDIs. Heißt das, dass mein Agent immer zwangsläufig irgendwie in meiner IDI laufen muss oder wie darf ich das verstehen? Agenten können auch in

Benjamin: 16:41

der... Cloud gehostet werden. Das war nur ein Beispiel. Also die Agenten sind meistens integriert heutzutage in IDEs, aber ein Agent ist ja nichts weiter wie ein Softwareprogramm Also ich kann mit Spring oder auch wenn man in der.NET-Welt kommt, was irgendwas Enterprise oder auch in Python, ein Programm schreiben, was als Agent funktioniert. Das ist erstmal nur ein Softwareprogramm.

Stefan: 17:02

Das heißt, also ich könnte jetzt eben auch, wenn ich ein Stück Software entwickle, was meine Nutzer dazu Für eine Raumbuchungssoftware zum Beispiel irgendwie nutzen wollen, dass jemand einfach sagt, hey hier, ich würde gerne einen Raum für 20 Leute in Frankfurt buchen, dann könnte ich da hinten einen Agenten in irgendeiner Form ansprechen, der sich darum kümmert dass diese Buchung auch tatsächlich passiert und der dann den Nutzer zurückmeldet, ja, hat funktioniert oder nein, ist kein Raum frei, sucht was anderes. Genau so in Art. Und dieser Agent kündigt MCP. Und

Benjamin: 17:33

dann mit diesem MCP-Server sprechen und der macht dann die Aktion gegen die API, wo auch immer dann diese Buchungen stattfinden. Super. Hast du richtig verstanden. Was man noch wissen muss, Der Client und der Server, das ist, glaube ich, Interessanteste, um auf einer gewissen Flughöhe zu bleiben, auch für alle, die das auch eben benutzen möchten, die haben verschiedene Capabilities, also Fähigkeiten. Ich werde auch ab und zu das übersetzen, weil ich will auch immer die Fachwörter verwenden, die so typischerweise verwendet werden in der Spezifikation. Der Server, was kann er? Das Wichtigste, die Tools. Da erklärt der Server, hey, Das sind die Capabilities, die ich habe, das Lieber-Client kannst du von mir erwarten und nutzen. Dann steht meistens in Form von einer ID drin, okay, Kalender lesen Kalender-Event eintragen um bei diesem Google-Kalender-Beispiel zu bleiben. Und mit einer Beschreibung für das NLM, wo der NLM versteht okay, diese ID... Was bedeutet das? Also wenn der Client das nutzen würde, was hat das LLM dann zu erwarten? Also es wird nicht für Menschen beschrieben, sondern wie man das am besten halt einem Model geben würde, damit es damit arbeiten kann. Das ist in meinem Hinterkopf. Neben den Tools, also wie gesagt, das Wichtigste sind ja die Aktionen die dann der Agent damit machen kann, gibt es noch Resources und Prompt. Resources ist so ein Sammelbecken, so ein Sammelsugium, da kann man alles reinwerfen. Das sind alles nur Informationen, die man am Ende will, dass die vielleicht in den Kontext landen Und dann sagt er, für bestimmte Tools wäre es ganz gut, wenn er diese Resources mit in den Kontext wirft Wie gesagt, Kontext ist für

Stefan: 19:06

mich auch immer gleich mit dem Input für das Model. Das würde also bedeuten, wenn ich es in der Softwareentwicklung benutze, in meinem IntelliJ zum Beispiel, dass ich dann meine Code-Basis als Kontext quasi mit reinwerfen geben kann, damit die neu entwickelte Software oder der neue Vorschlag für eine Softwareverbesserung der von dem Alienten zurückkommt, dass der sich dann auch möglichst nah vielleicht an meiner schon existierenden Software orientieren kann

Benjamin: 19:29

Und auch so ein Resource, zum Beispiel kann man noch sagen, was könnte so ein Resource sein? Das ist zum Beispiel ein Datenbankschema. Also wenn man ein Tool hat, einen MCP-Server, der Datenbanken anbindet, könnte ein Resource das Datenbankschema einfach sein, das darüber direkt in den Kontext geladen wird. Die Prompts sind einfach vordefinierte gute Prompts, die der Client nutzen kann, die einfach vordefiniert sind, die dem User angezeigt werden können, die dann auch schlussendlich irgendwo in den Kontext landen. Liegt natürlich im Steuerung des Clients, je nachdem wie die UI aussieht wenn es eine UI gibt. Das ist die Serverseite was der Server zur Verfügung stellt. Der Client, das ist auch relativ neu, mittlerweile kann der auch einiges. Der Client kann zum Beispiel Sampling machen. Das ist eines der wichtigsten Features, weil man will ja zum Beispiel nicht den MCP-Server nochmal ein Model anbinden, damit auch der MCP-Server irgendwie die Chance hat, mit einem Model zu integrieren und darüber halt irgendwelche Aufrufe zu machen. Also selber sozusagen als Agent zu fungieren. Das heißt, man hat diese Funktion gemacht, der Server kann den Client fragen, hey Client, kannst du bitte mal das Model aufrufen mit diesem Input und mir den Response wieder geben, damit ich weiterarbeiten kann. Das heißt, damit kann man auch Abrechnungen leisten. Machen oder das heißt zumindest der, der Kleine der den Aufrufe macht, die Kosten auch vom Model trägt oder auch die Anbindung an das Model macht und dem Server das egal ist, der kann den Kleinen dafür nutzen und hat dann trotzdem Zugriff auf den Model.

Stefan: 20:51

Okay, das würde aber bedeuten dass ich diesem Server auch vertrauen muss. Dass der Server nicht einfach irgendwelche Sachen gegen mein Model macht. Also werden wir wahrscheinlich nachher noch drauf eingehen. Genau, das ist ein sehr

Benjamin: 21:02

guter Punkt, auf den ich später noch zu kommen will. Genau, Vertrauen ist ein großer Punkt bei Elastic-Keys weil der könnte ja irgendwas hinschicken mit einem bösen Intent und kommt was zurück, um vielleicht irgendwie Daten abzuhalten. Ja, genau.

Stefan: 21:14

Oder mal in der rechten Leistung zu benutzen um selber Dinge zu tun. Muss ja erstmal nur, muss ja noch nicht mal direkt aktiv fühlswillig sein, sondern einfach nur einen großen Clown in Anführungszeichen. Stimmt das ist auch eine Gefahr.

Benjamin: 21:24

Das zweite ist Allocation. Das ist einfach nur, dass der Server den Client fragen kann, hey, kannst du dem User bitte um Input bitten? Also dass er sagt, wenn es ein UI gibt, dann wird die Implementierung irgendwie sagen, hey User, hier brauche ich gerade eine Eingabe von dir. Ist auch manchmal hilfreich wenn halt Multi-Step hast, im Hintergrund was passiert und du brauchst einfach nochmal Input vom User, damit es halt im nächsten Step weitergeht. Und das dritte ist Logging. Also Server kann Logs zum Client schicken. Ist auch gut im Enterprise-Umfeld. Man will ja schließlich sehen, was passiert. Und das Neueste, was dazu kam, ist Utilities. Das ist eine komplett neue... Capability ist jetzt unabhängig betrifft Client und Server. Es ist einfach nur, dass das Server Notifications an den Client schicken kann. Weil heutzutage gibt es viele Prozesse auch von Agents die sehr lange laufen oder auch um NCP-Server-Seite Dinge sehr lange laufen und manchmal will man halt den Client einfach benachrichtigen, wie der Zwischenstand ist. Mittlerweile muss ich sagen, das ist ziemlich ausgereift, weil diese ganzen Client-Capabilities und auch das gerade letztgelandene Notifications, das gab es alles nicht. Ich meine, das Protokoll ist jetzt vielleicht oder der Standard ist jetzt Er ist nämlich ganz eineinhalb Jahre alt, so ein bisschen älter als ich. Aber er hat sich schon sehr viel getan, muss ich sagen. Also auch gerade richtig viel Bewegung drin. Also ich denke, da werden noch viele Änderungen in Zukunft kommen.

Stefan: 22:41

Ich meine so viele Leute die das inzwischen benutzen ist es ja einfach... Nur natürlich. Da ist jetzt gerade viel Fokus drauf und dann fallen eben auch die ganzen Kinderkrankheiten, die so einen Standard vielleicht ab Anfang hat, fallen direkt auf und dann werden sie halt auch angegangen, weil das lohnt sich.

Benjamin: 22:58

Und für alle Zuhörer, die sagen, hey geil, ich will mal so einen Agent bauen, es gibt ja auch viele Frameworks und Agents Bauen da würde ich jetzt nicht tiefer eingehen aber das heutzutage relativ leicht zu bauen und die wollen halt auch irgendwie so ein mcp server oder so anbinden oder auch vielleicht einbauen weil für viele sachen es gibt schon tausende mcp server die man benutzen kann aber vielleicht hat man gehört ein hat man 3d drucker angebunden wenn man seinen eigenen 3d drucker irgendwie anwenden will kann man ja auch sein 1 mcp server schreiben ihr müsst nicht von null anfang es ist eine spezifikation mcp Das ist erstmal eine Standardspecification. Improvic sind ja die Rausgeber, die haben auch extrem viele SDKs schon, also First Party SDKs in Java, Python, TypeScript, Go, you name it, die man nutzen kann. Also man muss nicht von Grund Null auf anfangen. Es gibt auch von Third Party, also weil es ja ein Spektrum ist, ist es ja jedenfalls nicht selber nochmal SDKs zu bauen, zum Beispiel Fast MCP ist nicht von Improvic Ist auch ein geiles Framework, was man nutzen kann, um geiles MCB-Server zu bauen, die dann einfach viel von diesem Heavy Relifting wegnehmen, das einfach für sich wegabstrahieren und halt das machen, was ein Framework gut macht, nämlich Dinge einfacher machen. Ja, hoffentlich. Das ist ein So was ich jeden Fall den Leuten empfehlen kann, wenn sie anfangen wollen, einen MCP-Server da kleinzuschreiben.

Stefan: 24:16

Ja.

Benjamin: 24:17

Wobei wir das die ganze Zeit geteasert hatten, wollte ich das auch noch unbedingt noch mit einstreuen, weil ich den 3D-Drucker gerade erwähnt habe. Also es ist wirklich ein Use Case, den ich mal gesehen habe, dass jemand einen 3D-Drucker angebunden hat über einen MCP-Server. Aber ich würde sagen, die meisten dazu kommen ja eher vielleicht aus der IT-Branche, schreiben mehr Software. Ich glaube, für die habe ich noch weitere coole Beispiele, man kann auch Figma mittlerweile Anbinden. Unser geliebtes Design-Tool wo die UX-Designer ja Designs reinmachen, wo man Designs abfragen kann und man dann dem Agent Zugriff geben kann auf die Designs. Und da kann man ja nicht nur sagen, code mir das und mach mir eine schöne Geis, sondern code mir das bitte mal, lieber Agent, also Cloud Code zum Beispiel und schau dir... Fick mal mal an, damit du genau weißt wie das aussieht. Klar, wenn er es dann gebaut hat, wo er weiß wie es aussieht, dann gibt es noch einen Playwright-NCP-Server mittlerweile, wo man Playwright anwenden kann. Playwright ist, für alle, die nicht kennen, ein UI-Testing-Tool, was den Browser die Seite öffnet und eine von den Capabilities, also von den Tools, die der Server zur Verfügung stellt, ist, Screenshots zu machen. Von der Seite Das heißt, er hat die Screenshots, er hat die Figma-Designs er kann das dann abgleichen und stellt die Differenzen fest und kann sich so langsam dem Design nähern. Und dadurch werden diese Agents über diese MCP-Server oder diese ganzen Tools im Endeffekt deutlich schlauer und können deutlich mehr machen.

Stefan: 25:34

Das heißt, mein Agent geht quasi hin und sagt, hey, ihr liebes LLM, hier ist mein Designsystem, bauen wir mal was danach. Dann vertraut er dem LLM nicht und beschließt okay, ich mache mir auch nochmal UI-Tests dazu und kann dann tatsächlich so eine Vergleichsaktion durchführen und beschließen, das machen wir jetzt 20.000 Mal und dann sind wir hoffentlich nah genug, dass mir das Ergebnis gefällt.

Benjamin: 25:55

Ja, genau. Also das ist, also man ist ein bisschen absagterfasst mit dem MCP-Server man kann Informationen reinzuholen in den Agent, man kann aber auch Validierungen damit machen, wie ich es mit Playwright meinte, man kann aber auch zum Beispiel SonarCube-Server anbinden, gibt es einen MCP-Server von SonarCube, wo man dann Feedback zum Code kriegt, wie gut denn der Code ist, ob man was refactoren muss, das direkt berücksichtigen soll, dann kann ich auch sagen, hier dem lieben Code, schau dir die Issues in SonarCube an, fix mal bitte den Code. Und wir haben das tatsächlich bei uns irgendwo im internen Projekt mal ausprobiert und das hat gut geklappt, also der hat glaube ich hunderte Schuss wegbekommen und dann war ich auf Null und der hat da glaube ich 20 Minuten rumgerödelt aber ich musste nichts machen. Das ist echt praktisch. Aber

Stefan: 26:34

das heißt ja auch gute Sonarchube-Regeln helfen halt nicht nur eine größere EntwicklerInnen-Mannschaft So ein bisschen zu steuern und eine Richtung zu geben für eine einheitliche Lösung, die man am Ende entwickelt, sondern kann dann eben zukünftig sogar helfen, wenn man mit mehr KI arbeitet.

Benjamin: 26:49

Genau, um der KI ein bisschen Leitplattenleitigen zu geben und zu sagen Hey, was ist gut, was ist schlecht? Und mein absoluter Favorite ist Das ist, glaube ich auch eine neue Ära für mich. Klar, es kann jetzt vielleicht ein bisschen übertrieben sein, aber es ist eine neue Ära von Analytics, weil früher so Fachbereiche, ich meine, immer so in der Analytics-Abteilung, die haben dann halt ein Dashboard gebaut, wo die Fachbereiche draufschauen konnten, gerade aus unseren Banden bei Reporting oder so. Und das war immer sehr aufwendig zu bauen mit MathLab oder mit Power BI oder mit anderen Tools Da ging immer viel Konzeption rein und jeder hat ja andere Bedürfnisse gehabt, auch jeder in der Fachabteilung und da muss man sich immer darauf einigen, wie baut man jetzt aber dieses Dashboard? Und wenn man es dann selber customizen konnte, war es immer mega aufwendig weil man musste ja wissen, wie man diese Daten da rein bekommt, wie man die queriert. Und ein richtig geiles Tool, was ich jedem empfehlen kann, ist MCP Toolbox. Das ist von Google. Das ist ein MCP-Server wo man Alle möglichen Datenbanken anbinden kann. Und was man dann ja machen könnte, ist man nimmt diesen MCP-Server bindet den Agent an, sagt dem Agent, hey, ich möchte gerne einen Report haben, der mir diese Daten zeigt, als Zeitleiste. Man beschreibt halt einfach mit, das kann ja jeder Fachbenutzer verwenden, weil man mit einfacher Sprache beschreibt was man gerne auf so einem Dashboard sehen möchte. Der übersetzt das dann halt in diese Queries, der holt sich die Daten, ich warte es zurück. Dann kann man dem Agent noch sagen, hey, bring mir das doch bitte in irgendein Format, was ich in ein Datenvisualisierungstool einbinden kann. Zum Beispiel von Google gibt es so ein Tool, wo man Datenvisualisierung machen kann und da kann man sagen, ja bringt mir das in dieses Format, ob jetzt XML oder JSON oder YAML ist, das weiß ich gar nicht und das macht da AirJet auch und da kann man es einfach hochladen und dann kann jeder für sich selber einfach diese Dashboards ohne Programmierkenntnisse halt bauen und customizen wie man es halt gerne hätte. Klar gibt es da auch wieder Fallstricke Aber das ist halt ein wichtiger Use Case.

Stefan: 28:33

Das klingt super praktisch weil solche Dashboards, ich kenne sie hauptsächlich erfahrungsmäßig mit, es sind viel zu viele Informationen, weil man eben immer irgendwelche Trade-Offs machen muss mit, wer will jetzt eigentlich was sehen und dann kann wirklich jeder, der auf was drauf guckt, genau das sehen, was er oder sie sehen will. Genau. Diese

Benjamin: 28:50

Individualisierung von Software wird dadurch immer mehr auch enabled. Und andere haben nur so Neben-Use-Cases, die ich gesehen habe wenn ich Privates genutzt habe. Die ganzen Marktdaten-Anbieter in der Finanzbranche haben mittlerweile auch MCP-Server rausgebracht. Also man kann Marktdaten in seine Agents reinbekommen, also Tics und Kurse. Und dann kann man natürlich seinen Agent bauen, dass der vielleicht für einen handelt und so. Ist jetzt keine Empfehlung, dass man vielleicht blinder KI vertrauen sollte, um mit deinem privaten Geld zu handeln. Aber da sieht man mittlerweile, wie weit das geht, dass sogar diese Finanzmarktdaten mit sehr, sehr traditionellen und auch klassischen Unternehmen, dass sie auch auf diesen Zug aufspringen und alle diese MCP-Server mittlerweile an den Markt bringen. Also es gibt kaum was mittlerweile, für was es keinen MCP-Server gibt, wenn man sich ein bisschen umschaut. Zumindest von den gängigen Tools, die halt viele nutzen. Genau. Aber da kommt auch ein Problem. Es gibt ja Hunderttausende vielleicht mit diesen MCP-Servern und da würde ich gerade schon direkt Richtung Enterprise-Probleme vielleicht springen weil da habe ich das gemerkt, wo ich gemerkt habe, okay, wie würde ich sowas in Enterprise einführen? Naja, wo kriegst du die her? Das ist ja die erste Grundproblematik. Diesen MCP Server kaum bekommen, den schon jemand geschrieben hat. Es gibt Repositories, es gibt nicht den de facto Standard wie bei JavaScript, wo man MPN, das ist ja das de facto Artifactory. Es gibt es nicht, es gibt mcp.so, es gibt awesome mcp Server, es gibt von mProfig, also die Autoren von MCP, die haben es mittlerweile auch geschafft, eine Repository an den Start zu bringen. Es gibt verschiedene Anbieter. Und da komme ich, bin ich genau auf deinen Punkt zurückgekommen auf dieses Trust-Thema. Weil ich muss ja dem Herausgeber vom MCP-Server vertrauen, weil der steckt ja zwischen der ATI und mir und hat ja am Ende auch irgendwo meine Credentials wo wir auch nochmal gleich dazu kommen müssen. Und dem muss ich ja vertrauen, dass der keinen Quatsch damit macht.

Stefan: 30:38

Dass er keinen Quatsch selber macht, dass er keinen Quatsch mit meinen Anfragen macht, dass er keinen Quatsch mit meinen LLM macht, auf das er ja zugreifen kann. Ich meine, wir haben in der Vergangenheit gerade dieses Jahr häufig gesehen, was schon bei sowas wie einer Library wie NPM an Sicherheitsrisiken passieren kann, wenn jemand die Repositories übernimmt oder sonst irgendwas und dann plötzlich Schadsoftware mit in den Frontends drin ist. Das ist ja bei so einem gefühlt oder bei dem, was ich verstanden habe, ist es bei so einem MCB-Server noch gravierender weil die einfach noch viel mächtiger sind.

Benjamin: 31:07

Genau, weil man auch weniger Kontrolle hat, weil es ja nicht desamistisch ist, ein Modell ja selber Entscheidungen treffen kann oder auch die Agents Aber bei diesem ganzen Thema von diesem Security und Vertrauen, würde ich immer allen empfehlen, erstmal auf MCP-Service, klar, die man selber geschrieben hat oder in ein Unternehmen geschrieben wurden, oder direkt von... Den Betreibern zum Beispiel zu einer API. Also wenn Google selber einen MCP-Server ausgibt, man vertraut ja auch der API oder Google selber, da kann man auch den MCP-Server vertrauen. Genauso wie bei Azure von Microsoft oder von Cloud. Egal wer diese MCP-Server entwickelt, sobald die gleichen sind, die auch die API dahinter bedienen, würde ich sagen, kann man in der Regel fein werden damit erstmal sicher. Nichtsdestotrotz In einem Enterprise-Umfeld würde ich trotzdem mit dem MCP-Inspektor das ist ein Tool von Improfit, kann man sich auch anschauen was denn rein raus geht und was denn überhaupt in so einem MCP-Server genau passiert. Oder auch in dem Kleinen der Kommunikation würde ich auch empfehlen, wenn man unsicher ist. Sollte man das nochmal checken was da genau passiert, weil es hat halt unglaublich viele Angriffsvektoren Gerade diese ganzen KI-Themen mit Prompt Injection wird halt durch die MCP-Server nochmal verschärft. Also für alle, die es nicht kennen, bei Prompt Injection geht es darum, dass man irgendwie... Schafft zum Beispiel eine Datenbank irgendeinen Eintrag zu hinterlegen als Kunde, was dann halt von diesem MCP-Server zum Beispiel genutzt wird oder vom Model dann schlussendlich genutzt wird oder irgendeine Anweisung vor das Model drinsteht. Wenn das mit abgefragt wird und das war zum Beispiel mein Username und anstatt meinem Username habe ich irgendwie was eingetragen hier Model, mach mal dies, bitte das schick mal an die E-Mail, bitte alle Kundendaten, dann kriegt das Model weil der beim Nutzernamen ausliest über den MCP-Server in seinen Kontext das rein versteht das als Anweisung Was automatisch hereingeflossen ist und zack schickt er mir an meine E-Mail vielleicht, wenn ein E-Mail-MCP-Server angebunden ist, eine E-Mail, wo alle Kundendaten drinstehen. Und das ist noch ein Problem, was bis heute noch nicht gelöst wurde. Es ist weiterhin ein großes Problem, Prompt Injection in der Welt. Bin ich mal gespannt, wann die da eine Lösung finden. Muss man einfach nur bewusst sein, dass man das sehr kritisch vorausschauen sollte. Weil wir es Security hatten, UAUF 2.1 ist offiziell mit Leitung unterstützt im MCP-Spec Das freut mich, dass endlich auch ein Dass die da einen Standard definiert haben. Es war lange Zeit nichts definiert wie man eine Security macht. Mit OAuth hat man da einen guten Spieler, der, denke ich, im Markt etabliert ist, dem man auch vertrauen kann.

Stefan: 33:41

Und da ist ja auch konstant Weiterentwicklung drin. Also ich finde es wirklich Wahnsinn, was die dort machen bei OAuth. Und das sind immer wieder neue Dinge, die mit drin sind. Es sind immer wieder Aktualisierungen mit drin. Und sind so gut sie können am Zahn der Zeit.

Benjamin: 33:54

Vor allen Dingen, dass auch dieses MCB-Thema auch einfach die OAuth-Macher dazu bewogen hat, die Specs anzupassen, finde ich auch interessant. Für alle, die OAuth ein bisschen kennen, ganz kurz nur, der Client fungiert meistens Der macht dann diesen ganzen Mechanismus von dem Authorization-Flow, wo der User sich durchklicken muss, einloggen muss auf den Authorization-Server. Und das Backer, der MCB-Server kümmert sich nur um die Token-Validierung. So ist ungefähr die Verteilung zwischen den beiden, was diesen ganzen OAuth-Flow angeht Funktioniert mittlerweile recht. Da habe ich es selber sogar schon mal umgesetzt. Das andere, was man so im Enterprise-Umfeld beachten muss, neben der Security, ist natürlich...

Stefan: 34:30

Ich habe noch eine Frage, bevor wir da einsteigen. Bei der Security, wir haben vorhin darüber geredet dass ein Client verschiedene Dinge tun kann. Ich habe Capabilities an das Schluss genannt, dass der Client eben auch, dass der Server den Client eben auch Dinge anfragen kann, um das Model zu benutzen und so weiter und so fort. Und ich denke, oder ich habe... Wahrgenommen, dass das so einer der größten Punkte ist, wo Sicherheitsprobleme herkommen, dass du dir dem Server eben vertrauen musst. Habe ich auch die Möglichkeit grundsätzlich diese Client-Helper-Abilities einzuschränken? Ja. Also man kann auch sagen, man

Benjamin: 35:03

implementiert also Tools auf SAP-Server-Seite würde ich auf jeden Fall implementieren weil es ist Der Kern, das macht wenig Sinn. Man muss keine Prompt man muss keine Reset zur Verfügung stellen, muss auf Client-Seite keine, keine Sampling also Sampling heißt die Fähigkeit, nicht zur Verfügung stellen. Oder auch diese Fähigkeit, dass man dem Kunden das anbietet, das passiert da, es ist ein bisschen wie ein SSL-Handshake in dem Protokoll. Client und Server, wenn die Verbindung aufgebaut wird, handeln aus, was kann der Server, was kann der Client, die informieren sich gegenseitig und dass die dann wissen, okay, was unterstützt denn? Jeder jeweils andere. Und das heißt, das muss man nicht machen. Das heißt, wenn man nur die Tools macht und dieses Sampling erstmal außen vor lässt, ist man auch schon ganz gut unterwegs, was jetzt auch Security angeht Beim Sampling muss man sich ein bisschen mehr Gedanken machen. Ja, gut. Danke dir. Aber gute Frage. Das andere, was ich noch sagen wollte, ist, Security ist immer so ein Konzern wo es sich immer gut um das andere ist. Skalierung, weil ja klar, ich kann lokal MCP-Server aufsetzen, zum Rumspielen kann man machen, prinzipiell Security-technisch empfehle ich das nicht mal, weil wenn man einen MCP-Server lokal aufsetzt, hat der ja Zugriff Auf den kompletten Rechner. Mit den gleichen Rechten, mit dem er gestartet wurde. Das heißt, der kann relativ viel auf dem eigenen Rechner machen. Und das ist halt gefährlich, weil der kann halt broke gehen. Der kann halt anfangen, Dinge zu machen, die man gar nicht weiß. Weil gerade auch Agents oft viele Aktionen machen, wo gar keine Rückfrage zum User gibt. Und dann passieren einfach Dinge. Da muss man ein bisschen aufpassen. Das heißt, ich empfehle auch in einem Enterprise-Umfeld immer Remote-MCP zu machen. Weniger Local, eher Remote, da hat man viel mehr Kontrolle. Und Remote, wenn man in der Cloud ist, das Deployed, bei MCP muss man wissen, habe ich vorhin jetzt ausklammert muss man wissen, meistens ist es ein zustandsbehaftetes Protokoll. So war es von Anfang an gedacht, mittlerweile kann man es auch zustandslos machen, aber prinzipiell ist es erstmal immer zustandsbehaftet MCP. Das heißt, wenn man einen Zustand hält, Und wenn der Cloud ist, man will es skanieren, man will diesen MCP-Server vielleicht auf 10 Nodes laufen lassen, jetzt ein Kubernetes oder auf 10 Pods laufen lassen, wie hält man dann, dann muss man halt irgendwie diese Session sharen. Aber dann würde ich sagen, kann man ganz bedroht die altbewährten Mechanismen nutzen, Redis zum Beispiel. In-Memory-Datenbank, so bei Performant schnell oder halt auch eine normale Datenbank, wo ja Sachen ein bisschen größer sind und auch nicht so häufig abgefragt werden, weil es ist ja meistens so ein Hin und Her beim MCP, auch bei einem Agent, der tut ja auch meistens öfter mit diesem MCP-Server interagieren und dadurch muss man ja, es ist besser, wenn der MCP-Server für die meisten Use Cases halt auch weiß, was der User denn vorher denn so angefragt hat. Ja. Man muss diesen Zustand irgendwie halten. Das heißt, darüber muss man sich auch ein bisschen Gedanken machen, muss das mit installieren. Ist aber in den heutzutage Cloud-Umgeben glaube ich, kein Problem, was schwer ist zu lösen. Was ich auch empfehlen kann, ohne jetzt tiefer auf einzugehen, MCP-E-VALS nennt sich das. Also in der KI-Welt spricht man nicht von Unit-Tests, Integration-Tests, sondern von E-VALS. Ich würde jetzt nicht zu tief reingehen, was E-VALS genau sind. Ich würde es sehr grob nur beschreiben, Models sind ja nicht deterministisch das heißt, der Output kann immer leicht anders sein, deswegen kann man auch nicht wirklich so Unit- oder Integration-Tests schreiben, immer das gleiche Ergebnis erwarten, dann hat man halt Tests die halt sehr oft failen Sondern in diesen E-Volts arbeitet man eher mit einem Scoring und einem Soft-Einschätzung und mit Schwellenwerten und dass man sagt, okay, passt das jetzt, was ich als Ergebnis bekomme oder halt nicht. Und da gibt es ein Library, nennt sich MCP E-Volts. Oder generell sollte man da halt mit jeweils arbeiten, um zu testen hey, mach den MCP-Server was ich will. Das andere ist, was ich auch noch gehört habe, ist, was manche schon gesehen haben, bei Kunden ist, die versuchen, mit Open API diese MCP-Server zu generieren. Weil man sagt, hey ich habe ja eine API, ich will ja einen MCP-Server generieren, damit dann mein Client oder mein Agent Zugriff hat auf die API. Klingt erstmal logisch kann man ja machen. Der Riesen-Nachteil ist, weil ich mich damit immer beschäftigt habe, ist, wenn man das generiert kann man machen, gibt es ganz viele Frameworks draus. Das Problem ist, OpenAPI ist nicht dafür gebaut, dass es von Models konsumiert wird. Das heißt, diese Beschreibungen, die man zum Beispiel hat, die sind nicht dafür ausgelegt dass ein Modell versteht was diese Schnittstelle genau macht. Man hat auch meisten APIs viel zu viele Schnittstellen, die vielleicht für die Use Cases von Agent-Agenten Irre weil ein Agent hat ja immer ein Task, der will ja immer was erreichen. Und so API sind sehr, sehr low-level. Die sind ja nicht so high-level, hier legen wir einen Kalendereintrag an, sondern vielleicht sind es auch viele einzelne API-Schritte, die man dafür braucht. Und Wenn man so ein Model halt so viele Möglichkeiten gibt und zu viele APIs, dann verwirrt man auch damit das Model. Weil das ist ein eigenes Themengebiet für sich, Context Engineering. Wenn man zu viel, auch der Hinweis, man sollte nicht zu viele MCP-Server anbinden, weil man zu viele MCP-Server anbindet und dem Model zu viel Informationen gibt, dann werden die Ergebnisse immer schlechter Und wahrscheinlich auch teurer, weil es länger mehr Ressourcen braucht, um das Ganze auszuhalten. Auch, und das ist auch ein Faktor aber Hauptproblem ist, dass die Ergebnisse schlechter werden, weil es gibt ja genug Studien, die zeigen, die werden ja auch immer, dass es immer größere Kontext-Windows gibt, also immer mehr Input-Tokens die man reinstecken kann in so ein Modell. Das Problem ist nur, dass es... Umso größer dieses Kontext-Window wird, umso schlechter werden die Ergebnisse und deswegen sagen auch die ganzen Experten, die sich damit auskennen, man sollte immer gucken, dass man nicht zu viel in so einen Kontext reinpackt bevor man es zum Modell schickt, also den Input möglichst klein hält und deswegen aus Open APIs einfach nur diese MCPs generieren schlecht, weil wie gesagt zu viele APIs drin, die Schreibung passen nicht und Beispiele sind halt sehr wichtig. For Models, was jetzt bei einer normalen REST-API nicht so ist. Also Menschen brauchen nicht viele Beispiele, Models schon, damit die gut funktionieren.

Stefan: 40:56

Das heißt, ich brauche nicht zu viele Informationen, aber trotzdem Beispiele. Ja genau, Beispiele. Also gerichtet viele Informationen, dass ich quasi sage, okay, ich habe halt nur diese drei verschiedenen Beispiele Server zum Beispiel, aber ich habe zu jedem Server einen riesen Haufen an Beispielen damit mein Modell versteht hey, so nutze ich das. Genau, dass

Benjamin: 41:16

der versteht wie ich das zu nutzen habe. Der braucht Kontext der versteht wer es benutzt. Und das ist halt so ein Fallstreck. Also kann man gerne machen. Mein Tipp ist, einfach als Baseline kann man generieren, aber dann sollte man das nochmal refine und nicht einfach blindes nehmen, was aus der OpenAPI als NTP-Server generiert wurde. Aber es kann ein guter Start sein. Ja. Genau so ein guter Start ist, es gibt nicht nur die SDKs, sondern gerade wenn man zum Beispiel im Spring- oder im.NET-Umfeld unterwegs ist, vielleicht bei Spring zu bleiben, gibt es auch Spring Boot Starter, die auf diesen offiziellen SDKs von Introphic aufsetzen wo man dann direkt sehr schnell in diesen, Spring-Ökosystem, MCP-Server und Clients aufsetzen kann. Und wenn man dann sogar noch die AI nutzt um die für einen zu schreiben, ist man, glaube ich, in zehn Minuten hat man schon was aufgesetzt, was funktioniert. Gut, und darauf aufzusetzen muss ich mich ein bisschen mehr beschäftigen. Aber ich glaube, mittlerweile sind die Einstiegshöhen relativ gering, um einfach mal damit anzufangen.

Stefan: 42:13

Wie es dann weitergeht, darüber sehen wir dann in der Zukunft. Wann die KI gut genug ist, auch hochwertige Software komplett alleine zu

Benjamin: 42:21

schreiben. Genau, da bin ich auch gespannt. Ich glaube, irgendwann kommt es dahin, oder wenn uns da erinnern wann es sein wird, steht, glaube ich noch in den Sternen.

Stefan: 42:29

Das glaube ich auch. Damit, muss ich sagen, habe ich zumindest ein grobes Bild und ein recht gutes Verständnis, wie ich denke, zu MCP erlangt Und deswegen so von mir muss ich sagen, wie MCB passt, was man vielleicht mit Agenten alles noch so tun kann, das steht noch auf dem anderen Zettel da können wir vielleicht irgendwann uns nochmal so austauschen und was genau im Detail so ein Agent alles noch machen kann. Aber jetzt für MCB würde ich sagen... Danke dir. Das war sehr erleuchtend worüber wir geredet haben. Hast du noch irgendwelchen Input an unsere Hörerinnen und Hörer den du abschließend vielleicht noch mitgeben möchtest?

Benjamin: 43:03

Freut euch. Ich höre schon raus, es wird wahrscheinlich eine Folge zu Agents gehen. Das ist das eine. Das andere ist, MCP ist ein Standard. Der einfach dafür sorgt, dass man nicht jedes Mal das Artenwerk findet. Das heißt, wenn ihr euch mit Agents beschäftigt Agents bauen wollt, denkt immer mit an NCP. Damit könnt ihr leicht diese Tools in den Agents nutzen. Müsst das nicht alles selber bauen. Überlasst das Heavy Lifting den Frameworks. Und wenn ihr euch noch mehr mit dem Thema beschäftigen wollt, weil das war jetzt zwar viel, ich habe viele Buzzwords gedroppt, ich denke aber viele interessante Themen angesprochen, wenn man das ein bisschen vertieben möchte, kann ich drei Sachen empfehlen. Das erste ist ein YouTube-Kanal, der nennt sich MCP Developer Summit. Das ist eine eigene Konferenz gewesen zu MCP. Die haben extrem viele Videos zu dem Thema und Deep Dives. Genauso wie der YouTube-Kanal AI Engineers. Hat auch sehr viele Videos zu MCP. Ist auch eine Konferenzreihe. Hat noch viele andere interessante Videos zu AI, aber zu MCP gibt es auch genug. Und das Letzte ist, bin ich sehr stolz auf Anthrophic, das sind ja die Ausgaben von MCP, die haben eine hervorragende Dokumentation zu MCP, haben extrem viele Beispiele gut gepflegte Github-Repos, immer wieder neue Blogposts wenn sich was getan hat am Speck mit guten Beispielen aus der Praxis, schaut da auch gerne rein. Ich glaube, wenn man Diese drei Quellen berücksichtigt ist mir erstmal gut aufgestellt und kann einfach mal wild drauf loslegen und einfach mal ein bisschen Spaß haben, weil was ich sagen kann ist, was mir im Prinzip am meisten gefallen hat, es war einfach so leicht, ich konnte direkt irgendwelche Sachen in meinen Agent ausprobieren, hat richtig Spaß gemacht einfach damit zu arbeiten. Probiert's aus. Und danke, Stefan, für die Einladung.

Stefan: 44:44

Danke dir für alles. Du hast mir auf jeden Fall den Mund ein bisschen wässig gemacht, um solche MCP-Server auch mal selber und du Kleinst selber auszuprobieren. Die Quellen, wie immer, hängen wir sie mit in die Beschreibung dran. Das heißt, wenn ihr es nachlesen wollt, tut es gerne. Und damit wären wir fertig für heute und wir hören uns beim nächsten Mal. Macht's gut, ciao. Ciao.