Ja, die Aussage kommt in der aktuellen KI-Hype-Gesprächslage ja fast einem Selbstmord gleich, aber ich will kurz erklären, warum wir bei HybridAI zu dem Schluss gekommen sind, erstmal keinen MCP Server einzurichten oder anzusprechen.
MCP-Server sind ein (man muss vll. sagen derzeit noch „gewollter“) Standard der von Anthropic entwickelt und gepusht wird und derzeit extrem viel Wiederhall findet in der AI-Community.
Bei einem MCP-Server geht es darum die für aktuelle „agentic“ KI-Anwendungen so wichtigen Tool-Calls (oder „function-calls“) zu standardisieren, also genaugenommen die Schnittstelle vom LLM (tool-call) zur Schnittstelle des externen Service oder Tools, meist irgendeine Rest-API oder so.
Bei HybridAI haben wir ja schon lange auf eine starke Implementierung von function-calls gesetzt, insofern können wir auf ein paar dutzend implementierte und in Produktion befindlicher function-calls zurückschauen die von inzwischen mehr als 450 KI-Agents teilweise genutzt werden. Also schon ein bisschen Erfahrung in dem Thema. Wir nutzen auch N8N für bestimmte cases, das ist nochmal ein Layer auf dem Thema, der relevant ist im praktischen Alltag. Unsere Agents haben auch APIs nach aussen über die sie angesprochen werden, wir kennen das Problem also sogar in beide Richtungen (d.h. wir könnten sowohl einen MCP Server einrichten für unsere Agents als auch andere MCPs abfragen in unseren function-calls).
Also warum finde ich dann MCP-Server nicht total cool?
Ganz einfach: er löst ein Problem das es mE kaum gibt und lässt die zwei viel wichtigeren Probleme bei function-calls und damit agentischen Setups ungelöst.
Erstmal: warum gibt es das Problem der zu standardisierenden Fremd-Tool APIs eher nicht? Das hat zwei Gründe. (1) bestehende APIs und Tools haben meistens REST-APIs oder was ähnliches, also eine bereits standardisierte Schnittstelle. Diese ist zudem ziemlich stabil was man allein daran erkennt dass viele API-URLs noch ein „/v1/…“ im Aufruf haben oder vielleicht auch schonmal „/v2/…“. Aber die sind eigentlich sehr stabil und gut ansprechbar. Selbst wenn es neue Interfaces gibt, bleiben die alten Endpoints oft online für sehr lange Zeit. Und noch ein Punkt: gerade ältere APIs sind oft spannend, also z.B. die API der ISS oder die des europäischen Patent-Amtes oder die irgendeiner Open-Data API einer Stadt. Diese Services werden auch nicht so schnell MCP-Interfaces dafür anbieten – ergo muss man sich eh mit den alten APIs rumschlagen noch sehr lange. Dazu kommt Punkt (2), und bei dem wundert es mich ein bisschen mit dem MCP-Hype. Denn LLMs sind eigentlich ziemlich cool darin alte APIs abzufragen, viel cooler als andere Systeme die ich da schon kennengelernt habe – denn: man schmeisst ja den API-Output eigentlich nur in das LLM rein und lässt es antworten. Kein Parsing, kein Error-Handling, keine XML-Syntax durchdringen. Macht alles das LLM und das ziemlich reliable und fehlertolerant. Also wozu eigentlich der MCP-Server um das zu abstrahieren?
Also, MCP löst ein Problem (und fügt ja einen weiteren Tech-Layer hinzu), das eigentlich im realen tool-calling Alltag gar nicht so groß ist.
Größer sind dafür folgende zwei Probleme die wirklich nervig sind und andere Lösungen bräuchten in der nahen Zukunft:
–> Tool-Auswahl
–> Tool-Execution und Code-Security
Tool-Auswahl: Agentische Lösungen zeichnen sich ja dadurch aus, dass mehrere tools, ggf. sogar sequentiell verschaltet werden können und das LLM selbst entscheiden kann, welche es nimmt und in welcher Kombination. Wie das abläuft kann man mühevoll mit der Beschreibung des Tools beeinflussen, das ist quasi ein kleiner Mini-Prompt der die Funktion und Ihre Argumente beschreibt. Und da kann es sehr schnell ziemlich drunter und drüber gehen. Wir haben z.b. einen Tool-Call der Perplexity aufruft bei Anfragen mit aktuellem Bezug („wie ist das Wetter heute…“). Oft called das LLM den aber auch, wenn irgendwas anderes gefragt wird was ein bisschen komplizierter ist. Oder es wird der Tool-call für die WordPress-Search-API getriggered, obwohl wir eigentlich die Web-Search über GPT-4.1 mit Websearch haben wollten. Diese Baustelle empfinde ich als ziemlich messy aktuell und das soll ja noch viel autonomer und komplexer werden. Wie die LLMs mit verschiedenen tools umgehen unterscheidet sich auch noch signifikant, aber nicht sehr deterministisch und schlecht dokumentiert.
Tool-Execution: Ein richtig fettes Problem auch für Skalierung aber eben auch Security steckt in der eigentlichen Tool-Code Execution. Denn die – das wissen viele nicht – findet ja lokal auf Deinem eigenen System statt. D.h. eigentlich müssten wir bei HybridAI unseren Kunden anbieten uns Code anzuliefern, der dann als Tool-Call für sie hinterlegt und aktiviert und eben auch ausgeführt wird, wenn das LLM es will. Das ist aber hinsichtlich Code-Integrity, Plattform Stabilität und Sicherheit ein ziemlicher Albtraum (wer jemals ein WordPress-Plugin eingereicht hat weiß, wovon ich rede). Aber das ist ein sehr wichtiges Problem, das übrigens noch viel größer wird, wenn der „Operator“ oder das „computer use“ tool stärker verwendet werden – denn auch die laufen lokal ab und nicht bei OpenAI.
Für diese beiden Probleme hätte ich gerne Ideen, also vielleicht ein TOP (Tool-Orchestration-Protocol) oder ein TEE (Tool Execution Environment). Aber einen MCP brauchen wir erstmal nicht.
