# Model Context Protocol - (29.04.2025) Das Model Context Protocol, kurz MCP, ist ein offenes Protokoll welches einen standardisierten Weg bietet, wie generative Sprachmodelle auf Applikationen und deren Daten zugreifen können. Es hilft dabei, Agenten (*agents*) und komplexe Workflows auf LLMs aufzubauen. Unteranderem bietet es folgende Vorteile[^1]: - Eine Liste mit vorgebauten Integrationen welche jegliche LLMs direkt integrieren können - Die Flexibilität zwischen verschiedenen LLM Anbietern zu wechseln - Best Practices um Daten innerhalb der Infrastruktur zu schützen ## Core Architektur Bevor wir uns mit den Funktionalitäten auseinander setzen können, wollen wir einen kurzen Überblick über die Funktionsweise und Architektur des Protokolls schaffen. Grundsätzlich folgt MCP einer Client-Server Architektur, wobei sich Host-Applikationen mit mehreren Servern verbinden können:[^1] - **Hosts** sind LLM-Applikationen welche eine Verbindung initiieren - **Clients** verwalten die 1:1 Verbindung, innerhalb der Host-Applikation, mit dem Server - **Server** stellen Kontexts, Tools und Prompts für Clients zur Verfügung. ![[MCP-Architektur_1.excalidraw.png]] Alle Client-Instanzen werden vom Host verwaltet. Auch Sicherheitsregeln oder Einwilligungen werden vom Host übernommen. Die Clients übernehmen die Fähigkeitsverhandlungen und verwalten die Nachrichten bidirektional. Es ist wichtig zu beachten, dass jeder Client isoliert für eine Server-Verbindung vom Host erstellt wird und somit auch nur während dieser Verbindung besteht. Wenn mehrere Server eingebunden werden, dann existieren zeitgleich auch mehrere Clients.[^2] ### *Message Types* In MCP sind drei Arten von Nachrichten (*message types*) definiert: - **Requests** (Anfragen): Bidirektionale Nachrichten mit Methoden und Parameter welche eine Antwort erwarten. - **Responses** (Antworten): Erfolgreiche Resultate oder Fehlermeldungen. - **Notifications** (Benachrichtigungen): Einweg Nachrichten welche keine Antwort erwarten. Alle Nachrichten folgen der [JSON-RPC 2.0](https://www.jsonrpc.org/specification) Spezifikation.[^2] ### Fähigkeitsverhandlung (*Capability Negotiation*) Das Model Context Protocol basiert auf einem Fähigkeitsbasierten Verhandlungssystem. Bei der Initiierung deklarieren sowohl Clients wie auch Server klar ihre Fähigkeiten und unterstützten Features. Die darin bestimmten Limitationen werden anschliessend während der ganzen Kommunikation respektiert.[^2] Wenn also *Sampling* beispielsweise nicht vom Client unterstützt werden sollte, dann wird dies vom Client bei der Initiierung so kommuniziert und der Server kann entsprechend keine *Sampling*-Anfragen senden. ## Server Features Die meisten Features von MCP bestehen auf der Server Seite. Zu diesen gehören: ### Prompts Das Model Context Protocol bietet mit *Prompts* einen standardisierten Weg, Vorlagen für Prompts bereit zu stellen. Der Server kann so strukturierte Nachrichten und Anweisungen für die Interaktion mit Sprachmodellen definieren. Der Client kann diese Vorlage anschliessend entdecken, aufrufen und mit eigenen Argumenten nach Bedarf anpassen. *Prompts* sind darauf ausgelegt, vom Benutzer kontrolliert zu werden. Der Server stellt diese zwar zur Verfügung, der Benutzer sollte diese jedoch explizit auswählen.[^3] ### Resources Mit *Resources* bietet MCP einen standardisierten Weg für Server dem Client bestimmte Ressourcen zur Verfügung zu stellen. So können Server jegliche Daten wie Dateien, Datenbank Schemas oder Applikationsspezifische Informationen als Kontext für Sprachmodelle anbieten.[^4] ### Tools Über *Tools* können ausführbare Funktionen bereitgestellt werden, welche vom Sprachmodell nach Bedarf ausgeführt werden können. So kann dem Modell beispielsweise Zugriff auf eine Datenbank oder eine API gegeben werden, aber auch komplexe Rechnungen ausgeführt werden. Jedes Tool wird durch einen Namen eindeutig identifiziert und hat Metadaten, welche das Schema des Tools beschreiben. Anders als bei den *Prompts* sind Tools Modell-gesteuert. Das Sprachmodell kann also alle verfügbaren Tools erkunden und diese automatisch ausführen. Dabei wählt es die Tools nach kontextuellem Verständnis und den Anweisungen des Benutzers.[^5] ## Client Features Neben den Server Features hat MCP auch einige Client Features standardmässig implementiert: ### Roots *Roots* bieten einen standardisierten Weg für Clients, um dem Server Dateisystem "roots" bereitzustellen. Innerhalb eines Roots werden Abgrenzungen definiert, in welchen der Server arbeiten kann, wodurch der Server auch weiss, auf welche Ordner und Dateien er Zugriff hat.[^6] ### Sampling Über *Sampling* kann ein Server Vervollständigungen oder generierte Inhalte von Sprachmodellen über den Client anfordern. So können Server auf AI-Fähigkeiten zugreifen, während die Kontrolle über Modell-Zugriff, Auswahl und Berechtigungen weiterhin beim Client bleibt. Auch ein API Key ist so nicht notwendig. Der Server kann auch gleich Kontext von MCP Servern in seine Prompt einschliessen und damit Text-, Audio- oder Bild-basierte Interaktionen anfragen.[^7] Da Sampling in der Umsetzung noch eher instabil ist, hat Google das [[A2A]] Protokoll entwickelt, welches diese Funktionalität spezifisch für Interaktionen zwischen verschiedenen generativen Modellen anbietet. ## Transporte Das Protokoll definiert aktuell zwei Transport-Mechanismen für die Client-Server Kommunikation: - stdio - Streamable HTTP Es kann jedoch mit eigenen Transport-Mechanismen erweitert werden. ### stdio *stdio*, ausgeschrieben "Standard Input/Output" ist das Protokoll für lokale MCP Server. Mit diesem Transport ist der Client dafür zuständig, den Server als Unterprozess (*subprocess*) zu starten. Anschliessend liest der Client über den Standard Input (`stdin`) und sendet Nachrichten über den Standard Output (`stdout`).[^8] ### Streamable HTTP Bei *Streamable HTTP* läuft der Server in einem unabhängigen Prozess und kann so mehrere Client-Verbindungen unterstützen. Dieser Transport nutzt `HTTP POST` und `GET` Anfragen. *Stremable HTTP* ersetzt hierbei den ursprünglichen *HTTP+SSE Transport*, wobei auch hier mit SSE (*Server-Sent Events*) ein Stream für mehrere Server Nachrichten genutzt werden kann. So können sehr einfache, aber auch komplexere MCP Server, welche entsprechendes Streaming und Server-zu-Client Benachrichtigungen und Anfragen unterstützen, entwickelt werden.[^8] ## Security bei Streamable HTTP in MCP Während die Sicherheitsbedenken bei *stdio* nicht von grosser Relevanz sind, da der ganze Server nur lokal läuft und auch die Lebzeit des Prozesses begrenzt ist, sind diese bei Streamable HTTP sehr wichtig zu beachten. Mit jedem Tool und anderen Server Features wird eine neue Schnittstelle auf den Server implementiert. Wie auch bei anderen Schnittstellen, müssen diese nach bestem Gewissen abgehärtet werden, um einem böswilligen Client nicht die Möglichkeit von unbefugtem Zugriff zu gewähren. Gerade bei Funktionen welche auf interne Ressourcen zugreifen ist dies ein springender Punkt. Wie auch bei einer API keine personenbezogene oder anderweitig geschützte Daten an Unbefugte weitergegeben werden sollten, ist auch bei MCP darauf zu achten. So ist es sehr wichtig, dass alle Zugriffe nur mit valider Authentifizierung und entsprechender Autorisierung geschehen dürfen. ### Authentifizierung und Autorisierung Das Model Context Protocol bietet auf Transportebene bereits Autorisierungsfähigkeiten. Während Autorisierung bei MCP Implementationen optional ist, ist diese in den meisten Fällen trotzdem empfohlen. Wenn Autorisierung implementiert wird, schreibt MCP vor, *OAuth 2.1* zu nutzen.[^12] Gerade bei Streamable HTTP sollten alle Verbindung korrekt authentifiziert werden. ### DNS rebinding Attacken Während durch Authentifizierung und Autorisierung bereits der Zugriff gehärtet werden kann, gibt es trotzdem noch einige andere Punkte welche potentielle Schwachstellen darstellen könnten. Eine Empfehlung von Anthropic ist beispielsweise, dass der `Origin` Header bei allen eingehenden Verbindungen validiert wird, um DNS Rebinding Attacken zu vermeiden.[^13] Auch sollte der Server nur auf den localhost anstatt auf alle Netzwerk Interfaces gebunden werden. Werden diese Massnahmen nicht vorgenommen, ist es einem Angreifer möglich, über eine remote Website auf lokale MCP Server zuzugreifen.[^11] ### Runtime-Environment Sicherheit Eine weitere Empfehlung welche bei der Veröffentlichung von MCP Servern gegeben wird, ist die Applikation in einer isolierten Sandbox laufen zu lassen. So können sensitive Ressourcen bereits auf Infrastruktur-Ebene geschützt werden.[^9] ## Risiken von MCP Während der Betrieb eines MCP Servers für das entsprechende Unternehmen mit Datensicherheitsrisiken kommt, gibt es auch aus Benutzer-Sicht immer Risiken. ### Server Trust Probleme Da es noch wenige offizielle MCP Server gibt, muss bei den meisten Anwendungen noch auf Benutzerentwickelte Alternativen zurückgegriffen werden. Diesen Servern fehlen entsprechend wichtige Sicherheitsprüfungen. So können auch sehr einfach böswillige MCP Server veröffentlicht und beworben werden. Werden solche böswillige Server in einen Client eingebunden, kann dieser sich darin austoben. Werden keine gründlichen Checks vorab gemacht, kann es zu unautorisierten Zugriffen und Datenleaks kommen, oder das System kann kompromittiert werden.[^9] #### Consent Fatigue Grundsätzlich könnte argumentiert werden, dass die Benutzerkontrollierte Zugriffskontrolle auf Tools bereits diesem Risiko entgegenwirkt. Zugriff wird nur gegeben, wenn das Sprachmodell auf eine absolut nötige Ressource zugreifen möchte. Dabei gibt es jedoch von Benutzerseite ein Risiko. Eine mögliche Strategie für böswillige MCP Server wäre, dass der Benutzer mit sehr vielen Zugriffsbestätigungen "überflutet" wird, was bei den meisten dazu führen würde, dass die angefragten Berechtigungen nicht mehr geprüft sondern einfach angenommen werden. So könnten problemlos trotz nötiger Einwilligung des Benutzers noch Tools eingebunden werden, die nicht ihren eigentlichen Zweck erfüllen.[^9] #### Offizielle Registry Gemäss der Roadmap[^10] ist eine offizielle MCP Registry geplant, was diesem Risiko signifikant entgegen wirken würde. Bis diese jedoch verfügbar ist, muss jeder Benutzer seine verwendeten Server prüfen und auf Vertrauensbasis von einer allfälligen Nutzung absehen. ## Fazit MCP bietet einen standardisierten Weg um generative Sprachmodelle mit Funktionalität und Datenzugriff zu erweitern. Die Möglichkeiten sind hierbei nur durch die Kreativität der Entwickler begrenzt. Auch wenn das Projekt noch sehr jung ist, hat es sich bereits in vielen respektablen Unternehmen etabliert und wird daher mit grösster Wahrscheinlichkeit auch bleiben. [^1]: vgl. Introduction, in: MCP Documentation, 02.04.2025, https://modelcontextprotocol.io/introduction [^2]: vgl. Architecture, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/architecture [^3]: vgl. Prompts, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/server/prompts [^4]: vgl. Resources, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/server/resources [^5]: vgl. Tools, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/server/tools [^6]: vgl. Roots, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/client/roots [^7]: vgl. Sampling, in: Model Context Protocol Specification, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/client/sampling [^8]: vgl. Transports, in: Model Context Protocol Specification, 23.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/basic/transports [^9]: MCP Security Exposed: What You Need to Know, in: Paloalto Community Blogs, 23.04.2023, https://live.paloaltonetworks.com/t5/community-blogs/mcp-security-exposed-what-you-need-to-know-now/ba-p/1227143 [^10]: vgl. Registry, in: MCP Roadmap, 28.04.2025, https://modelcontextprotocol.io/development/roadmap#registry [^11]: vgl. Server-Sent Events (SSE), in: MCP Transports, 16.04.2025, https://modelcontextprotocol.io/docs/concepts/transports [^12]: vgl. Authorization, in: Model Context Protocol Specifications, 22.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization [^13]: vgl. Transports, in: Model Context Protocol Specification, 23.04.2025, https://modelcontextprotocol.io/specification/2025-03-26/basic/transports