Sprachmodelle können Texte analysieren, Code schreiben, Zusammenhänge erklären und Aufgaben planen. Trotzdem besitzen sie zunächst eine entscheidende Einschränkung: Sie können außerhalb ihres eigenen Modells nichts tun. Ein Sprachmodell weiß vielleicht genau, mit welchem PowerShell-Befehl ein Windows-Dienst neu gestartet wird, wie eine Datenbank abgefragt werden müsste oder welche Datei in einem Projekt verändert werden sollte. Ohne zusätzliche Schnittstellen kann es diese Aktionen aber nicht selbst durchführen.
Damit aus einem Sprachmodell ein tatsächlich handlungsfähiger Assistent wird, benötigt es Zugriff auf Werkzeuge, Daten und Anwendungen. Genau an dieser Stelle setzt das Model Context Protocol, kurz MCP, an. MCP definiert eine standardisierte Kommunikationsschicht zwischen einer KI-Anwendung und externen Fähigkeiten. Diese Fähigkeiten können sehr unterschiedlich sein: Dateien, Datenbanken, APIs, Git-Repositories, lokale Programme, Unternehmensanwendungen oder ein Terminal.
Die grundlegende Idee ist einfach: Eine KI-Anwendung muss nicht für jedes Werkzeug eine eigene Integrationslogik besitzen. Sie spricht MCP, und MCP-Server stellen ihr die jeweiligen Fähigkeiten in einer standardisierten Form zur Verfügung. Damit könnte MCP für KI-Anwendungen eine ähnliche Bedeutung bekommen wie standardisierte Schnittstellen in anderen Bereichen der IT. Nicht weil MCP bestehende APIs ersetzt, sondern weil es eine gemeinsame Sprache zwischen KI-Anwendungen und diesen bestehenden Systemen schafft.
Das eigentliche Problem: Ein LLM kennt die Welt, kann sie aber nicht bedienen
Betrachten wir zunächst einen normalen lokalen Chat mit einem Sprachmodell. Der Benutzer schreibt beispielsweise: „Prüfe, warum mein Webserver nicht läuft.“ Das Modell kann auf Grundlage seines Trainingswissens eine sinnvolle Prüfsequenz vorschlagen: Dienststatus prüfen, laufende Prozesse analysieren, Konfigurationsdateien ansehen, Logeinträge lesen und prüfen, ob der benötigte Port belegt ist.
Das ist hilfreich, bleibt aber passiv. Der Benutzer muss jeden Schritt selbst ausführen und die Ergebnisse wieder in den Chat kopieren. Ein Agent mit Werkzeugzugriff kann dieselbe Aufgabe dagegen selbstständig in technische Einzelschritte zerlegen, den Dienststatus abfragen, Logdateien einlesen, Ports prüfen und die Ergebnisse wieder in seine weitere Analyse einbeziehen. Der Unterschied zwischen beiden Systemen liegt damit nicht zwangsläufig im Sprachmodell selbst, sondern vor allem in der Frage, welche Werkzeuge das Modell erreichen kann.
MCP beschäftigt sich genau mit dieser Verbindung zwischen Modell und realer Umgebung.
Ein einfaches Bild: MCP ist wie USB-C für KI-Werkzeuge
Für einen ersten Zugang kann man MCP mit einer standardisierten Geräteschnittstelle vergleichen. Früher benötigten Geräte unterschiedliche Kabel, Stecker und Treiber. Eine standardisierte Schnittstelle reduziert diese Vielfalt und ermöglicht es, verschiedene Geräte über einen gemeinsamen Mechanismus anzubinden.
Bei KI-Anwendungen existierte ein ähnliches Problem. Eine Anwendung benötigte beispielsweise eine spezielle Integration für GitHub, eine andere für eine SQL-Datenbank, eine weitere für das Dateisystem und wieder eine andere für ein Terminal.
Die KI-Anwendung muss nun nicht mehr jede einzelne Gegenstelle auf proprietäre Weise verstehen. Sie versteht MCP. Die jeweiligen MCP-Server übersetzen anschließend zwischen MCP und dem dahinterliegenden System. Diese Analogie ist hilfreich, hat aber eine Grenze: MCP ist kein physischer Bus und auch kein einzelnes Produkt, sondern ein Protokoll und eine Architektur für den Austausch zwischen KI-Anwendungen und externen Fähigkeiten.
MCP ersetzt bestehende APIs nicht
Eine der wichtigsten Abgrenzungen lautet: MCP ersetzt REST, SQL, PowerShell oder andere bestehende Schnittstellen nicht. Ein MCP-Server kann intern weiterhin eine REST-API verwenden, eine Datenbank abfragen oder ein Kommandozeilenwerkzeug aufrufen.
Typische Ketten sehen beispielsweise so aus:
LLM
↓
KI-Anwendung
↓
MCP
↓
GitHub MCP Server
↓
GitHub REST API
oder:
LLM
↓
MCP
↓
Datenbank-MCP-Server
↓
PostgreSQL
Bei einem lokalen System kann derselbe Mechanismus so aussehen:
LLM
↓
MCP
↓
Terminal-MCP-Server
↓
PowerShell
↓
Windows
MCP sitzt damit typischerweise oberhalb vorhandener technischer Schnittstellen. Es standardisiert die Sicht der KI auf diese Systeme. Das ist ein entscheidender Unterschied, denn MCP ist keine Konkurrenz zu bestehenden APIs, sondern eine zusätzliche Integrationsschicht speziell für KI-Anwendungen.
Die MCP-Architektur: Host, Client und Server
Technisch folgt MCP einer Host-Client-Server-Architektur. Der Host ist die KI-Anwendung, in der der Benutzer arbeitet. Das kann beispielsweise eine Desktop-Anwendung, eine Entwicklungsumgebung oder ein Webfrontend sein. Innerhalb des Hosts existieren MCP-Clients, wobei jeder Client mit genau einem MCP-Server kommuniziert. Ein Host kann gleichzeitig mehrere solcher Clients und damit mehrere MCP-Server verwalten.
Der Host besitzt dabei eine besonders wichtige Rolle. Er koordiniert die Verbindung zum Sprachmodell, verwaltet die MCP-Clients und ist für Sicherheitsentscheidungen, Berechtigungen und Benutzerinteraktion verantwortlich. Ein Wetter-MCP-Server benötigt beispielsweise keinen Zugriff auf eine lokale Projektdatenbank, und ein Git-MCP-Server sollte nicht automatisch sämtliche Informationen kennen, die ein anderer Server geliefert hat. Der Host kontrolliert, welcher Kontext wohin gelangt.
Der MCP-Server stellt dagegen die eigentlichen Fähigkeiten bereit. Er kann mit einem Dateisystem sprechen, eine API aufrufen, SQL-Abfragen durchführen oder lokale Programme starten. Gute MCP-Server sollten möglichst klar abgegrenzte Aufgaben erfüllen und sich kombinieren lassen, statt immer mehr Funktionen in einen einzigen riesigen Integrationsdienst zu packen.
Im KI-Stack lässt sich dieses Prinzip praktisch beobachten. Dort stellt der MCP Runtime eine definierte lokale Tool-Schicht bereit. Dahinter übernimmt Open Terminal die tatsächliche Ausführung auf Windows beziehungsweise über PowerShell.
Open WebUI
↓
MCP
↓
MCP Runtime
↓
Open Terminal
↓
Windows / PowerShell
MCP ersetzt dort weder PowerShell noch Open Terminal. Es standardisiert den Zugriff des KI-Frontends auf deren Fähigkeiten.
Tools, Resources und Prompts – MCP besteht aus mehr als Tool Calling
MCP wird häufig auf „Tools für ein LLM“ reduziert. Das greift zu kurz, denn MCP kennt drei zentrale serverseitige Primitive: Tools, Resources und Prompts. Diese drei Kategorien erfüllen unterschiedliche Aufgaben und sollten klar voneinander getrennt werden.
Tools sind ausführbare Funktionen. Beispiele wären read_file, write_file, search_repository, restart_service, create_ticket oder query_database. Ein Tool besitzt einen Namen, eine Beschreibung und ein definiertes Schema für seine Eingaben. Dadurch kann das Modell erkennen, welches Werkzeug für eine bestimmte Aufgabe geeignet ist und welche Parameter dafür benötigt werden.
Resources stellen dagegen Informationen bereit. Das können Dateien, Datenbankschemata, Git-Verläufe, Dokumentationen, Konfigurationen oder andere Datensätze sein. Eine Resource ist damit eher Kontext als Aktion. Der Unterschied lässt sich einfach formulieren: Eine Resource beantwortet die Frage „Welche Information soll ich lesen?“, während ein Tool beschreibt, welche Aktion ausgeführt werden kann.
Prompts wiederum sind strukturierte und wiederverwendbare Interaktionsvorlagen. Ein MCP-Server könnte beispielsweise einen Prompt bereitstellen, der ein Repository nach Sicherheitsproblemen analysiert oder eine bestimmte Auswertungsroutine vorbereitet. Damit standardisiert MCP nicht nur Aktionen und Datenzugriff, sondern auch wiederverwendbare Arbeitsmuster.
Der wichtige Punkt ist die Discovery. Ein MCP-Client kann einen Server nach seinen verfügbaren Tools, Resources und Prompts fragen. Die KI-Anwendung muss diese Fähigkeiten damit nicht alle dauerhaft und proprietär in ihrem eigenen Programmcode fest verdrahten.
Wie ein MCP-Tool-Aufruf praktisch funktioniert
Nehmen wir ein einfaches Beispiel. Der Benutzer schreibt: „Welche Prozesse verbrauchen gerade besonders viel Speicher?“ Der Host übergibt diese Anfrage an das Sprachmodell. Gleichzeitig kennt das Modell die Beschreibung eines verfügbaren Tools, beispielsweise list_processes, einschließlich des Schemas und der möglichen Parameter.
Das Modell entscheidet nun nicht einfach, eine Antwort zu erfinden, sondern erzeugt einen Tool-Aufruf. Der Ablauf sieht vereinfacht so aus:
Benutzer
│
▼
"Welche Prozesse benötigen viel RAM?"
│
▼
LLM erkennt:
"Ich brauche aktuelle Systemdaten."
│
▼
Tool Call: list_processes
│
▼
MCP Client
│
▼
MCP Server
│
▼
Betriebssystem
│
▼
Prozessdaten
│
▼
LLM
│
▼
Antwort an Benutzer
Das Modell selbst führt den Betriebssystembefehl nicht aus. Es entscheidet lediglich, dass ein Werkzeug benötigt wird und mit welchen Argumenten es aufgerufen werden soll. Die tatsächliche Ausführung übernimmt die Infrastruktur außerhalb des Modells. Diese Trennung ist fundamental, weil sie klar macht, dass Tool-Nutzung und Modellinferenz zwei unterschiedliche technische Ebenen sind.
MCP und Function Calling sind nicht dasselbe
Function Calling beziehungsweise Tool Calling ist bereits seit längerer Zeit Bestandteil moderner Sprachmodelle. Dabei kann ein Modell anstelle einer normalen Textantwort eine strukturierte Anweisung erzeugen, sinngemäß: „Rufe Funktion X mit Parameter Y auf.“
MCP befindet sich eine Ebene darüber. Tool Calling beschreibt die Entscheidung des Modells, ein Werkzeug zu verwenden. MCP beschreibt die standardisierte Infrastruktur, über die solche Werkzeuge gefunden, beschrieben und angesprochen werden können.
LLM
│
│ Tool Calling
▼
"Ich möchte read_file ausführen."
│
▼
MCP
│
│ standardisierte Verbindung
▼
MCP Server
│
▼
Dateisystem
MCP ersetzt Tool Calling deshalb nicht. Beide Mechanismen ergänzen sich und lösen unterschiedliche Teile derselben Aufgabe.
Warum das wichtig ist
Ohne eine standardisierte Schnittstelle entsteht schnell ein Integrationsproblem. Angenommen, fünf KI-Anwendungen sollen mit zehn unterschiedlichen Systemen kommunizieren. Bei vollständig individuellen Integrationen müssten viele verschiedene Adapter entwickelt, gepflegt und getestet werden.
Jede KI-Anwendung müsste wissen, wie GitHub angesprochen wird, wie eine bestimmte Datenbank authentifiziert wird, wie das Dateisystem funktioniert und wie ein Ticketsystem seine API strukturiert. MCP verschiebt diese Integrationsverantwortung. Ein GitHub-MCP-Server kennt GitHub, ein Datenbank-MCP-Server kennt die Datenbank und ein Terminal-MCP-Server kennt seine lokale Ausführungsumgebung. Die KI-Anwendung selbst kennt dagegen primär MCP.
Dadurch wird eine klassische Many-to-Many-Integrationslandschaft stärker modularisiert. Genau darin liegt wahrscheinlich der wichtigste architektonische Nutzen von MCP.
Lokal oder Remote – beides ist MCP
MCP schreibt nicht vor, dass ein Server lokal laufen muss. Ein lokaler Server kann direkt auf demselben Rechner wie der Host betrieben werden. Im KI-Stack wird dieser Ansatz beispielsweise für den lokalen Systemzugriff verwendet:
Open WebUI
↓
localhost
↓
MCP Runtime
↓
PowerShell
Ein MCP-Server kann aber genauso entfernt betrieben werden:
KI-Anwendung
↓
Internet
↓
Remote MCP Server
↓
Cloud-Service
Beide Varianten verwenden dasselbe grundsätzliche Protokoll, sind sicherheitstechnisch aber keineswegs identisch. Bei einem lokalen MCP-Server kann die Angriffsfläche beispielsweise über localhost-Bindung und lokale Credentials stark begrenzt werden. Ein Remote-MCP-Server benötigt dagegen ein wesentlich umfassenderes Authentifizierungs-, Autorisierungs- und Netzwerkmodell.
stdio und Streamable HTTP
Für die Kommunikation definiert MCP unterschiedliche Transportwege. Bei stdio startet der Client den MCP-Server typischerweise als lokalen Unterprozess. Die Kommunikation erfolgt über Standard Input und Standard Output. Dieser Ansatz eignet sich besonders gut für lokale Werkzeuge, weil dafür kein eigener Netzwerkdienst notwendig ist.
Der zweite zentrale Weg ist Streamable HTTP. Dabei werden MCP-Nachrichten über HTTP übertragen. Antworten können direkt oder über einen Stream zurückgegeben werden. Die Bedeutung der MCP-Nachrichten bleibt dabei unabhängig vom Transport gleich.
Damit trennt MCP bewusst zwischen zwei Ebenen:
Was wird kommuniziert?
↓
MCP-Protokoll
Wie wird es transportiert?
↓
stdio / HTTP
Diese Trennung erleichtert die Wiederverwendung derselben logischen Schnittstelle in sehr unterschiedlichen Umgebungen.
Ein wichtiger Architekturwechsel: MCP ist inzwischen stateless
Wer ältere MCP-Artikel liest, findet häufig noch Beschreibungen von Sessions, einem initialize-Handshake und dauerhaft gebundenen Verbindungen. Das entspricht nicht mehr vollständig dem aktuellen Stand der Spezifikation.
Mit der Spezifikation 2026-07-28 wurde der MCP-Core grundlegend in Richtung eines stateless Request/Response-Modells weiterentwickelt. Requests sollen die für ihre Verarbeitung notwendigen Protokollinformationen selbst enthalten. Für größere Installationen ist das relevant, weil einzelne Requests damit flexibler geroutet und von unterschiedlichen Serverinstanzen verarbeitet werden können.
Das bedeutet allerdings nicht, dass Anwendungen keinen Zustand mehr besitzen dürfen. Ein Tool kann beispielsweise eine ID erzeugen, die bei späteren Aufrufen als normaler Parameter wiederverwendet wird. Der Unterschied besteht darin, dass dieser Zustand nicht mehr zwingend verborgen in einer Transport-Session gehalten werden muss.
Diese Entwicklung macht MCP interessanter für größere, skalierbare Architekturen, Reverse Proxies, Gateways und verteilte Installationen.
MCP 2026 lässt sich besser routen und cachen
Der stateless Core bringt weitere Vorteile. Informationen über Methoden und Tool-Aufrufe lassen sich bei HTTP-basierter Kommunikation besser für Routing, Observability oder Rate Limiting nutzen. Auch Tool-, Prompt- oder Resource-Listen können effizienter behandelt und gecacht werden.
Das ist kein spektakuläres Feature, aber aus Infrastrukturperspektive wichtig. Sobald eine MCP-Landschaft nicht mehr aus zwei oder drei lokalen Tools besteht, sondern aus vielen Servern, Benutzern und Agenten, werden Themen wie Load Balancing, Caching, Logging und Policy Enforcement relevant.
MCP entwickelt sich damit zunehmend von einem einfachen Tool-Protokoll zu einer ernstzunehmenden Integrationsschicht.
Mehr Tools sind nicht automatisch besser
Ein häufiger Denkfehler lautet: Wenn MCP Tools verfügbar macht, sollte ein Agent möglichst viele davon erhalten. Das ist nicht unbedingt sinnvoll.
Ein Sprachmodell muss verstehen können, welches Werkzeug für eine Aufgabe geeignet ist. Hat ein Agent beispielsweise 200 sehr ähnliche Tools zur Auswahl, steigt die Komplexität der Entscheidung. Zusätzlich benötigen Toolbeschreibungen und Schemas Kontext und erhöhen damit potenziell den Tokenverbrauch und die Latenz.
Mehr Tools können deshalb auch mehr Auswahlfehler, höhere Komplexität und eine größere Angriffsfläche bedeuten. Eine gute MCP-Architektur besitzt nicht möglichst viele Tools, sondern genug klar abgegrenzte Tools.
Im KI-Stack wurde diese Frage bei der Entwicklung von Local Control praktisch untersucht. Statt für jede einzelne Windows-Funktion ein eigenes MCP-Tool einzuführen, wurde geprüft, ob die vorhandene Tool-Schicht zusammen mit run_command, PowerShell und bestehenden KI-Stack-Skripten ausreicht. Das Ergebnis war, dass für den vorgesehenen lokalen Steuerungsumfang keine zweite Windows-Control-Runtime mit dutzenden Spezialtools notwendig war.
Das ist ein gutes Beispiel für ein grundlegendes Architekturprinzip: Die Schnittstelle sollte abstrahieren und vereinheitlichen, nicht unnötig vervielfachen.
MCP macht ein System nicht automatisch sicher
MCP ist ein Kommunikationsprotokoll und keine automatische Sicherheitsgrenze. Ein Tool namens read_documentation besitzt ein völlig anderes Risikoprofil als ein Tool wie delete_database, obwohl beide technisch über dieselbe Protokollschicht bereitgestellt werden können.
Deshalb müssen Host und Server weiterhin entscheiden, wer ein Tool sehen und ausführen darf, welche Parameter zulässig sind, auf welche Daten zugegriffen werden darf, wann eine Bestätigung erforderlich ist und wie Aufrufe protokolliert werden. Gerade bei Remote-Szenarien kommen zusätzliche Anforderungen an Authentifizierung, Autorisierung und sichere Transportwege hinzu.
Eine gute MCP-Architektur setzt deshalb auf Least Privilege. Ein Research-Agent benötigt normalerweise keine Registry-Schreibrechte oder die Fähigkeit, lokale Dienste zu stoppen. Ein Administrationsagent kann solche Rechte dagegen durchaus benötigen. Tool-Verfügbarkeit wird damit Teil des Berechtigungsmodells und sollte nicht pauschal für alle Agenten identisch sein.
Dieses Prinzip wird auch im KI-Stack verwendet. Profile mit lokalem Administrationsbedarf erhalten die entsprechende MCP-Verbindung, während beispielsweise ein Research-Profil bewusst keinen allgemeinen Terminalzugriff erhält.
Prompt Injection wird mit Tool-Zugriff gefährlicher
Bei einem reinen Chatbot kann eine manipulierte Information zunächst zu einer falschen Antwort führen. Bei einem handlungsfähigen Agenten kann dieselbe Manipulation zu einer realen Aktion führen.
Ein Research-Agent könnte beispielsweise eine manipulierte Webseite lesen, die versucht, das Modell dazu zu bringen, bestehende Anweisungen zu ignorieren und lokale Dateien zu löschen. Ein Agent ohne Dateisystem- oder Terminalrechte kann diese Anweisung nicht direkt ausführen. Ein Agent mit uneingeschränktem Systemzugriff hätte dagegen theoretisch ein deutlich größeres Schadenspotenzial.
Daraus folgt ein wichtiges Sicherheitsprinzip: Nicht jede Information, die ein Modell lesen darf, sollte automatisch Einfluss auf jedes Werkzeug haben, das es verwenden darf. MCP löst dieses Problem nicht automatisch, ermöglicht aber eine Architektur, in der Fähigkeiten und Server klarer getrennt werden können.
Human in the Loop ist kein Widerspruch zu Agenten
Ein Agent muss nicht vor jedem ungefährlichen Schritt fragen, ob er eine Datei lesen oder einen Prozessstatus anzeigen darf. Das würde Automatisierung praktisch unbrauchbar machen. Gleichzeitig sollten kritische Aktionen wie das Löschen von Produktionsdaten oder weitreichende Änderungen nicht zwangsläufig denselben Freigaberegeln unterliegen wie eine reine Statusabfrage.
Eine sinnvolle Agentenarchitektur unterscheidet deshalb zwischen Aktionsklassen. Lesende, reversible und klar eingegrenzte Operationen können weitgehend autonom erfolgen. Kritische, irreversible oder weitreichende Eingriffe benötigen zusätzliche Kontrollen oder Benutzerfreigaben.
MCP liefert dafür die technische Grundlage, die eigentliche Policy muss aber die Anwendung beziehungsweise der Host definieren.
Was MCP ausdrücklich nicht ist
MCP ist kein Sprachmodell, kein Agent, kein RAG-System, kein Memory, keine Datenbank und auch keine Alternative zu PowerShell, REST, SQL oder Git. Es kann all diese Systeme jedoch einem KI-Agenten über eine einheitliche Schnittstelle zugänglich machen.
Diese Trennung verhindert viele typische Missverständnisse rund um MCP.
MCP und RAG
Ein RAG-System beschafft Informationen und fügt relevante Ausschnitte in den Kontext des Modells ein. Ein MCP-Server könnte den Zugriff auf ein solches RAG-System bereitstellen, aber MCP selbst führt keine semantische Suche durch.
Eine mögliche Architektur wäre:
LLM
↓
MCP Tool: search_knowledge
↓
RAG-System
↓
Vektordatenbank
↓
relevante Dokumentabschnitte
Im KI-Stack existiert RAG deshalb unabhängig von MCP. MCP könnte eine Schnittstelle zu Wissen bereitstellen, ersetzt aber nicht Speicherung, Chunking, Embeddings oder Retrieval.
MCP und Memory
Dasselbe gilt für persistentes Memory. Ein Memory-System speichert Informationen über einen Benutzer oder frühere Interaktionen. MCP könnte einen Memory-Dienst zugänglich machen, beispielsweise über Tools wie remember_fact, search_memory oder delete_memory. Das Protokoll selbst besitzt aber kein langfristiges Gedächtnis.
Im KI-Stack wird persistentes Memory bewusst über die native lokale Memory-Funktion von Open WebUI umgesetzt. MCP und Memory erfüllen damit unterschiedliche Aufgaben: Memory beantwortet die Frage, was sich ein Assistent merken soll, während MCP beschreibt, wie der Assistent externe Fähigkeiten erreicht.
MCP verändert vor allem die Architektur von KI-Anwendungen
Die größte Veränderung durch MCP liegt nicht darin, dass ein Sprachmodell plötzlich eine Datei öffnen kann. Das war technisch schon vorher möglich.
Der entscheidende Unterschied ist, dass sich dafür eine gemeinsame Integrationsschicht etabliert. Vorher musste eine KI-Anwendung für jedes Zielsystem eigene Adapter implementieren. Mit MCP entsteht eine klar definierte Zwischenschicht zwischen Host und angebundenem System.
Vorher:
KI-Anwendung
↓
individueller Adapter
↓
System
Mit MCP:
KI-Anwendung
↓
MCP
↓
MCP Server
↓
System
Dadurch können beide Seiten unabhängiger voneinander entwickelt werden. Ein Entwickler eines Tools muss nicht jede zukünftige KI-Oberfläche unterstützen, und ein Entwickler einer KI-Oberfläche muss nicht jedes zukünftige Zielsystem individuell integrieren. Beide Seiten müssen sich auf dasselbe Protokoll einigen.
Genau darin liegt der Wert eines Standards.
Warum MCP gerade für lokale KI interessant ist
Bei Cloud-KI werden Tool-Aufrufe häufig über die Infrastruktur des jeweiligen Plattformanbieters abgewickelt. Bei lokaler KI stellt sich die Frage anders: Wie bekommt das lokale Modell kontrollierten Zugriff auf den lokalen Rechner, ohne dass dafür zwingend ein externer Dienst benötigt wird?
MCP eignet sich dafür besonders gut, weil auch der Server vollständig lokal betrieben werden kann:
Benutzer
↓
Open WebUI
↓
lokales LLM
↓
MCP
↓
lokaler MCP Server
↓
PowerShell
↓
eigener Rechner
Damit müssen weder Tool-Aufrufe noch lokale Systeminformationen zwangsläufig einen externen Cloud-Dienst durchlaufen.
Genau deshalb wurde MCP im KI-Stack als Standardpfad für terminalfähige Profile eingeführt. Mit KI-Stack 2.14 entstand zunächst der kontrollierte lokale Ausführungspfad über Open Terminal. Version 2.15 setzte MCP darüber als standardisierte Tool-Schicht, und Version 2.16 verwendet diese Architektur anschließend für allgemeines Local Control.
MCP ist dort also kein isoliertes Zusatzfeature, sondern zunehmend die Verbindungsschicht zwischen KI und lokalem System.
MCP wird zunehmend Infrastruktur für Agenten
Mit der Weiterentwicklung der Spezifikation geht MCP inzwischen deutlich über den ursprünglichen einfachen Tool-Server-Ansatz hinaus. Der Core wird stärker auf skalierbare, stateless Kommunikation ausgerichtet, Listen können effizienter behandelt werden und Erweiterungen adressieren zunehmend auch länger laufende Aufgaben und interaktive Workflows.
Damit entwickelt sich MCP von einer Schnittstelle nach dem Muster „Ein LLM kann ein Tool aufrufen“ zunehmend zu einer allgemeinen Integrationsschicht für Daten, Werkzeuge, Benutzerinteraktion und agentische Workflows.
Das erklärt auch, warum MCP momentan so viel Aufmerksamkeit erhält. Nicht weil das Protokoll an sich spektakulär wäre, sondern weil durch eine gemeinsame Schnittstelle erstmals sehr unterschiedliche KI-Anwendungen und externe Systeme interoperabler werden.
Fazit
MCP macht Sprachmodelle nicht intelligenter. Es verändert vielmehr, was sie erreichen können.
Ein Sprachmodell ohne Werkzeuge kann erklären. Ein Sprachmodell mit proprietären Integrationen kann einige fest definierte Systeme bedienen. Ein MCP-fähiger Host kann dagegen unterschiedlichste Fähigkeiten über eine gemeinsame Architektur einbinden.
Die Verantwortlichkeiten bleiben dabei klar getrennt: Das LLM entscheidet, welche Fähigkeit benötigt wird. Der Host kontrolliert Kontext und Berechtigungen. Der MCP-Client stellt die Verbindung her. Der MCP-Server stellt die Fähigkeit bereit. Das dahinterliegende System führt die eigentliche Arbeit aus.
Genau diese Trennung macht MCP interessant. APIs, PowerShell, Datenbanken oder andere Technologien verschwinden dadurch nicht. Sie werden vielmehr über eine gemeinsame KI-seitige Integrationsschicht zugänglich.
Für agentische Systeme dürfte diese Standardisierung mindestens genauso wichtig werden wie die nächste Generation größerer Sprachmodelle. Denn ein gutes Modell, das nichts erreichen kann, bleibt ein Berater. Ein Modell mit kontrolliertem Zugang zu den richtigen Werkzeugen kann zum Assistenten werden.