Deep Dive 179 –

Model Context Protokoll (MCP) mit Philipp Schmid

13.05.2025

// Podcast
// Deep Dive 179

Shownotes

In dieser Folge sprechen wir über das Model Context Protocol (MCP) – einen offenen Standard, der von Anthropic eingeführt wurde. MCP soll die Art und Weise standardisieren, wie KI-Anwendungen – etwa Chatbots, IDE-Assistenten oder benutzerdefinierte Agenten – mit externen Tools, Datenquellen und Systemen interagieren. Kurz gesagt: MCP ist wie ein „USB-Anschluss“ für KI-Integrationen und vereinfacht die bislang komplexen Verbindungen zwischen KI-Modellen und ihrer Umgebung.

Wir erklären, aus welchen zentralen Bausteinen MCP besteht: Was sind Tools und Ressourcen? Welche Rolle spielen Clients und Server im MCP-Kontext?

Außerdem diskutieren wir, warum MCP aktuell so stark gehypt wird – und ob es die Entwicklung von AI-Agenten grundlegend verändert.
Wenn ihr erfahren wollt, wie ihr heute schon MCP-Server in eure Entwicklungsumgebung oder LLM-Chats integrieren könnt, dann hört unbedingt rein!

Interessante Links:

Download

/transkript/programmierbar/deep-dive-179-model-context-protokoll-mcp-mit-philipp-schmid

Dennis: Hallo und herzlich willkommen zu einem neuen Deep Dive im AI Space. Wir reden heute über das Model Kontext Protokoll. Ich bin Dennis, neben mir ein Gesicht, das wir lange nicht mehr gesehen haben.
Fabi: Der Fabi und jetzt auch nur hören und gar nicht sehen.
Dennis: Das stimmt, ich seh dich und Du bist gut gebräunt.
Fabi: Ja, ich war dreieinhalb Monate in Thailand, 'n bisschen Sabbatical gemacht und ja, hab Gefühl, es ist nichts passiert in der Zeit, weil wir uns über Model Contact Protokoll unterhalten, was gefühlt 1 der letzten Themen unserer AI News im Dezember war. Und ich mir dachte, hä, das was ist ist gar nicht was.
Dennis: Aber damals wurd's einfach nur vorgestellt als Protokoll und heute ist es der Hype.
Philipp: Ah, das
Dennis: ist spannend. Deswegen sprechen wir darüber und mit wem könnten wir das besser tun als mit Philipp, der uns jede Woche auch in den AI News unterstützt. Hallo.
Fabi: Philipp, schön,
Philipp: dass Du am Start bist
Dennis: und ein bisschen was uns über MCPs erzählst. Nein, ich sag immer MC, das hört sich sowieso nach Mehrzahl an, aber das ist ja nur ein Protokoll.
Philipp: Ja, das das Einzige, den den Fehler, den ich immer Anfang gemacht hab und auch gesehen hab, ist, man sagt immer MCP Protokoll, aber das wär dann Model Kontext Protokoll Protokoll. Ja. Also MC Protokoll oder MCP?
Dennis: Ja, aber auch kein Plural.
Fabi: Gut. Aber es gibt ganz viele MCP Server und darüber darüber halten wir uns ja gleich.
Dennis: Das stimmt, das gibt es. Wir sind zu transparent.
Fabi: Und und schauen
Dennis: wir noch mal kurz, dass Philipp uns grade auch Abwechslung gemacht hast, nach 25 Minuten Aufnahme, dass wir hätten doch auf Aufnahmen aufnehmen drücken können am Anfang der Folge. Von daher ist das jetzt unser zweiter Take, den wir dazu haben. Wenn wir jetzt ganz relevante Informationen vergessen, dann liegt es daran, dass wir gerade den ja in der nicht aufgenommenen Folge, die schon geteilt haben.
Fabi: Nee, ich ich es ist
Philipp: mehr wie sone Übung, das kennen wir doch bei Präsentationen. Die Übung wird nie so gut wie dann das die richtige Präsentation, weil man ja schon 'n bisschen drüber geredet hat und son bisschen den roten Faden hat oder vielleicht auch Dinge einfacher in die richtige Reihenfolge passt. Das heißt, die Folge kann nur besser werden.
Dennis: Hast Du nicht grade gesagt, die Übung ist besser als jede Präsentation?
Philipp: Nee, nee, bei Geld ist wichtig. Und also ich weiß nicht, wie's bei euch früher war, aber wenn ich eine Präsentation in der Schule oder heut noch so gemacht, dann wenn ich die üb davor, dann ist die Live Präsentation immer 'n bisschen besser, als wenn ich die nicht übe. Okay.
Dennis: Also
Fabi: ich hab nie geübt davor, deswegen weiß ich nicht, aber Ja, genau.
Dennis: Mal gucken. Ach ja, dann komm Fabi. Gib mir dir mal die Möglichkeit, MCP in einem kurzen Satz zu beschreiben. Also jetzt müsstest Du's ja im Gegensatz zur ersten Aufnahme, jetzt müsste das
Fabi: Ja, ist von 'n definiert offener Standard zur Interaktion von, sagen wir mal, LLMs mit der Außenwelt, wo's ja schon verschiedene Ansätze gab und hier als offener Standard definiert. Und son bisschen, ich glaub, Philipp hat's ja auch in seinem Blogbeitrag, dem wir auch verlinken werden, auch schon geschrieben so, als der USB Standard oder USB-c-Standard, vielleicht wenn man vorher gab's ja doch verschiedene USB Ports Ports für für Large Language Models und die Möglichkeit, jetzt wirklich relativ einfach mit der Außenwelt zu interagieren. Oder Philipp, wie würdest Du's in deinen Worten schreiben?
Philipp: Genau. Also ich find die Analogie super treffend. Ich hab die auch online gesehen. Also das ist jetzt nicht etwas, was ich selber erfunden hab.
Fabi: Mhm.
Philipp: Und ich bin, sag ich mir jetzt noch nicht ganz so alt, aber selbst ich weiß noch irgendwie in der Vergangenheit, wenn man einen PC hatte damals mit Windows 95 oder so was, hatte man für seine Maus und seine Tastatur, seinen Drucker, seinen Bildschirm jedes Mal einen eigenen Stecker mit einem eigenen Anschluss und da hinten dran waren ja auch immer eigene Treiber, die installiert wurden und eventuell konnte ich dann plötzlich meine Maus von meinem alten PC nicht mit meinem neuen PC verbinden oder 'n Controller nicht anschließen, eine Festplatte. Ich mein, da gab's ganz, ganz viele Beispiele. Und so kann man das sich aktuell 'n bisschen in der LLM Welt vorstellen. Wenn ich 'n LLM mit Tools verbinden möchte, ist es ganz häufig der Fall, dass ich für jede meine LLM Anwendungen dieses Tool oder Function Calling oder 'n prompt Template, das ich definiere, immer wieder neue Umsätze. Das beste Beispiel ist irgendwie, man hat eine Wetter API und ich bin 'n Unternehmen, das für 'n Nachrichtensender arbeitet und wir haben halt Wetter News und halt 'n Onlineservice, der Wetter News anbietet und irgendwie 'n Chat eine Chat App, die auch Wetter News zur Verfügung stellt. Und bisher höchstwahrscheinlich hätte jedes dieser Teams ihren eigene Funktionsdefinition geschrieben und die eigene Implementierung, wie ich dann dieses Tool in mein LLM bekomme. Und mit MCP ist der Gedanke, dass man das löst. Das Ganze wird ein bisschen beschrieben wie in der Software immer. Man hat ein m mal n Problem. Das heißt, ich habe m verschiedene Anwendungen und n verschiedene Implementierungen für ein Tool. In unserem Wetter Nachrichtenbeispiel wäre m sozusagen die Nachrichtensendung, die Chatanwendung und irgendwie meine Webseite. Und n wären dann jeweils die Implementierung, die dieser Wetter API. Und der Gedanke von MCP ist, dass ich sozusagen die Wetter API Anbindung oder das Tool, also die n nur einmal implementieren muss Und dann, dass jeder Client sozusagen dieses Tool einsetzen kann, ohne diesen neuen Entwicklungsaufwand. Genau.
Fabi: Und was Sie aber daran zum, wenn Sie beim ersten Mal meinen, es gab ja, ist ja nicht so, dass nicht schon probiert wurde, irgendwelche Dinge dort zu standardisieren. So das Erste, was man jetzt in Kopf kommen würde, ja auch Langchain oder so, wo es ja auch die Möglichkeit, solche solche Ressourcen oder Tools irgendwie mit meinem LM zu interagieren und 'n Agent zu schreiben, ja auch da schon 'n Gefühl von Form von Standardisierung hatten. So und kannst Du irgendwie, also vielleicht, wenn wir noch nicht den kompletten Kontext haben, wie MCP genau funktioniert, irgendwie dir erklären oder uns erklären, wieso jetzt MCP diesen Hype hat denn irgendwie scheinbar ein besserer Standard ist oder ist er's als Langchain? Oder Langchain probiert?
Philipp: Ja, also ist 'n gutes Beispiel fürn Versuch, wie man Agents standardisiert. Es gibt ja ganz viele weitere Agent Frameworks wie True AI, Lama Index, die alle 'n bisschen das Cyber Problem versuchen zu lösen. Wie können wir 'n Standard schaffen, dass LLMs easy mit Tools interagieren können? Aber keins dieser Tools hat sozusagen die Abstraktion geschafft, wirklich 'n Standard zu definieren. 'n Standard oder 'n Protokoll zu definieren, hat man im Normalfall ja eine Spezifikation. Also das gibt's ja bei HTTP oder bei anderen Protokollen auch. Und Langchain ist ja mehr so eine Implementierungsanwendung, wie ich das lösen kann. Also wenn ich einen Langchain Agent bau oder wir bleiben vielleicht bei unserem Nachrichtenbeispiel, dann baut jeder zwar einen Langchain Agent und jeder eventuell trotzdem noch dasselbe Tool, aber alle Tools sehen irgendwie gleich aus. Also da habe ich ja dieses Problem noch nicht gelöst, dass ich irgendwo remote dieses Tool hab und dann einfach interagieren kann. Klar kann man hier wieder einen eigenen Ansatz irgendwie umsetzen, dass ich GitHub Repositories hab, wo ich dann Shared Libraries hab, die dann jedes jeder Server oder jede Anwendung installiert und dann man das ausführen kann. Es funktioniert und ich meine MCP an sich ist auch nur eine Open API SPAC mit 'ner sehr guten Definition und verschiedenen API Routen. Aber halt wirklich diesen Standard zu erreichen, brauchst Du eine gute SPAC und MCP hat eine sehr gute SPAC, also Spezifikation. Die kann man auch online einsehen. Es haben wirklich Leute gebaut, die sich davor sehr, sehr viel beschäftigt haben. Sie haben sich andere Spezifikationen wie Open API angeschaut oder auch das Language Server Protokoll von Microsoft, das jetzt mittlerweile in allen IDIs mittlerweile zu Hause ist. Und da kann man auch eine gute Parallele ziehen mit was das Ziel von MCT ist, wenn man sich 'n bisschen die das Language Server Protokoll anschaut. Also ich weiß nicht, welche ID ihr nutzt, aber man hat ja Visual Studio Code, man hat mittlerweile Cursor und Windsurv, was ja eigentlich auch nur Visual Studio Code ist, aber ich hab ja Visual Studio, ich hab ja NeoVim, ich hab Chat Brains und alle diese IDEs sind sehr unterschiedlich, aber alle implementieren mittlerweile diesen Language Server Protokoll. Das heißt, wenn ich für Python oder für meine eigene Library einen Language Server implementieren möchte, damit Entwickler gut damit arbeiten können, schreibe ich nur noch 'n language Server Produkt oder halt 'n language Server, welches das language Server Protokoll implementiert. Und dann ist es automatisch verfügbar in allen anderen IDIs, ohne dass diese IDIs große Arbeit dafür leisten müssen. Das heißt, ich hab Support für Go Python automatisch in allen und alles funktioniert irgendwie gleich. Und davor hätte Visual Studio, Visual Studio Code, Intellij erhalten alle ihre eigenen Language Server sozusagen entwickeln müssen für für Python.
Fabi: Ja, cool. Vielleicht, Du hast gesagt, hat den den Standard auch sehr gut definiert. Aber wenn ich's auch richtig sehe, Sie haben auch gleichzeitig, ich weiß nicht, ob das dann macht oder nicht, aber auch die ganzen SDKs für verschiedene Sprachen, dann die Implementierung der Server beziehungsweise Client das dann zu machen. Gibt's auch schon eine sehr breite Palette. Das ist einerseits der Standard, aber auch gleichzeitig wurden viele Desty case mitgeschippt.
Philipp: Ja, ich mein, das ist generell bei, gibt immer mehr, also es ist nicht ein Argument, warum jetzt MCP Actors oder im Hype ist. Also es gibt ganz, ganz viele. Das eine ist dieses, dass es AI Native implementiert würde von 'nem großen Unternehmen wie Antropic, 'n relativ guten Community Anklang gefunden hat. Sie haben das auch damals gelauncht mit Beispielen für, wie man, also 'n Clay Desktop sozusagen selber integriert first Party Support. Sie haben verschiedene kleinen Server Libraries bereitgestellt, wie man MCP Server selber bauen kann. Sie haben MCP Servers selber bereitgestellt und halt einfach auch Tooling außen rum. Also wie kann ich diese Server debuggen? Wie kann ich die richtig deploying? Wie kann ich die linden und testen? Und dann natürlich jetzt, warum so im Hibis? Man hat wie auch immer 'n Network Effekt geschaffen, dass die Community und vor allem alle mehr oder weniger gezwungenermaßen jetzt MCP integrieren. Ich glaube, angefangen hat's mit Cursor und Windsurf, die MCP Server in ihre IDIs integriert haben, einfach mehr Funktionalität bereitzustellen, ohne dass der Entwickler selber diese Toolintegration schreiben muss. Dass Du sozusagen als Entwickler die Möglichkeit hast, eine Tool Integration außerhalb zu schreiben und dann über MCT in Cursor zu verbinden und Beispiele, die ich halt irgendwie gesehen habe, dass man hat andere LLMs integriert. Ich habe eine Art Fetch Service mit eingebaut, dass ich zum Beispiel dynamisch Webseiten abfragen kann als Teilen von meinem Agent Flow. Dann hat OpenAI angekündigt, sie werden MCP Server supporten in Ihrem Agent Tool und eventuell auch in ChatGPT, das ist ein bisschen noch auf der der Schwebe.
Fabi: Also ich den ChatGPT Server einbinden kann?
Philipp: Ja, das ist aber nicht bestätigt, sondern Sie haben MCP Support in Ihrer Open Source Open AI Agents SDK. Wir von Google Deep Mind arbeiten an der Integration in unsere SDK. Cloud hat natürlich die Integration und es gibt noch mittlerweile über 1000 Community MCT Servers. Das heißt, es wird schon ganz, ganz viel dafür gemacht, dass ich ganz, ganz, ganz einfach Tools in meine LLM Applikation einbauen kann, ohne diesen wiederholenden Boilerblade Code zu schreiben.
Fabi: Jetzt sind wir irgendwie schon viel reingegangen in Beispielen und so viel über Server irgendwie schon mit dem Begriff irgendwie rumgeworfen. Wollen wir vielleicht noch einmal probieren, mal zu erklären, wie denn jetzt, welche Komponenten es genau bei dem MC Protokoll gibt mit, also die Begriffe wären Host, Client und Server. Und ganz, falls Du jetzt Ressourcen angeht, haben wir oftmals schon Tools genannt. So können zumindest noch mit Host Client und Server. Was hat's da mit auf sich und wie interagieren die miteinander?
Philipp: Genau. Und vielleicht ganz kurz davor, einen superkleinen Abriss, wie generell, wie man Agents baut oder wie Function Calling funktioniert, weil das ganz häufig kommen. Function Calling ist die Möglichkeit in LLM Tools bereitzustellen und strukturierten Output zu generieren. Also das ist das Geheimnis hinter eigentlich jedem Agent. Man kennt das von unserem Wetterbeispiel. Ich frag, hey, wie ist das Wetter in Berlin? Und ich möchte dann, dass das Modell diese natürliche Sprache interpretiert und in eine Art strukturierte Form bekommt. Und das funktioniert in dem Sinne, dass man die Möglichkeit hat, bei seinem LLM Request nach JSONSCema bereitzustellen über eine Definition von verschiedenen Tools. Ein Tool könnte zum Beispiel sein getwather information. In diesem Tool habe ich dann die Beschreibung Retrease to current weather for gewinn Location und dann habe ich Input Parameter noch defined mit Location String String und irgendwie Date String String auch. Und wenn man mich dann sozusagen beides an den LLM schick, kann das LLM selber entscheiden, hey, ist die User Anfrage jetzt, kann ich die mit meinem Tool lösen oder brauche ich vielleicht noch Information oder ist es einfach nur normaler Chat und er sagt hallo und ich antworte halt mit hallo? Wenn es dann 'n Tool nutzen möchte, antwortet das LLM wieder mit 'nem JSON Output. Das heißt, es return den Toolnamen und die verschiedenen Argumente, die genutzt werden sollen, dieses Tool aufzurufen. Bisher war es dann so, dass ich auf meiner Client Seite das dann wieder parse, dann in meinem Code die Funktion Suche, die dann ausführe. Dann hat sozusagen, also ich nutze die Argumente, die das LLM bereitstellt, führe das auf meiner Seite aus und mach den Weather API Call zum Beispiel. Der Weather API Call kommt dann zurück mit irgendwie 25 Grad und dann wär der nächste Schritt, okay, ich schick diese Antwort von dem Tool wieder zu meinem LLM. Das LLM generiert dann eine schöne Nachricht für den Nutzer, irgendwie, das Wetter heute in Frankfurt ist 25 Grad und das wäre dann die Nachricht, die ich dann dem User anzeigen würde. Und bei MCP, Du hast es schon gesagt, ich hab 'n Host, 'n Client und 'n Server. Der Host wär in dem Fall, könnte eine Chatanbindung sein, könnte ein Agent sein, den ich 'n ziel eine sein. Das ist einfach unsere Applikation. Client ist eine Abstraktion, die Teil dieses Hosts ist, die sich mit dem Server verbinden kann und sozusagen zwischen Client und Server immer hin und her kommuniziert und der Server implementiert unsere Tool Tools oder auch Resources, also irgendwelche Dateninformationen oder auch prompt Templates, zum Beispiel den Nutzer zu helfen, 'n Tool ausführen zu können. Und wenn ich dann 'n MCP Server integrieren möchte, hab ich meinen Host, also meine Anwendung. In diesem Host rede ich mit dem LLM, das heißt, ich mache in dem Host die LLM Calls, aber auch sozusagen die kleinen Calls. Und im Normalfall ist es so, wenn ich meinen Host starte als Beispiel, wir haben Cloud Desktop, ist der erste Schritt sozusagen, ich starte oder verbinde mich mit meinen MCP Servers, die ich definiert habe. Die MCP Server initialisieren dann die Connection zu unserem MCP Server. Man hat immer eine 1 zu 1 Verbindung zwischen Client und Server. Das heißt, wenn ich mehrere MCP Servers hab, bräuchte ich auch mehrere MCP Clients auf meiner Host Seite und nachdem ich den Client ininstalliert habe, kann ich dann zum Beispiel über ARPC Calls die Tools listen oder auch Tools ausführen oder andere Informationen bekommen.
Fabi: Okay, und jetzt hab ich da beispielsweise mehrere Du hast ja immer Wetter als Beispiel genommen, die Wetter API, da wäre irgendwie der Tool Call. Gib mir mal den das aktuelle das aktuelle Wetter in New York oder so was. Und jetzt hast Du noch das Beispiel, also da da versteh ich, okay, Du hast uns ja vorher auch Function Calling erklärt sozusagen, da wird wahrscheinlich irgend einen Listen Call gegen einen Server gemacht. Diese Information wird jetzt als LLM mitgegeben und das LLM kann selbst entscheiden. Wenn wir jetzt die den anderen Typ Ressource haben, also was dann als Beispiel, gut bei 'ner Wetterapp ist wahrscheinlich, fällt mir jetzt spontan keine Ressource ein. Aber es könnte einfach eine Form von Datei sein oder kannst Du uns das Prinzip Ressource erklären und wie kann ein LLM irgendwie eine Ressource anfragen oder macht wer wer macht das?
Philipp: Genau, also in in MCP Server, Exposes Tools, Ressourcen und Prompts. Der, ich würd mal sagen, 99 Prozent aller MCP Server spezialisiert und fokussiert sich auf Tools, weil an sich kann alles als Tool definiert werden, aber man hat wirklich bewusst diese Abstraktion definiert, da Tools sozusagen Model controls sind, also das Modell entscheidet, wenn ich 'n Toolcall durchführe oder nicht. Der Gedanke hinter Ressourcen ist, dass das die Aufgabe der Anwendung ist. Ein Beispiel könnte einfach sein, die Version von 'nem 'ner speziellen API oder eine Art eine andere Art andere Informationen, die ich dann in meiner Anwendung anzeigen möchte, also wie eine User Information, dass ich einen MCP Server hab, der irgendwelche Informationen über mich bereitstellen kann. Und man kann sich das 'n bisschen so vorstellen, dass es eigentlich get requests sind, aber ohne und. Das heißt, es ist 'n get request, den ich immer ausführen kann, der eigentlich immer dasselbe Ergebnis zurückliefert und halt nicht plötzlich irgendwie 'n anderes Ergebnis. So kann man sich's 'n bisschen vorstellen und der Gedanke ist, dass der Anwender das selber kontrollieren kann. Beispiel, das ich gesehen hab von 'ner IDE Integration ist, dass ich zum Beispiel in meinem Chatfenster und dann in Filame eingeben kann, dass sozusagen dadurch 'n MCP request passiert und dann der Pfeilkontext dem Model bereitgestellt wird. Mhm. Und dann gibt's noch Prompts, die sind dann Usercontrolled. Da ist der
Dennis: Aber sind die
Fabi: da da mit dem Ja. Add und dann File kann ich denn dann auch die möglichen Ressourcen mir irgendwie Also ad on 12 eine Auto complete haben kann, so ad File name muss ich ja auch irgendwie erst mal Also ich ich kann alle Ressourcen mir irgendwie curren zu sagen, was Genau. Ressourcen gibt's denn?
Philipp: Ein MCP Server definiert verschiedene APC Calls. Es gibt immer List Tools, List prompts, List Resources.
Fabi: Ah, okay.
Philipp: Und dann habe ich für Tools habe ich Call Tool und dann habe ich get Resource und get prompt.
Fabi: Mhm.
Philipp: Und das Dritte, was wir noch haben, sind prompts, diesen User Control. Das Beispiel, das ich immer so ein bisschen im Kopf hab, ist, ich hab irgendwie einen speziellen Service, dass der User, dass ich dem User sozusagen die Möglichkeit biete, irgendwie so prompt Templates, die er anklicken kann. Und dann habe ich sozusagen, muss er nicht den ganzen Texte immer neu schreiben, wenn ich eine spezielle Summary oder eine spezielle Suchanfrage mache. Und der Gedanke hier hinter ist halt auch, okay, wenn ich einen MCP Server entwickle, bin ich der Domain Experte für diesen MCP Server. Das heißt, ich weiß eventuell auch am besten, wie ich den nutzen kann. Das heißt irgendwie, keine Ahnung, Youtube oder Google Maps, dass es 'n spezielles Format gibt, wie ich Longitude, Latitude oder Start, End der Route in meinen Prompt packen soll, dass das Modell das besser versteht. Und das könnt ich halt über diese Prompts expozen.
Fabi: Dennis, Du guckst, dass sich dann der an dem Part eine Nachfrage aufzingt?
Dennis: Ja, nee, ich versuche das, also aber das ist etwas, was ja dann trotzdem auch wegabsrahiert ist, ne, also was das LLM entscheidet. Also es kriegt Nee, nee,
Fabi: nee.
Philipp: Entscheidet der User. Also man kann sich Nur die
Fabi: Tools entscheidet das, ne. Alles andere beide ist dann hängt von dem, wie er's implementiert und wie er diese wie er diese Prompt Templates oder so was dir zur Verfügung stellt.
Philipp: Genau.
Dennis: Also das
Fabi: hab ich auch gefragt gemeint. Wenn dann viele Tools sind, keine Ahnung, hab ich dann irgendwie in meinem Chatfenster sozusagen irgendwie kann ich irgendwo klicken, Google Maps Template und hab dann sozusagen wie, oder vielleicht energier ich auch mit dem LLM, dann mir im Endeffekt das richtige Template raus zu uns noch nicht weiß. Also da bin da da würd mich auch mal der der Use Case interessieren, aber Du hast ja auch grad schon vorhin gemeint, ne. Der Großteil der Service wird sich auf irgendwie Tools wahrscheinlich, ist ist zumindest der Haupt Use Case, wie wie die meisten Dinge umgesetzt werden. So, deswegen hätt ich auch gesagt, lass uns vielleicht erst noch mal in diesen Toolsbereich reingehen, weil ich glaub, das ist sehr interessantere, weil grad bei die die die Hausimplementierung von so Templates stellen sich mir auch noch einige Fragen. Aber würd man auch sehen, wie's wie's
Philipp: Ich find da den ganzen mit prompt Gedanken schon sehr interessant, weil wenn man sich überlegt, ich hab Desktop und Cloud Desktop zeigt dann diese Templates in der UY als kleine Buttons zum Beispiel. Und dann ist es abstrah hier. Das heißt, wenn der MCP Server sein prompt Template ändert, muss ich meine Anwendung nicht ändern. Das heißt, vielleicht bleiben wir bei unserem Wetterbeispiel und unser Wetterservice funktioniert jetzt nicht mehr nur mit Städten, sondern auch mit Postleitzahlen. Und dann hab ich vielleicht abhängig davon, was ich eingebe, muss ich Location collm und dann den Ort wie New York oder Postal Code oder SIP Code und dann Collm. Und je nachdem, was ich vielleicht in der UI als Slider oder so aktiviere, wird dann das andere Template ausgewählt. Und im Hintergrund auf der Hostseite oder kleinen Seite wird dann das Template richtig formatiert und es ist nicht etwas, was der User macht. Also Mhm. Für mich ist der Gedanke, okay, wie kann ich die den Tool Use verbessern anhand mit vordefinierten Templates, die ich als Domain Experte bereitstelle? Aber ja, das ist wie gesagt 99 Prozent, das ist bisher Toolusage.
Fabi: Lass doch grad mal bei Toolusage drauf eingehen. Was wir was wir Grade bei Tools gibt's ja 2 verschiedene Arten, wie diese Server oder genau, nicht nur bei Tools, generell bei Servern vielleicht darauf eingehen, aber es ist dann wird dann Tools am häufigsten genutzt. Es gibt lokale Server und es gibt remote Server, die aktuell, die die es aktuell eine Möglichkeit gibt. So kannst Du, weil ich hab vorhin mal 'n bisschen probiert so, oder hast Du schon gute Beispiele für Remote Services, die's die's da draußen irgendwie gibt? Weil zum, ich bin son bisschen die SPAC durch und hab mir mal angeschaut, okay, was gibt's denn für Server? Was würd ich gern mal integrieren? Direktes, was mir als erstes Beispiel kam, a cool, Google Drive ist einen ist einen Server. Ich kann meine Google Drive halt vielleicht durchsuchen und kann's mit mit verschiedenen Host Applikationen benutzen. Und so, dann hab ich mir, ist direkt erst mal durchgelesen, da gab's nur die lokale Variante von. Das heißt, das musste das lokal konfigurieren. Ich musste erst mal anfangen, irgendwie mir 'n Google Cloud Projekt zu erstellen, mir dann irgendwie einen einen einen einen JSON Token irgendwie erstellen, der dann damit interagieren kann. Ich war direkt schon so, okay, ja gut, wenn das jetzt der Standard ist, wie wie Tools standardisiert werden, dann wird die Zukunft ja rosig.
Philipp: Ich weiß, so ist es
Fabi: nicht so, aber son bisschen, wie ist denn der aktuelle Stand zwischen lokal und remote? Und weil es wird ja wahrscheinlich nicht so bleiben, dass ich auf Ewigkeiten irgendwie mir mein Google Drive lokal irgendwie konfigurieren muss und irgendwie mir im Google Cloud Projekt irgendwelche Tokens erst mal erstellen muss, bevor ich damit interagieren kann.
Philipp: Hoffentlich nicht. Nee, also das das ganze Remote Thema ist langsam am Kommen. Es hängt auch 'n bisschen damit zu sagen, dass MCP halt jetzt im Hype ist und jeder das integrieren möchte. Und dann stellen sich natürlich die Fragen, wie kann ich das irgendwie skalieren? Wie funktioniert Autorisierung und Authentifizierung? Und der initiale Push von Antropic im Release war, man macht das sozusagen über lokale Server, weil dann hab ich mehr oder weniger nur einen User. Also wenn ich's lokal auf meinem Mac sozusagen einen Server ausführ für Google Drive, dann muss ich ja nur mein API key bereitstellen für meinen Google Drive. Sobald ich 'n remote Server hab, hab ich ja das Problem, welchen API key nutz ich? Wie stell ich den API key bereit? Und möcht ich überhaupt API Key von Client zu Server senden? Ist die Klarian wird das, nee, das ist 'n riesen Security Problem. Es gab auch 'n Update im in MCP Ende März, die das ganze Thema 'n bisschen aufarbeitet, weil halt 'n Rieseninteresse da ist. Man hat jetzt oder der der das das definiert jetzt Autorisierung und Security über O-Off. Das heißt, der Gedanke wäre, wenn ich 'n remote Google Drive Server hätte und den erst das erste Mal nutze, Desktop, hey, wann ist meine letzte E-Mail, dann Fabi, dass sozusagen das Modell versucht, hey, ich möchte den MCP Server nutzen. Dann wird aber festgestellt, hey, ich hab kein Token von Fabi, Display wie sone Art Log in with Google UI, dass dann im Hintergrund diese Ooff low passiert und dann der Toolcall durchgeführt wird, sobald dieses Ooff Token bereitstellt. Das ist aktuell am com. Ich hab auch noch nicht so viele, sag ich mal, remote MCP Server Implementierungen gesehen. Denn das beste Beispiel, was ich aktuell halt seh, ist vielleicht bei uns im Unternehmensbeispiel zu bleiben. Ich hab halt irgendwie meine Wetter API, die möcht ich intern bereitstellen. Da brauch ich eventuell kein spezielles Token oder 'n anderes Token. Da kann ich das als HTTP Service bereitstellen über eine URL, die dann nur intern in meinem Unternehmen erreichbar ist. Und dann kann ich sozusagen diese remote Server bei den verschiedenen Anwendungen einbauen.
Fabi: Vorhin in unserer ersten Folge, denn das hast Du das schöne Beispiel mit Visual Worsses, welche ID hast Du hast Du angezapft und gesagt, okay, hier siehst Du jetzt eine Liste von möglichen Servern, die ich anbinden kann?
Dennis: Also das ist VS Code, aber da drin läuft klein, also dieser AI Agent Assistant, den man so als Chatfenster nebendran hat. Und da gibt's eben oben so ein Reiterchen und ein 1 dieser Tabs ist MCP Server. Und da ist eine lange Liste an allen möglichen Servern, die man dann installieren kann.
Fabi: Und genau, da würd mich jetzt der Part interessieren so, ist denn gibt's denn wie eine Art Standard repository, wo sich Server registrieren können so? Oder ist es dann im Endeffekt, wenn ich jetzt meinen Server implementiert hab, ich hab das jetzt toll nach SPAC gemacht und jetzt jetzt kann jeder das integrieren, aber muss ich jetzt Cursor schreiben und schreibe ich jetzt OpenAI und schreibe ich auch noch eine E-Mail an einen Tropic und sag, hallo, ich hab hier 'n neuen Server. Bindet den doch mal in eurer Hostübersicht ein, dass Leute sie einfach konfigurieren und installieren können?
Philipp: Also bisher ist das alles noch son bisschen 'n Community Effort. Also es gibt keine öffentliche Registry wie wie Pipe oder NPM, wo ich dann die Server find. Es gibt viele Third Party Regististries aktuell schon, die halt GitHub scrapen und dann also MCP Server haben spezielle Imports oder Packages definiert und wenn das Package Teil deines GitHub Repository ist, dann wirst Du in die Liste sozusagen mit aufgenommen. Aber hat auch angekündigt, die arbeiten in ihren eigenen Registry, sozusagen dieses Problem zu lösen. Aktuell gibt's halt verschiedene GitHub Repository mit, MCP Servers und so etwas. Aber generell wichtig ist auf jeden Fall, wenn man sich damit jetzt beschäftigt, schaut euch den Code an, weil am Ende hab ich ja Abiturary Code Execution, die entweder auf meinem Client ausgeführt wird oder von jemand anderem.
Dennis: Ja, wenn ihr das gerade macht, hab ich so im im Hintergrund immer so auf.
Philipp: Okay, er. Hab ich jetzt nicht verstanden. Aber ich hab 'n Beispiel gesehen, dass halt irgendwie jemand 'n lokalen MCP Server ausführt, der dann halt im Hintergrund irgendwie dein environment variable File anschaut und irgendwelche Daten wegschreckt. Das heißt, MCP Server ist nicht irgendwie secure by Defour. Das ist immer noch, wenn ich auf Gitapilen Server such, dann wirklich schaut euch das an. Deswegen ist ganz gut, wenn dann etwas arbeitet und eventuell auch halt dieses ganze Community dahinter steckt, wie Open Source halt funktioniert. Dass wenn schädliche, also es wird niemals 'n Google Drive MCP Server, der 10000 Stars hat oder so was geben, der dann plötzlich deine API Keys und dann irgendwelche wilden Sachen damit tut, sag ich mal. Aber ja, man man definiert aktuell noch diese Server selber und bei klein oder bei Cursor oder bei ganz vielen anderen Servern hat man die Möglichkeit, remote Services zu nutzen. Es gibt aber nicht so viele remote Services aktuell. Das heißt, wenn ich 'n lokal Service definieren möchte, ist das meistens 'n N P-X-oder 'n UV-X Befehl, also 'n Python- oder 'n Node, der dann auf meinem Host diesen Server im Hintergrund startet und dann zwischen Klein und Server kommuniziert. Und dann kann natürlich der Server trotzdem irgendwie ins Internet gehen und irgendwie Google anfragen.
Fabi: Ja, cool. Wie ist denn so Serverimplementierung, sonst was jetzt das, was son bisschen das Tooling angeht? Jetzt hab ich ja eine Komponente irgendwie mit LLMs interagiert. So, was wär denn, wenn ich jetzt meinen Server schreib, wie genau teste ich den denn am Ende eigentlich? Muss ich immer eine Beispiel, also muss mir immer eine eigene Host Applikation schreiben, die damit irgendwie interagiert so oder wie würde ich, wenn ich jetzt einen Server baue, gibt's da gibt's da Tooling von vielleicht auch MCP irgendwie zur Verfügung so, son Server zu schreiben?
Philipp: Ja, also ich glaub, das ist halt auch Sie hatten vielleicht am Anfang ganz kurz einen Teil, warum MCP so erfolgreich ist aktuell, weil sie halt diesen Standard haben und sie haben SDKs für viele verschiedene Sprachen mittlerweile, sowohl Client als auch Server für Python, Type Script, Node, Codelin, Sisharb. Es gibt irgendwie Go und Rust unoffiziellally, also Community sozusagen. Es gibt verschiedene Tools, 1 nennt sich Model, Model Inspektor oder Model Kontext Inspektor,
Dennis: wo
Philipp: ich dann meinen Server starten kann und dann sozusagen meinen Server debuggen kann selber. Und man kann halt ganz einfach Tests schreiben. Also man kann wirklich Unitsts schreiben für die verschiedenen Tools und das dann mehr oder weniger lokal testen und ausführen. Und es gibt auch mittlerweile verschiedene Abstraktionslibraries wie Fast MCP. Das habe ich zum Beispiel schon benutzt von in Python. Fast, weil es basiert auf Fast API, was es dann sehr, sehr einfach macht, so einen MCP Server in unter irgendwie 60 Zeilen selber zu schreiben, Mhm. Der dann über Deckerators das Ganze 'n bisschen weg abstrahiert. Dann kann ich einfach sagen irgendwie Tool und dann geborene ich den Namen ein und dann hab ich nur meine Python Funktion und er generier dann dieses JSON SPACK selber.
Fabi: Okay, cool. Wie ist 'n so zum Verständnis von, also ich hab ja zumindest Gefühl nach dem Spiel, ich hab 'n ganz gutes Verständnis zu hören, was das MCP Protokoll irgendwie macht's Du denn? Hast Du noch Fragezeichen so wirklich zu zu der reinen Funktionalität des Protokolls so oder wie wie wie der Flow genau funktioniert?
Dennis: Nee, das ist, glaub ich, okay. Ich ich bin mir noch son bisschen unsicher, also auch wenn das jetzt grade so alles hypt und ich bin mir noch nicht so ganz sicher so als normaler und oder. Für wen ist es gerade so das das Relevanteste? Also wer muss sich darum kümmern? Wer muss vielleicht selbst son Server irgendwie bereitstellen? Wer sollte sich darum kümmern, die Dinger einzubauen und einzunutzen? Wo ist im Moment so der größte Handlungsdrang,
Fabi: den
Dennis: man hat in dem Space?
Philipp: Also ich glaub, wenn man irgendwie 'n Start-up ist und einen Sass API bereitstellt, dann würde ich definitiv 'n MCP Server irgendwie bereitstellen. Also es gibt halt wie gesagt, es gibt die Hosts und Client Implementierer. Da ist dann eher irgendwie ChatGPT, Cloud Desktop, Langchain irgendwie so zu Hause, die es halt möglich machen, verschiedene MCP Servers integrieren und benutzen zu können. Und dann gibt's natürlich die Server Creator und Server Creator sind aktuell Community Member, die existierende APIs hinter 'nem MCP rappen. Also es gibt ganz viele Services schon für Youtube, Google Docs, Google Search, Google Drive, dann halt auch neue MCP Servers wie irgendwie Filesystem, wo ich dann Tools hab, mit meinem lokalen Filesystem irgendwie was machen zu können. Vielleicht eine eigene Sandbox, wo ich dann Python Code ausführen kann, Secure, was beim LLM Kontext halt nicht funktioniert. Das ist halt auf jeden Fall so die eine Seite. Und ich muss selber schon sagen, wenn man Agents an sich aktuell baut, würde ich mir das definitiv anschauen, weil ich werd nicht nur ein Agent bauen und ich werd auch nicht das einzige Team sein in meinem Unternehmen, die in Zukunft irgendwie MCP Server bauen. Und ich habe halt immer diesen Boilerblade oder Implementierungsaufwand von, ich möchte jetzt irgendwie Google Suche integrieren oder vielleicht noch 'n besseres Beispiel, ich möchte irgendwelche Vektordatenbanken irgendwie integrieren als Teil von meinem Flow oder ich möchte irgendwelche Self Verification Checks machen, die dann noch mal 'n LLM oder so was ausführen oder irgendwelche eigenen Guardrails Checks, dann vermeide ich einfach dieses, okay, jeder implementiert immer und immer und immer wieder dasselbe. Und ich fand's halt super hilfreich. Also zum Beispiel einen MCP Server, den ich echt cool fand und gern genutzt habe bisher als Fetch MCP, der einfach nur die Möglichkeit bietet, dass das Modell eine HDTP Link aufruft und das Ergebnis zurückbekommt und dann einen Teil von dem Model. Das heißt irgendwie, wenn ich irgendwie eine Dokuseite hab, dann möchte ich gern, dass das Modell einfach den Kontext liefert. Und bisher macht man ja immer irgendwie Command-a, Command-c und kopiert es dann irgendwie in den in den Kontext mit rein. Und so kann halt das Modell dynamisch anhand von der Suche oder was halt zurückkommt, immer wieder mehr verschiedene HTTP Requests durchführen.
Fabi: Weil sich sozusagen selbst selbst durchklickt.
Philipp: Genau. Und weil es halt selbst versteht, hey, okay, er fragt mich etwas drüber, wie Feature X funktioniert. Ah, okay, auf der aktuellen Seite finde ich nicht Feature X, aber hier ist ein Link, der eventuell zu Feature X führt. Lassen wir den Link zu Feature X aufführen. Okay, hier ist die Antwort, okay. Dann habe ich halt so dieses diesen Agentic Loop, der halt versucht, diese Userantwort zu generieren.
Fabi: Wo hast du bei welchem Host hast du diesen Server eingebunden?
Philipp: Ich habe es in Cursor eingebunden und ich habe dann verschiedene Anwendungen auch gebaut. Also sehr hyped, das heißt jedes Agent SDK Tool unterstützt es mittlerweile. Ich habe einen Langcraft Agent gebaut und dann halt auch wirklich handrolled. Wie kann ich einen MCP Server in eine normale kleinen SDK einbinden, dass ich diese Konvertierung von diesen JSON SPAC macht, dann den Call danach, Server Ausführung. Ist einfach ein bisschen besser zu verstehen. Aber ich glaube generell, ich würde fast so weit gehen und sagen, wenn ich ein Agent Aktuell Bo, der Function Calling nutzt, würde ich nicht mehr diese Tools roh implementieren, sondern lieber immer einen MCP Server, weil den kann ich dann Es ist nicht so, dass ich dann irgendwas mich blockiere, sondern einfach es macht es, würde es in Zukunft einfacher machen und maintainable oder ich kann es besser in meinem Unternehmen oder in verschiedenen Bereichen teilen. Oder ganz oft wird es auch der Fall sein, dass ich ein Tool von einem Agent 'nem anderen Agent wieder nutze. Und wenn ich es halt im MCT Server hab, kann ich einfach starten, loslegen und halt meine Anwendung bauen.
Dennis: Okay. Und als Dev kann man letztendlich in den Hosts, die es schon gibt, msc Server nutzen, einfach einfach, einfach einfacher, einfache Dienste anzubinden, unterschiedliche Funktionalitäten dann zu nutzen für sich selbst.
Philipp: Genau, wenn Du, ich sag mal, wenn Du ganz wild bist und jetzt anfängst, Du schreibst 'n MCP Server für Gmail, könntest Du in Curse, in dem Agent Mode den integrieren und dann eine E-Mail darüber verschicken. Wenn Du ihn halt prompt hast, hey, schreib bitte eine E-Mail an Fabi, was auch immer. Und der Kontext soll das und das sein. Such bitte noch in dem und dem Pfeil, dann würde halt Curcel wie bisher bei Fileupdates halt am Ende diesen Tool Call machen mit Cent E-Mail und dann würde halt die E-Mail rausgehen.
Dennis: Mhm. Mhm.
Fabi: Ja, ist halt immer, wenn man son bisschen Größenskalierung soll, weil Du hast ja vorhin gemeint, was früher einen m mal n Problem war, ist jetzt dann m plus n, wobei jetzt ja n die Server sind, wo ich jetzt mal ausgehen würde, weil Du meintest, also das sind so typische Ja. Alle, die eigentlich eine, 'n API Produkt anbieten, können sich eigentlich darauf einstellen, dass sie auf kurz oder lang wahrscheinlich auch einen MCP Server irgendwie anbieten werden. So, von daher geh ich aus, dass die Größe n wahrscheinlich relativ groß wird. Wie groß die Größe m, also diejenigen, die diese Server, die die Host Applikationen schreiben oder klein schreiben, würde ich jetzt mal tippen, ist wahrscheinlich tendenziell eher 'n Ticken kleiner. Es werden die großen Anbieter sein, die die im Endeffekt LLM Applikationen oder Chatinterfaces für ihre LLMs bauen. Es werden irgendwie IDIs sein und es werden die oder sind die Leute, die grundsätzlich einfach Agents entwickeln. Wo ich mal davon ausgehen würde, es wird eine, also die die großen Anbieter werden mit wenigen Händen vorher wahrscheinlich abzuzählen zu sein. Und die Agents werden wahrscheinlich auch insgesamt weniger sein als die Server, die die hinten dran gebaut werden. Aber das bin ich mal gespannt so irgendwie, wie viele, so so von der Größen Skalierung her würd ich wahrscheinlich sagen, es wird mehr Server geben, als es Hosts gibt, aber das wahrscheinlich auch nur sehr mit meinem sehr kurz gegriffenen Horizont darüber gedacht.
Philipp: Ich kann mir ganz gut vorstellen, dass in der Zukunft eventuell ganz viele Agents selber bauen, zusammenklicken und niemals 'n MCP Server selber schreiben. Also das ist halt wirklich, hey, ich hab hier irgendwie eine coole, eine coole coole Idee. Ich möcht für unser Unternehmen, weil wir klein sind, 'n Slack Bot schreiben oder 'n Slack Agent schreiben, der irgendwie die Möglichkeit hat, irgendwelche Invoices zu generieren und dann per E-Mail zu schicken. Irgendwie so was. Oder ich möchte irgendwas definieren, was dann vielleicht am Ende nachher nicht reactive bis de deployed wird. Und das kann ich halt alles abstrahieren, die verschiedenen Tools in verschiedenen MZT Server und die Wahrscheinlichkeit ist relativ hoch, dass wenn ich Stripe nutzt oder ich weiß nicht, oder andere Dinge, dass die irgendwann einen MCP Server bereitstellen und ich einfach nur sozusagen meine Systeminstruktionen zusammen definieren muss und das Prompt Engineering und das hat alles zusammen funktionieren und dann diesen Agent sozusagen testen kann, ohne dass ich jetzt die Implementierung für Stripe, für Slack, für halt die ganzen Tools schreibe, die ich schon nutze. Und dann natürlich halt, wenn ich interne Services und API miteinander verknüpfen möchte.
Fabi: Okay. Vielleicht ist es tatsächlich
Dennis: auch son Gedankengang, wenn man also ja, dieses Agentengetriebene, wo jetzt vielleicht heute wir noch nicht so im Alltag immer in so einzelnen Agenten denken. Aber ich glaube, das
Fabi: wär so was, was Ich hab grad ich hab grad mein mein Gedanken kam direkt, aber er ist nicht groß zu Ende gedacht, sodass ich grad wieder mal CI Chain für 'n neues Projekt bei uns aufsitzen sozusagen, Release Automatisierung sozusagen und wo ich mir auch, da sind's halt verschiedene NPM Skripte, die ich irgendwie ausführen kann, die ja im Endeffekt auch nichts anderes sind als Templates und bestimmte Services aufrufen. So vielleicht, also auch wenn ich jetzt das ja relativ standardisiert sind, meistens die gleichen Anfragen sind's, aber es sind irgendwie alles Use Case, wo man wahrscheinlich anders drüber nachdenken kann, wenn ich im Endeffekt den Release dann eben nicht mehr über meinen über meine NPM Skripte in unserem Fall mache, sondern einfach im Team es 'n SlackBot gibt, keine Ahnung, auch der Game, die dann einfach sagen kann, hier, mach mal mach mir mal 'n Test von von der oder machen wir nur eine Test Flight Version von unserer aktuellen App so und einfach damit interagieren kann. Du könntest schon
Philipp: Ja und der Gedanke hier wär ja, dass die Tools, die SATACHEN dann nutzt, nicht ihr alles schreiben müsst. Ja. Also wenn dann irgendwie Apple, App Flight, MCP bereitstellt, wo ich so was aktivieren kann oder Slack Nachrichten und GitHub gibt's ja schon, dass ich halt irgendwie halt die darüber die Dinge mehr steuern kann. Also der Gedanke ist nicht, dass sozusagen die Arbeit wegfällt, sondern dass halt die die Implementierungen standardisiert werden und einfacher wiederverwendbar werden. Und ich sehe, also das typische Beispiel finde ich, ist immer halt so dieses Einkauf Sales Procurement irgendwie, dass ich halt irgendwie E-Mails lese, eventuell was in meiner Datenbank prüfe, dann eventuell warte oder halt verschiedene andere Konditionen hab, die erfüllt werden sein müssen. Wenn irgendwas nicht erfüllt ist, schick bitte Dennis eine E-Mail, dass er das nachschauen soll. Das ist 'n Agent, der irgendwie auf Chrome Basis läuft und die ganzen Tools, die er nutzt, halt standardisiert sind und ich halt nicht immer neu umsetzen muss. Und den der Vorteil, der halt dann darüber kommt, ich hab wieder eine viel viel geringeren Aufwand, son Agent umzusetzen, weil ich halt nicht alle Tools selber implementieren muss und dann eventuell viel mehr diese Tools am Ende einsetzen kann. Weil die Google API ist jetzt nicht irgendwie so cool, selber umzusetzen für manche Services. Und wenn ich da halt irgendwie erst mal 2 Wochen verschwenden muss, die ganzen Tools zu definieren, dann ist es halt auch wieder die Frage, hey, macht es Sinn, diesen Agent zu bauen?
Fabi: Ja. Ja, super cool. Dann bin ich mal gespannt. Also grade dieser dieser Punkt mit bin ich hier auf jeden Fall gespannt, wie lang es dauert Also ich mein, irgendwas wird ja kommen müssen für diese Server, 'n Server repository.
Philipp: Ja, Antropic hat schon angekündigt, die arbeiten an einem.
Fabi: Mag schauen, wie lang wie lang das wie lang das dauert und was so die ersten Sinne. Und grade was Du sagst, so ich glaub, also zumindest, ich mein, im Endeffekt, ich hab ja, wir haben ja oft die Dennis und ich irgendwie auch unsere so, was endet das in unserem Development Alltag son bisschen so? Also den den Blickwinkel darauf und so, das würd ich schon sagen, damit es da damit die Server da etwas ändern, dass ich jetzt dann Agent entwickelt, bin ich schon sehr gespannt auf. Also wenn ich im Endeffekt all diese persönlichen Datenquellen so einfach anbinden kann und in verschiedenen Host Applikationen einbinden kann, ja, und das ist 'n einfacher, bin ich da schon mal mehr hyped? Ich glaub, vielleicht das ist
Philipp: so ein bisschen wie mit generell AI Use Cases und wenn ich jetzt eine Prediction abgeben müsste, würde ich halt sagen, die Leute, die halt irgendwie sich überlegen, wie sie ihre Arbeit verbessern und automatisieren können mit AI profitieren sehr stark von MCP, weil halt die typischen repetitiven Aufgaben, die man halt hat, doch über API Tools irgendwie getrieben sind. Also keine Ahnung, alle meine E-Mails lesen, filtern, raussuchen, wem muss ich antworten, irgendwelche Slack Nachrichten beantworten, irgendwas triggern, was dann was automatisiert. Das nutzt alles standardisierte API Schnittstellen im meisten Fall. Und wenn halt für alles dieses eine Server ist, dann kann halt auch der Non Expert Developer halt plötzlich sagen, hey, cool, ich setze mich halt in den Nachmittag hin und automatisier oder versuche 'n Stück dieses Prozess zu automatisieren. Wenn ich die erste Beispiel für meinen Slack Chatbot hab, der irgendwas kann, vielleicht baue ich dann plötzlich 10 verschiedene Slack Chat Bots. Manche können sich vielleicht gegenseitig aufrufen und dann agier ich halt oder nutze ich halt die Technologie und bin nicht mit diesem typischen Softwareentwickler beschäftigt, der halt, hey, lass mal erst die Technologie bauen und dann wie kann ich es irgendwie nutzen? Und da find ich halt die die Appserhöhung sehr cool.
Fabi: Ja, ist auch grade, wenn Du halt dein Beispiel gerade noch mal lieferst mit den verschiedenen Slack Chat Bots und wenn's dann wirklich einfacher wird, dann ist meine Prediction, die ich am Anfang gemacht hab, wo n die Server mehr sein werden als MD Clients, geht sehr schnell nach hinten los. Und ich glaube, ich bin einfach nur noch nicht kreativ genug, in welchen Use Cases sich alles so ganz viele kleine Agents baut. Ich mein, mit den ganzen Use Cases, da brauchen wir uns nicht so fragen, dass m sehr viel größer wird als n. Und Ich mein, ich mein,
Philipp: das ist ja wie bei allem, wenn ich die Eintrittsbarriere verringern kann, dass ich's mehr Menschen und allen ermöglichen, davon zu profitieren und diesen diese abstrahierte Tools zu bauen, umso mehr Leute kann ich erreichen und umso mehr wird es genutzt selbst in
Fabi: Ja, ich mein, ich glaub, wenn wir uns jetzt gerade so oft drüber unterhalten haben, ist, glaub ich, MCP wirklich eine grundlegende sehr gute Veränderung für den AI Space. Man muss sich fast fragen, warum diese Form von Standardisierung so lang gedauert hat, so oder warum Leute, die an der Agent oder Agent Standardisierung wie Langchain oder so was Leute gearbeitet haben, nicht auch früher so einen Schritt gegangen sind. So, warum hat so lang, warum hat so lang gebraucht? Und dort der fragt, warum dauert's jetzt 4 Monate, dass wir 'n Deep Dive darüber machen? Warum ist der Hype erst jetzt da?
Philipp: Ja, ich wär da ganz argvorsichtig, weil ich glaub, man vergisst immer 'n bisschen den Zeithorizont HTTP ist jetzt auch nicht von heut auf morgen entstanden oder das Internet funktioniert ja heute auch nicht so wie vor vor 20 Jahren. Da ist immer ganz, ganz viel mit Entwicklung dabei und ganz viel Learning by Doing. Also vor 'nem halben Jahr wusste man ja eventuell noch gar nicht, brauche ich das überhaupt? Und ja, jeder baut sein Agent und implementiert halt seine Tools. Warum brauch ich da irgendwie eine Abstraierung? Und Langchain und andere haben ja eine Abstraierung sozusagen mit eingeführt. Warum brauch ich jetzt sozusagen diesen Split zwischen Server und anderes? Und wie gesagt, ein großer Teil für den Hype ist halt MCP hat eine sehr, sehr gute Spezifikation, was halt jetzt ermöglicht, anderen die Themen zu verstehen und teilzunehmen. Also es ist ja jetzt so, dass Google, Open AI und Antropic alle sozusagen sich damit beschäftigen und es verschiedenmäßig zu implementieren. Und auch Antropic hat selber gesagt, dass sie das als Open Open Source Standard umsetzen wollen. Das heißt, dass andere höchstwahrscheinlich Teil von 'nem Komitee werden und halt darüber diskutieren, was ist die nächste Funktion? Also es ist nicht dieses, ich entscheide, wie es umgesetzt wird und ich definiere das, sondern es ist der Gedanke wirklich von 'nem Open Protocol, was halt wirklich das Web irgendwie 'n bisschen erfolgreich gemacht hat. Und dann halt 'n Hype, den man halt Da muss man halt manchmal Glück haben.
Fabi: Ja. Und ich mein, find Spezifikationen klingt immer erst mal son bisschen abschreckender, aber es ist wirklich also auch sehr zugänglich geschrieben und so so geschrieben und so so kann man sich auf jeden Fall mal anschauen. Es gibt einmal die UserGuide Variante und die Spezififikationsvariante und also fand's auf jeden Fall 'n guten Also ich hab parallel zu Philips Blogpost noch mal darüber auch die mir anguckt. Und ich muss sagen, manche Stellen waren ähnlich zugänglich geschrieben so. Von daher ist eine echt gute gute Homepage.
Dennis: Gab's Du, hat da jetzt einen Vorteil von? Ist das cool, dass das von denen kam oder ist einfach nur irgendwie son schöner Erfolg, dass es 1 sich auf die Open Source vorne frei schreiben kann?
Philipp: Ich glaub, sie werden, egal wie's ausgeht, schon sehr großen Anteil damit haben, wie MCPs sich weiterentwickelt. Sie werden natürlich zuhören und ich glaub, wenn sie's wirklich ernst nehmen, dann wird es wie sone Art Demokratie einfach, dass halt jeder seine Meinung dazu haben kann. Aber es wird immer von Antropic sein. Also das wird denen niemand wegnehmen, dass MCP von Antropic kommt und ist halt auch, ja. Also ein bisschen wie vielleicht Kubernetes und Google. Kam ja ursprünglich von Google und jeder weiß, dass es irgendwie von Google kommt, aber umso länger oder umso mehr das Kubernetes ein Standard geworden ist oder auch jetzt in die Linux Foundation oder Cloud Native Foundation gewechselt ist, umso weniger hat man diesen Google Kontext und so eventuell könnte sich MCP auch entwickeln. Aber aktuell sind wir halt wirklich noch sehr, sehr am Anfang. Und es bleibt auch abzuwarten, ob das Protokoll wirklich das Richtige ist oder wir in 2 Monaten merken, dass es halt doch irgendwie nicht klappt. Ist auf jeden Fall 'n richtiger Schritt und es ist das erste Mal seit eineinhalb Jahre, wo wir irgendwie Agents bauen, dass sich alle son bisschen einig
Fabi: sind. Sehr cool. Klingt dann am schönen Abschlusssatz, oder? Hast Du noch Fragen, Dennis?
Dennis: Nee.
Philipp: Wann wird's den ersten Lotum MCP Server geben?
Fabi: Was willst Du was willst Du anbinden? Willst Du
Philipp: Ja, in dem natürlich, dass euer Spiel mit LLLM Input funktioniert.
Fabi: 4 Bilder ein Wort, Ressourcen ausgegeben, ja, müsste Es
Dennis: müssen kreativ sein. Oder erst mal 'n bisschen neu denkbar.
Fabi: Ich sag mal so, bisher hatten noch auch noch keine, es gibt ja auch keine API von uns. Von daher ist die Strafe.
Philipp: Ja, aber das ist ja nicht eine Anforderung. Also das das ich glaub ein ein Teil, den wir vielleicht nicht erwähnt hatten, ist, wenn MCP nur aktuelle APIs abstrahiert, wird es nicht erfolgreich sein. Also es müssen auch Use Cases mit integriert werden, die aktuell noch nicht sind. Und wir müssen Incentive sozusagen schaffen, dass selbst 'n Uber einen Server bereitstellen möchte. Weil Uber ist ja 'n sehr eingeschlossenes Ecosystem. Und wenn man das jetzt irgendwie von Customer Journey aus betrachtet oder Business aus betrachtet, würde ja viel lieber Uber gern den Flow kontrollieren, wie man ein Auto bestellt und halt nicht das U-Bahn MCP Server Expos, das dann ich plötzlich über ChatGPT mein Uber Auto bestellen kann, weil dann ist der Kunde auf der ChatGPT Seite und ChatGPT hat mehr Macht im Sinne von, hey, wenn halt nicht Uber, dann nutz ich halt Lift oder spiel dann Lift gegen Uber aus und drücke irgendwie die Preise son bisschen. Deswegen bleibt's definitiv abzuwarten.
Fabi: Ja. Ja klar, aber ich mein, ja. Business Case ist auf jeden Fall sehr interessant dann raus, wenn ich meine, aber da ist ja auch so Uber hat dann Ich mein, wenn Uber 'n Service bereitstellt, Server bereitstellt, dann hat's ja auch seinen Ohrflow oder wie auch immer. Man ist mit seinem Account mit drin. Wenn man 'n Auto bucht, hat man direkt durch die Abbuchung über Uber und so was. Und ich mein natürlich bei, also, wie willst Du 'n Game machen? So klar, kannst 'n kleines Game dann erst mal bauen, sondern dann trennen sich trotzdem sozusagen die nächsten Fragen. So, wie ist denn, was ist denn das Businessmodell dahinter, also Game zu bauen, ne? Und dann sind die Businessmodelle, die Du hast, Inner Purchces oder Werbung. So Werbung wird wahrscheinlich im LLM als Function Call und jetzt bitte zeigen 30 Sekunden Werbung an hier. Kannst Du ein revolded Video dir in deiner Chat GPT Applikation
Philipp: Genau. Dafür im Sales Calls. Ad
Fabi: mob Ad mob hat auch 'n Server, der dann der dann also Ressourcen revolded Videos zurückliefert oder keine Ahnung, wie machen wir in der Purge Ja,
Philipp: aber 'n Beispiel, das mir jetzt spontan kam, wo ihr 'n Vorteil hättet von 'nem MCP Server zum Beispiel. Ich weiß nicht, wir nehmen einfach jetzt mal Schach. Ich hab das Spiel Schach und ich hab ja verschiedene Aktionen, die ich durchführen kann als Tools irgendwie. Ich hab irgendwie Move Figur und dann hab ich halt die Figur, die ich bewegen möchte und dann halt das Feld und ich bekomm halt wieder diesen State zurück. Was man jetzt natürlich machen könnte, ich könnte diesen MCP Server auf meiner Handy App einbauen, dass ich auf meiner App dann halt einfach nur diese Calls ausführe. Aber im gleichen Zug könnte ich halt 'n AI Agent haben, der automatisiert läuft, der halt auch diese Tools ausführt. Das heißt, ich könnte gegen eine KI spielen und wir beide nutzen dasselbe Interface. Oder ich hab halt nicht mein mein Button System, das auf meiner App ist, sondern ich hab eventuell 'n Voice Input, das ich spiele. Und dann habe ich 'n LLM Call, der dann wieder diese Tools ausführt. Also ich glaub, man kann sich da schon Gedanken machen. Man muss halt 'n bisschen weggehen von dem, welche Spiele habe ich aktuell?
Fabi: Ja. Oder wie Du sagst, im Endeffekt kann's ja auch eine Voice Integration deines Spiels sozusagen sein, sodass Du eben nicht mit der App per Touch interagieren kannst, sondern einfach per Voice. Und es ist einfach 'n Agent, der in deine App eingebunden ist. Und so kannst Du's auf verschiedene Weisen steuern, weil der Server sowohl von dem Touch Input als auch von dem LLM oder dem dem Voice Input gesteuert werden könnte.
Dennis: Genau.
Philipp: Ja, ist auf
Fabi: jeden Fall eine neue interessante Art darüber nachzudenken und die Zugänglichkeit auf jeden Fall erhöhen wir an vielen Stellen so.
Dennis: Jo. Cool. Vielen Dank Philipp. Gerne. Jetzt wo wir uns überall liest, dass wir mal 'n bisschen einen Einblick bekommen haben und bisschen mehr mit anfangen können. Gucken wir mal, was die Zukunft bringt, ob wir bald über ein neues Protokoll sprechen müssen oder ob sich dann doch durchsetzt.
Fabi: Werden die auf jeden Fall zuerst dann in den AI News hören.
Dennis: In den AI News hören.
Philipp: Oder dann 4 Monate später wie beim Ins High bist. Genau.
Fabi: Fabi, schön, dass Du wieder da bist. Dennis, Philipp hat Spaß gemacht mit euch.
Dennis: Podcast at Programmier Punkt bar, falls ihr Feedback loswerden wollt, Sonst eine ganz schöne Zeit und Philipp haben am Anfang gefragt, ob er Pick of a Days heißt.
Philipp: Ja, ich glaube jetzt kein, aber
Fabi: Du darfst was, Du darfst
Dennis: gerne. Genau.
Philipp: Ist vielleicht jetzt kein direkter Pick of a Day, aber definitiv eine große Empfehlung und zwar Late Space ist 'n Podcast, englischsprachig auch im AI Bereich Und sie haben vor 2 Wochen eine Podcastfolge mit den Creatoren auf MCP sozusagen veröffentlicht. Große Empfehlung, wenn euch das Thema wirklich interessiert, da sie gehen auch 'n bisschen darauf ein, wie sie das Protokoll umgesetzt haben, warum es Tools, so Resources und Prompts gibt. Vielleicht einfach noch mal eine zusätzliche Meinung. Sehr cool auf jeden Fall und auch 'n bisschen, was so die Pläne sind.
Dennis: Kann man einfach euch erklären?
Philipp: Ja, also man hat im KI Bereich, was ja diese Dimension, das ist einfach son n-dimensionaler Vektor mehr oder weniger. Also die Fusion Modelle agieren ja auch in dem Space und deswegen kommt es daher.
Dennis: Okay. Okay. Weil irgendwie, 'n Kollege hat den das heute benutzt. Ich wusste gar nicht genau, was er damit meinte. Welchen Zugriff? Problem des, okay. Du kannst
Philipp: da jetzt 'n MCP Server oder 'n Agent bauen, der 'n MCP Google Server integriert hat und dann mit ihm chatten.
Dennis: Oder oder googeln.
Fabi: Oder die andere, ihr habt's.
Dennis: Oder Google
Fabi: oder Chature. Gäng ich nicht.
Dennis: Gugguru, was? Cool. Vielen, vielen Dank. Bis ganz bald. Mach's gut.
Philipp: Tschau. Tschüs. Tschau.

Model Context Protokoll (MCP) mit Philipp Schmid

Shownotes

Speaker Info

Philipp Schmid