Einsteigerleitfaden: MCP-Architektur visuell verstehen

Das Model Context Protocol (MCP) hat zahlreiche neue Möglichkeiten eröffnet, die Large Language Models erweitern. Gleichzeitig hat es auch für einige Verwirrung gesorgt. Deshalb habe ich einen visuellen Einsteigerleitfaden zur MCP-Architektur erstellt – mit Diagrammen und allem, was dazugehört.

Wenn Sie in der Entwicklung tätig sind, haben Sie wahrscheinlich schon gehört, wie MCP Server die agentische Softwareentwicklung in Tools wie Cursor, Windsurf und sogar den neuen agentischen Workflows von VS Code prägen. MCP geht jedoch weit über Software hinaus und ermöglicht nahtlose, umfassende LLM-Erlebnisse für Endnutzer. Denn MCP erweitert das Modell über die Trainingsdaten hinaus und nutzt seine Schlussfolgerungsfähigkeiten, um Aktionen auszulösen.

MCP verstehen

LLMs sind im Wesentlichen komprimierte Wissensdatenbanken mit den Daten, auf denen sie trainiert wurden. Ähnlich wie unser Gehirn lernen sie mithilfe neuronaler Netze. Dadurch können sie Schlussfolgerungen ziehen und bedeutende logische Verknüpfungen herstellen, die an Intelligenz erinnern. So beeindruckend Large Language Models auch sind: Sie bleiben auf ihre eigenen Daten beschränkt.

MCPs sind die Brücke, die LLMs mit Wissen und Handlungsmöglichkeiten verbindet, die außerhalb ihrer Reichweite liegen. Manche würden sagen, dass es solche Möglichkeiten schon gab, als OpenAI vor einiger Zeit Function Calling oder Tool Calling einführte. MCPs haben dieses Konzept jedoch zu einem offenen Kommunikationsstandard mit klar definierten, strukturierten Schnittstellen weiterentwickelt und die verteilte, dynamische Bereitstellung und Erkennung von Tools ermöglicht. Mehr zum Thema MCP vs. Function Calling erfahren Sie weiter unten.

MCP Hosts, MCP Clients und MCP Server

Nachdem wir den Zweck von MCPs erläutert haben, können wir uns nun die einzelnen Bausteine genauer ansehen. Im Wesentlichen umfasst MCP drei Entitäten:

• Der MCP Host ist die KI-gestützte Anwendung, die MCPs integriert. Beispiele aus der Praxis sind Claude Desktop, Cursor, Windsurf, VS Code und weitere. Diese Anwendungen integrieren MCPs, indem sie einen MCP Client implementieren.

• Der MCP Client: Der MCP Client ist die zugrunde liegende Implementierungsschicht, die häufig in umfassenden KI-Anwendungen, agentischen Frameworks und ähnlichen Anwendungen gehostet wird. Er ist die Schnittstelle, die mit den MCP Servern kommuniziert.

• Der MCP Server: Der MCP Server stellt Fähigkeiten für die Interaktion mit der „realen Welt“ bereit. Das LLM hat keinen Zugriff auf Ihre lokalen Dateien, oder? Wenn ein MCP Server sie jedoch verfügbar macht, kann das LLM sie auflisten, lesen und bearbeiten. MCP Server implementieren diese erweiterten Funktionen, Wissensquellen und Aktionen, auf die das LLM nun zugreifen kann.

Hinweis: Sie werden wahrscheinlich feststellen, dass MCP Hosts oft einfach als MCP Clients bezeichnet werden. Der Begriff wurde um eine Ebene erweitert und bezeichnet nun die KI-gestützte Anwendung als Ganzes.

Ein kurzer Überblick über Function Calling und Tools

MCP Server stellen MCP Clients in der Regel Tools zur Verfügung. Beispiele für solche Tools sind „Datei lesen“ oder „alle Branches eines entfernten Git-Repositorys auflisten“.

Wie funktioniert das? Sie teilen dem LLM mit: „Hey, hier sind die verfügbaren Tools. Eines davon heißt read_file.“ Das LLM kann dieses Tool dann gezielt über das Model Context Protocol aufrufen. Dieser Aufruf wird wiederum einer konkreten Funktionsimplementierung im Code des MCP Servers zugeordnet:

function tool_read_file(filepath) {
   // implementation
}

Tools sind jedoch nichts Neues. Tool Calling, auch Function Calling genannt, wurde Ende 2023 von OpenAI eingeführt. Anschließend wurde Function Calling in jeder KI-gestützten Anwendung implementiert und musste von der Anwendung gezielt für das LLM orchestriert werden. Noch wichtiger: Nicht alle Modelle unterstützten Function Calling.

Weiter unten erläutern wir, warum MCPs eine bessere, ganzheitliche Lösung für Function Calling bieten.

Transporttypen für MCP Server: STDIO vs. HTTP

Der Begriff MCP Server lässt zunächst vielleicht an einen tatsächlichen netzwerkbasierten Server denken. Bekannt wurden MCPs jedoch vor allem durch lokal ausgeführte Prozesse, die über den Transportweg der Standardeingabe und -ausgabe kommunizieren.

Was ist STDIO?

STDIO (Standard Input, Output und Error) ist ein grundlegender textbasierter Kommunikationsmechanismus für Systemprozesse – also für tatsächliche Befehle oder Programme, etwa wenn Sie git in der Eingabeaufforderung ausführen.

Bei der Ausführung eines Programms richtet das Betriebssystem drei Standardkanäle ein: stdin für den Empfang von Eingaben (meist über die Tastatur oder die Ausgabe eines anderen Programms), stdout für die normale Ausgabe (üblicherweise ans Terminal oder in eine Datei) und stderr für Fehlermeldungen und Diagnosedaten (ebenfalls meist ans Terminal, aber häufig getrennt).

Kurz gesagt: STDIO ermöglicht Programmen die Interaktion mit dem Betriebssystem oder anderen Programmen. So können Sie beispielsweise die Ausgabe eines Befehls (stdout) als Eingabe (stdin) an einen anderen Befehl weiterleiten. Ebenso können Sie stdout oder stderr eines Programms zur Protokollierung oder späteren Prüfung in eine Datei umleiten. Viele Kommandozeilen-Tools nutzen STDIO intensiv für Datenverarbeitungspipelines und grundlegende Interaktionen.

In Systemen mit Client-Server-Architektur wie MCP Servern kann STDIO als einfache Methode dienen: Der MCP Server ist dabei ein Prozess, der Anfragen über stdin empfängt und als Textantworten über stdout an den MCP Client zurücksendet.

Lokale STDIO-MCP-Server

MCP Server, die für die Kommunikation auf STDIO angewiesen waren, benötigten einen laufenden Prozess. Daher handelte es sich größtenteils um lokal ausgeführte und lokal installierte MCP Server.

Viele KI-gestützte Anwendungen (auch MCP Hosts genannt) verlangten deshalb von Nutzern MCP-Serverdefinitionen, die sich auf die Prozessausführung konzentrierten. Hier ein einfaches Beispiel aus einer mcp.json-Definition eines MCP Servers von Cursor:

// This example demonstrated an MCP server using the stdio format
// Cursor automatically runs this process for you
// This uses a Node.js server, ran with `npx`
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

MCP Server in der Cloud skalieren

MCP Server können ihre Erwartungen endlich erfüllen: Der HTTP-Transporttyp setzt sich zunehmend in KI-Anwendungen wie Cursor und Claude Desktop durch. Gleichzeitig unterstützen Cloud-Infrastrukturen wie Vercel und Cloudflare das Hosting von MCP Servern.

Ursprünglich führten MCP Server einen netzwerkbasierten HTTP-Transport ein, der auf einem Mechanismus namens SSE (Server-Sent Events) beruhte, um Nachrichten zwischen dem LLM und dem MCP Server zu synchronisieren und zu orchestrieren. Wie WebSockets erfordert SSE jedoch dauerhaft laufende Server. Diese lassen sich auf modernen Deployment-Plattformen wie Vercel Functions oder AWS Lambda nicht ohne Weiteres bereitstellen. Deshalb entstand eine neue Spezifikation für Streamable HTTP, die serverloses HTTP für MCP Server ermöglicht.

HTTP-basierte MCP Server lassen sich einfach konfigurieren: Sie benötigen lediglich die Adresse eines Remote-Hosts statt einer komplexen Spezifikation von Kommandozeilenargumenten. Außerdem lassen sie sich leichter teilen und nutzen, da keine bestimmte Entwicklungsumgebung für die lokale Einrichtung und Ausführung mehr erforderlich ist.

Cursor erwartet beispielsweise, dass Remote-MCP-Server über HTTP ganz einfach wie folgt definiert werden:

// This example demonstrated an MCP server using the SSE format
// The user should manually setup and run the server
// This could be networked, to allow others to access it too
{
  "mcpServers": {
    "server-name": {
      "url": "http://example.com/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Die MCP-Architektur: alles zusammenführen

Nachdem wir die Bausteine von MCPs – etwa MCP Clients, MCP Server, die verwendeten Transporttypen und praktische Beispiele dazu – erläutert haben, können wir nun das Deployment-Modell und die Gesamtarchitektur von MCPs besser verstehen.

Die MCP-Architektur ermöglicht lokale und Remote-Deployments und eröffnet damit zahlreiche Konfigurations- und Deployment-Strategien. Beispielsweise können Sie vollständig MCP-fähige KI-Anwendungen lokal ausführen. Ein Beispiel aus der Praxis: Sie installieren eine lokale KI-Anwendung wie die Produktivitäts-App Raycast oder die Cursor-IDE. Dann stellen Sie Raycast oder Cursor über Ollama ein lokal ausgeführtes LLM bereit. Die Anwendungen Raycast oder Cursor führen einen lokalen MCP Client aus, den Sie mit einem lokal ausgeführten MCP Server konfigurieren können – etwa einem SQLite MCP Server, um datensatzbasierte Datenbanken zu durchsuchen.

Das obige Beispiel zeigt eine KI-gestützte Anwendung, die vollständig lokal auf einem Laptop ausgeführt wird und weder Cloud- noch Netzwerkzugriff benötigt.

Alternativ können Sie die Komponenten beliebig kombinieren. Sie können den MCP Server in einer Cloud-Infrastruktur bereitstellen und über einen HTTP-Transport verfügbar machen. MCP Client und MCP Server kommunizieren gemäß der Spezifikation über das Model Context Protocol. Dadurch lassen sie sich vollständig voneinander entkoppeln.

Darüber hinaus wurde die Implementierung des MCP Clients zwar bislang fast immer als Teil der KI-Anwendung gehostet, doch das ist nicht zwingend erforderlich. Der MCP Client kann auch von der KI-Anwendung entkoppelt werden.

MCP vs. Function Calling: Warum MCPs keine API-Wrapper sind

Viele bezeichnen MCPs abwertend als „nur einen weiteren REST-API-Wrapper“. Diese kurzsichtige Einschätzung wird MCPs nicht gerecht. Sehen wir uns an, warum MCPs vielschichtiger und für KI-Anwendungen bestens geeignet sind.

Bevor wir uns mit der übergeordneten Verwechslung von MCP und REST-API befassen, möchten einige Entwickler genauer verstehen, wie und warum sich MCPs von dem ursprünglichen Function Calling unterscheiden, das OpenAI und seine SDKs seit 2023 ermöglichen.

MCP vs. Function Calling

Beim Function Calling musste die KI-gestützte Anwendung jedes Tool selbst implementieren. Stellen Sie sich vor, eine Anwendung wie Cursor müsste ein Git-Tool zum „Auflisten entfernter Branches“ implementieren. Eine Anwendung wie Cursor könnte dafür den Befehl git ls-remote ausführen, während eine andere KI-Anwendung wie Windsurf die GitHub-API nutzen könnte. Die beiden Ansätze würden zu völlig unterschiedlichen Entwicklererlebnissen, einer anderen Fehlerbehandlung und weiteren Unterschieden führen.

Diese fehlende Organisation und Standardisierung der Function-Calling-Funktionalität führte zu unnötigen Duplikaten von Code und Logik in den verschiedenen KI-gestützten Anwendungen.

Zusammenfassend bieten MCPs gegenüber herkömmlichem Function Calling folgende Vorteile:

• Die Tools in Function-Calling-SDKs waren fest an die LLM-Integration gekoppelt. Das hatte folgende Auswirkungen:

• Eine Skalierung war nicht ohne Weiteres möglich. Mit MCPs können Sie den MCP Server hingegen unabhängig von Ihren KI-Anwendungen bereitstellen und skalieren.

• Es gibt keine klare Trennung zwischen der Tool-Implementierung in der KI-Anwendung und der übrigen Anwendungslogik. Beides ist untrennbar miteinander verbunden. Technisch gesehen können Sie Wrapper und Schnittstellen dazwischen erstellen und sie über JSON-RPC bereitstellen – damit würden Sie MCPs im Grunde neu entwickeln. Genau das und noch mehr bieten MCPs.

• Es gibt keine einfache Möglichkeit, Nutzern, die die LLM-Integration verwenden oder betreiben, eine Erweiterung um eigene Tools zu ermöglichen. Da die Function-Calling-Implementierung Teil der LLM-Integration ist, ist sie fest daran gekoppelt. Um Erweiterungen durch Drittanbieter zu ermöglichen, müssten Sie MCPs erneut selbst entwickeln.

Die feste Kopplung des herkömmlichen Function Callings, das ursprünglich zur Definition von Tools eingeführt wurde, wirft auch Sicherheitsfragen auf. Potenziell gefährliche und sensible Operationen, die Tools ausführen müssen, sind Teil der KI-Anwendung, die diese Tools bereitstellt. Unsichere Programmierkonventionen oder mangelhafte Sicherheitspraktiken auf Tool-Ebene könnten die gesamte KI-Anwendung gefährden.

Über die angestrebte Standardisierung der Spezifikation hinaus bieten MCPs eine Art Inversion of Control (IoC), die Function Calling und erweiterte Funktionen voneinander entkoppelt und in separate Services auslagert.

Sind MCPs nur REST-API-Wrapper?

Wer MCPs auf herkömmliche REST-APIs reduziert, übersieht die Komplexität der Entwicklung von KI-Anwendungen. Viele Eigenschaften von MCPs ähneln denen von REST-APIs: MCPs kommunizieren über HTTP, das zugrunde liegende Protokollformat ist JSON-RPC und es gibt ein Client-Server-Modell. Tatsächlich ähneln sie damit herkömmlichen Webanwendungen, deren Zweck darin besteht, Browsern auf der Client-Seite und anderen API-Clients Inhalte bereitzustellen.

MCPs kommen jedoch häufig auf einer anderen Abstraktionsebene als einfache REST-APIs zum Einsatz und benötigen KI-native Funktionen, die REST-APIs nicht bieten:

1. MCPs ermöglichen Anwendungsfälle, nicht Abläufe: Das heißt: Betrachten Sie MCPs als Wegbereiter für Anwendungsfälle, die ein Problem lösen sollen. REST-API-Endpunkte bilden meist granulare Entitäten und deren Beziehungen ab. MCPs erstellen letztlich eine TxE-Matrix (Tools × Endpunkte), in der eine einzelne bereitgestellte Tool-Implementierung mehreren REST-API-Endpunkten zugeordnet ist. Ein MCP-Server, der für ein Git-Repository ein „get_open_issues“-Tool bereitstellt, müsste beispielsweise wahrscheinlich mehrere REST-API-Endpunkte aufrufen: 1) alle offenen Issues auflisten; 2) für jede ID eines offenen Issues alle zugehörigen Daten und Metadaten abrufen. MCP-Server sind oft weniger granular als eine RESTful-API.

2. MCPs lösen Aktionen jenseits des Webs aus: Es liegt nahe, alles als webverbunden zu betrachten. Viele beeindruckende MCP-Demos drehten sich jedoch um Interaktionen außerhalb des Webs und von REST-APIs. Die virale Blender-MCP-Demo ermöglichte der Claude-KI-Anwendung beispielsweise, vollständige 3D-Szenen zu erstellen. Grundlage dafür war die Python-API von Blender. Wird der Blender-Anwendungsfall über eine sprachspezifische API bereitgestellt, kann das LLM seine Programmierfähigkeiten einsetzen und bessere Ergebnisse erzielen.

3. MCPs nutzen LLMs von Grund auf, REST-APIs nicht: Die MCP-Spezifikation definiert eine Funktion namens sampling, mit der der MCP-Server das LLM zu einer bestimmten Aktion abfragen kann. Hier ein praktisches Beispiel, das mit MCPs möglich ist, mit bestehenden APIs jedoch nicht – aufbauend auf dem vorherigen Git-Beispiel: „offene Issues mit den größten Auswirkungen auf die Sicherheit abrufen“. Wie könnte eine REST-API die Anforderung „größte Auswirkungen auf die Sicherheit“ erfüllen? Gibt es für Issues keinen vorhandenen Filter oder Tag für sicherheitsrelevante Inhalte, lassen sich keine relevanten Informationen abrufen. Bei MCPs hingegen kann eine Tool-Implementierung die Liste offener Issues abrufen und eine Sampling-Anfrage mit einer Eingabeaufforderung wie „Gib für die folgenden offenen Issues eine nach den größten Auswirkungen auf die Sicherheit sortierte Liste im JSON-Format zurück“ an das LLM senden. Dann kann das LLM seine Stärken ausspielen und ein Ergebnis mit fundierter Analyse liefern. Das MCP nutzt also ein LLM als Teil der Problemlösung – eine Funktion, die einer bestehenden REST-API-Implementierung nicht von Haus aus zur Verfügung steht. Sampling und die bidirektionale Kommunikation mit LLMs ermöglichen nicht nur Ähnlichkeits- oder Stimmungsanalysen, sondern nutzen auch die Stärken von LLMs mit mehreren Modellen und ermöglichen iterative Verbesserungen.

Sicherheitsbedenken bei MCP

MCP bringt auch Sicherheitsbedenken mit sich. Da MCP-Server allgegenwärtig sind, entstehen grundlegende Supply-Chain-Sicherheitsbedenken, darunter:

1. Schädliche MCP-Server – Wie stellen Sie sicher, dass ein MCP-Server vertrauenswürdig ist? Was passiert, wenn der MCP-Server heimlich vertrauliche Informationen aus Ihrer lokalen oder bereitgestellten Umgebung ausführt und exfiltriert? Könnte der MCP-Server eine Hintertür enthalten? Wie können Sie diese Sicherheitsbedenken überprüfen?

2. Verwundbare MCP-Server – MCP-Server funktionieren möglicherweise wie vorgesehen. Das heißt jedoch nicht, dass sie frei von Sicherheitslücken und Fehlern beim sicheren Programmieren sind. Unsichere Programmierpraktiken in einem MCP-Server können von Nutzern ausgenutzt werden und zu einer Sicherheitskompromittierung oder Datenpanne führen.

Dies sind nur einige der Sicherheitsbedenken rund um MCPs. Die Sicherheitsrisiken rund um MCP und KI umfassen auch praktische Sicherheitslücken beim Vibe-Coding, die Frage, wie LLMs durch Prompt-Injection für Angriffe missbraucht werden können, und Sicherheitsrisiken beim Programmieren mit ChatGPT.

All diese und weitere KI-Sicherheitsbedenken machen Leitplanken für KI-Sicherheit und die Absicherung KI-generierten Codes erforderlich – Risiken, die Snyk minimiert.