Zum Inhalt
Bytearium

Keine Werbung und keine Partnerlinks aktiv

KI & Automatisierung

Model Context Protocol (MCP)

MCP, das Model Context Protocol, verbindet KI-Anwendungen mit Werkzeugen und Daten. Wie Host, Client und Server zusammenspielen und wo die Risiken liegen.

Dieser Eintrag liegt noch unter unserer Mindestlatte für den Suchindex (Umfang und Zahl der Quellen) und wird überarbeitet. Er ist deshalb nicht in Suchmaschinen gelistet.

Dein KI-Assistent liest plötzlich deinen Kalender, fragt eine Datenbank ab und legt Tickets an. Dahinter steckt meist keine Magie, sondern ein kleines Protokoll mit großer Reichweite – und jeder Server, den du anschließt, sitzt mit am Tisch.

Kurz gesagt

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das Anwendungen mit Sprachmodellen einheitlich an externe Datenquellen und Werkzeuge anbindet [1]. Was heißt das konkret? Eine Anwendung, der Host, spricht über eingebaute Clients mit MCP-Servern; die Nachrichten folgen JSON-RPC 2.0, und Server bieten Werkzeuge (Tools), Ressourcen und Prompts an [1][2]. Aktuell ist die Protokollversion 2026-07-28 (Stand 25. Okt. 2026) [3]. Unsere Einschätzung: MCP macht Anbindungen leicht, und genau deshalb solltest du jeden Server wie installierte Software behandeln und nicht wie ein harmloses Plug-in.

So funktioniert’s

  1. Drei Rollen. Hosts sind Anwendungen mit Sprachmodell, die Verbindungen aufbauen, Clients sind Verbindungsstücke im Host, und Server liefern Kontext und Fähigkeiten [1]. Vorbild war das Language Server Protocol, das vereinheitlicht hat, wie Entwicklungswerkzeuge Programmiersprachen unterstützen [1].
  2. Was ein Server anbietet. Ressourcen sind Kontext und Daten für Nutzer oder Modell, Prompts sind Vorlagen für Nachrichten und Abläufe, und Tools sind Funktionen, die das Modell ausführen kann [1]. In der Gegenrichtung kann ein Client Elicitation anbieten: Der Server fragt beim Nutzer fehlende Angaben nach [1].
  3. Zustandslos seit 2026-07-28. Alle Nachrichten folgen JSON-RPC 2.0 [2]. Die aktuelle Version hat den alten Initialisierungs-Handshake gestrichen, jede Anfrage bringt Protokollversion und Client-Fähigkeiten nun selbst mit [2][4]. Außerdem gelten Roots, Sampling und Logging jetzt als veraltet [4].
  4. Lokal oder entfernt. Die meisten lokalen Server nutzen den Transport stdio: Der Host startet den Server als Kindprozess und spricht über Standardein- und -ausgabe mit ihm. Ein entfernter Server über Streamable HTTP führt keinen Code auf deinem Rechner aus und nutzt den Autorisierungsablauf des Protokolls [5]. Für HTTP-Transporte legt die Spezifikation einen Rahmen für die Autorisierung fest, stdio-Server holen ihre Zugangsdaten dagegen aus der Umgebung [2].
  5. Wer es pflegt. Am 9. Dez. 2025 hat Anthropic MCP an die Agentic AI Foundation übergeben, einen zweckgebundenen Fonds unter dem Dach der Linux Foundation; über die technische Richtung entscheiden weiter die Maintainer [6].
  6. Das Risiko. Laut Spezifikation stehen Tools für beliebige Codeausführung, und Tool-Beschreibungen gelten als nicht vertrauenswürdig, solange sie nicht von einem vertrauenswürdigen Server stammen; vor jedem Tool-Aufruf muss der Host die ausdrückliche Zustimmung des Nutzers einholen [1]. Ein lokaler Server ist ein gewöhnlicher Prozess mit den Rechten deines Kontos: Er kann deine Dateien, Umgebungsvariablen und SSH-Schlüssel lesen und sich mit beliebigen Zielen verbinden [5]. Tool-Namen und -Beschreibungen liest das Modell als Anweisungen, ein bösartiger Server kann so sogar steuern, wie der Agent die Tools anderer Server nutzt [5].

Ein Praxisbeispiel

Automatisierungswerkzeuge sprechen MCP in beide Richtungen. In n8n macht der Knoten MCP Server Trigger aus n8n einen MCP-Server, der ausgewählte Tools und Workflows für MCP-Clients bereitstellt, über Server-Sent Events oder Streamable HTTP und auf Wunsch mit Bearer- oder Header-Authentifizierung [7]. Der Knoten MCP Client macht das Gegenteil und führt die Tools eines externen MCP-Servers als Schritte im Workflow aus [8]. Bevor du einen Assistenten an so einen Endpunkt hängst, schaltest du die Authentifizierung ein, liest jede Tool-Beschreibung und gibst dem Workflow nur die Konten, die er braucht. Das ist ein allgemeiner Ablauf und kein Bericht aus unserem eigenen Aufbau.

Prüfliste

  • Prüfe, wer einen Server veröffentlicht, und lege seine Version fest, bevor du ihn installierst [5].
  • Lies die Tool-Beschreibungen und entferne jeden Server, dessen Beschreibungen Anweisungen enthalten, die nichts mit seiner Aufgabe zu tun haben [5].
  • Lass lokale Server von Dritten in einem Container oder einer VM laufen, die nur das nötige Verzeichnis sieht [5].
  • Gib jedem Server ein eigenes, eng begrenztes Token statt eines globalen aus deinem Shell-Profil [5].
  • Verlange Authentifizierung an jedem MCP-Endpunkt, den du bereitstellst, zum Beispiel in n8n [7].
  • Bestätige Tool-Aufrufe selbst, statt den Host sie unbeaufsichtigt ausführen zu lassen [1].

Primärquellen

Diese Quellen sind die Grundlage der Seite. Das heißt nicht, dass jede Aussage einzeln nachgeprüft wurde; ob ein Prüfbeleg vorliegt, steht oben unter „Stand“. Einordnung und Prüfliste sind unsere eigene Arbeit.

Für diese Fassung liegt noch kein dokumentierter Prüfbeleg vor. Der Text stützt sich auf die genannten Quellen.

Entstehung: Bytearium erstellt diese Seiten mit Unterstützung von KI und verantwortet die Veröffentlichung. KI kann sich irren, deshalb nennen wir Quellen und Prüfstand offen.

  1. Model Context ProtocolSpecification, revision 2026-07-28
  2. Model Context ProtocolBase Protocol – Overview
  3. Model Context ProtocolVersioning
  4. Model Context ProtocolKey Changes
  5. Model Context ProtocolLocal Server Security
  6. Model Context Protocol BlogMCP joins the Agentic AI Foundation
  7. n8nMCP Server Trigger node
  8. n8nMCP Client node

Auf dieser Seite gibt es keine Werbung und keine Partnerlinks.