Was ist MCP (Model Context Protocol)? Der Leitfaden

Veröffentlicht:

15 Min. Lesezeit

Acar Diveroli
Autor: Acar Diveroli
Verbindungen, die von einem LLM-Würfel zu einem zentralen MCP-Server und weiter zu Web-, Code- und Dateitools verzweigen

Stellen Sie sich vor, ein KI-Assistent soll auf interne Dokumente, eine Datenbank, ein Code-Repository und das Web zugreifen. Vor MCP bedeutete das, für jedes Tool in jeder Assistenzanwendung eine eigene Integration zu schreiben: ein Datenbank-Plugin für den Assistenten im Code-Editor, ein weiteres Plugin für dieselbe Datenbank in der Chat-App und eine dritte Version für interne Tools. Mit der Zahl der Tools und Anwendungen vervielfachte sich die Zahl der Integrationen.

MCP (Model Context Protocol) löst das, indem Sie ein Tool einmal als „MCP-Server" schreiben und in jeder KI-Anwendung mit MCP-Unterstützung nutzen. In diesem Artikel erklären wir, was MCP ist, welches Problem es löst, die Host-Client-Server-Architektur, die Tools, Ressourcen und Prompts, die Server anbieten, und die zwei Standard-Transportwege. Danach behandeln wir, wie ein MCP-Server an Webdaten kommt und wo ein Proxy ins Spiel kommt, die Sicherheitsrisiken des Protokolls, den Unterschied zwischen MCP und der direkten Nutzung einer API sowie den kleinsten lauffähigen MCP-Server in Python.

Was ist MCP?

Model Context Protocol ist ein offenes Protokoll, das standardisiert, wie Anwendungen mit großen Sprachmodellen an externe Datenquellen und Tools angebunden werden. Die offizielle Spezifikation des Protokolls legt die Kommunikation mit JSON-RPC-2.0-Nachrichten fest und vergleicht sich mit dem Language Server Protocol (LSP), das die Unterstützung von Programmiersprachen in Entwicklungswerkzeugen standardisiert hat. So wie LSP es erlaubte, Sprachunterstützung einmal zu schreiben und in jedem Editor zu nutzen, will MCP ermöglichen, ein Tool einmal zu schreiben und in jeder KI-Anwendung mit MCP zu nutzen.

Um MCP zu verstehen, hilft es, zwei Dinge zu trennen:

  • MCP ist weder ein Modell noch ein KI-Produkt. Es ist ein Kommunikationsvertrag: Es legt Format und Bedeutung der Nachrichten zwischen einer Anwendung und einem Tool fest.
  • MCP schreibt das Tool nicht für Sie. Eine Datenbankabfrage, eine Webanfrage oder eine Dateioperation bleibt Ihr Code; MCP erlaubt, diesen Code in einer Form bereitzustellen, die KI-Anwendungen entdecken und aufrufen können.

Die Versionen der Spezifikation werden nach Datum benannt. Beim Schreiben dieses Artikels ist 2026-07-28 die aktuelle Version, und sie enthält gegenüber früheren Versionen eine wichtige Änderung: Das Protokoll ist zustandslos; jede Anfrage trägt ihre eigene Protokollversion und Client-Fähigkeiten. In früheren Versionen wurde zu Beginn der Verbindung mit einem Handshake (initialize) eine Sitzung aufgebaut. Weil sich das Protokoll schnell entwickelt, empfehlen wir, vor dem Schreiben einer Integration die aktuelle Spezifikation zu prüfen.

Welches Problem löst MCP?

MCP löst das Problem der „N × M Integrationen". Gibt es fünf KI-Anwendungen und zehn Tools, braucht es fünfzig einzelne Integrationen, damit jede Anwendung mit jedem Tool sprechen kann. Jede Integration wird separat geschrieben, separat getestet und bei Änderungen am Tool separat aktualisiert.

Mit MCP wird daraus „N + M":

  • Jedes Tool wird einmal als MCP-Server geschrieben.
  • Jede KI-Anwendung erhält einmal MCP-Unterstützung.
  • Jede Anwendung mit MCP-Unterstützung kann jeden MCP-Server nutzen.

In der Praxis: Schreibt ein Unternehmen einen MCP-Server für seine interne Wissensdatenbank, erreichen Mitarbeitende diese Wissensdatenbank über denselben Server aus dem Assistenten im Code-Editor, aus einer Desktop-Chat-App oder aus einem selbst gebauten Agenten.

Architektur: Host, Client und Server

Der Architekturabschnitt der Spezifikation definiert drei Rollen.

KomponenteWas ist das?Aufgaben
HostDie KI-Anwendung selbst (Code-Editor, Chat-App, Agent)Erstellt und verwaltet Clients, kontrolliert Verbindungsberechtigungen und Nutzerzustimmung, ruft das Modell auf, führt den Gesprächsverlauf
ClientDer Konnektor im HostSpricht mit genau einem Server, hängt jeder Anfrage Protokollversion und Fähigkeiten an, hält die Sicherheitsgrenze zwischen Servern
ServerDas Programm, das Tool oder Datenquelle anbietetBietet Tools, Ressourcen und Prompts; kann ein lokaler Prozess oder ein entfernter Dienst sein

Eines der wichtigsten Designprinzipien der Architektur ist Isolierung: Ein Server kann weder das ganze Gespräch lesen noch in andere Server hineinsehen. Der Gesprächsverlauf bleibt beim Host; der Server erhält nur die Informationen, die er für seine Aufgabe braucht. Auch Interaktionen zwischen Servern kontrolliert der Host.

Eine Nutzeranfrage durchläuft diese Struktur so:

  1. Der Nutzer gibt eine Anfrage in die Host-Anwendung ein.
  2. Der Host gibt dem Modell die Liste der Tools der verbundenen Server mit ihren Beschreibungen.
  3. Das Modell entscheidet sich für ein Tool und erzeugt einen Tool-Aufruf.
  4. Der Host holt bei Bedarf die Zustimmung des Nutzers ein und reicht den Aufruf an den zuständigen Client weiter.
  5. Der Client sendet die Anfrage an den Server; der Server führt das Tool aus und liefert das Ergebnis.
  6. Der Host gibt das Ergebnis an das Modell, und das Modell erzeugt eine Antwort für den Nutzer.

Die allgemeine Logik der Tool-Aufrufschleife erklären wir ausführlich in Wie funktionieren KI-Agenten?.

Was bietet ein MCP-Server an?

Ein MCP-Server kann drei grundlegende Arten von Fähigkeiten anbieten:

  • Tools: Funktionen, deren Ausführung das Modell anfordern kann. Eine Webseite abrufen, eine Abfrage auf einer Datenbank ausführen, einen Datensatz anlegen. Jedes Tool hat einen Namen, eine Beschreibung, die dem Modell hilft zu verstehen, wann es zu nutzen ist, und mit JSON Schema definierte Parameter.
  • Ressourcen (Resources): Daten, die Nutzer oder Modell als Kontext nutzen können. Der Inhalt einer Datei, ein Datenbankschema, ein Dokument. Anders als Tools lösen sie keine Aktionen aus; sie liefern Informationen.
  • Prompts (Prompt-Vorlagen): fertige Nachrichtenvorlagen und Abläufe, die der Nutzer auswählen kann. Etwa eine parametrisierte Vorlage wie „Analysiere dieses Fehlerprotokoll".

Server können den Client außerdem um zusätzliche Eingaben bitten, um eine Anfrage abzuschließen: fehlende Informationen beim Nutzer erfragen (Elicitation) oder das Modell des Hosts Text erzeugen lassen (Sampling). In der aktuellen Spezifikation werden diese Anfragen innerhalb der Serverantwort übermittelt.

Über dem Protokollkern sind Funktionen wie die Verwaltung lang laufender Aufgaben oder interaktive Oberflächenelemente im Gespräch als optionale Erweiterungen definiert; Client und Server müssen sie ausdrücklich unterstützen.

Transportwege: stdio und Streamable HTTP

Wie MCP-Nachrichten zwischen beiden Seiten transportiert werden, legt der Transportabschnitt der Spezifikation fest. Es gibt zwei Standardwege:

KriteriumstdioStreamable HTTP
Wie funktioniert es?Der Client startet den Server als Unterprozess; Nachrichten fließen zeilenweise über Standardein- und -ausgabeJede Nachricht geht als HTTP-POST an einen einzigen MCP-Endpunkt; die Antwort kommt als JSON-Objekt oder als anfragebezogener SSE-Stream zurück
Wo läuft der Server?Auf dem Computer des Nutzers, auf derselben Maschine wie der HostAuf einem entfernten Server oder in der Cloud
AuthentifizierungLäuft mit den Rechten des BetriebssystemnutzersAuf HTTP-Ebene, meist OAuth-basierte Autorisierung
Typischer EinsatzLokale Dateien, lokale Entwicklungswerkzeuge, persönliche NutzungVon einem Team oder unternehmensweit geteilte Dienste
AbbruchEine Abbruchbenachrichtigung wird gesendetDer Antwortstream der Anfrage wird geschlossen

Die Bedeutung des Protokolls ist in beiden Wegen gleich; nur die Zustellung der Nachrichten ändert sich. Für besondere Anforderungen können auch andere Transportwege definiert werden.

Bedenken Sie, dass ein über stdio laufender Server mit allen Rechten des Nutzers läuft, der ihn gestartet hat. Ein MCP-Server, den Sie auf Ihrem Computer installieren, kann im selben Umfang auf Ihre Dateien und Ihr Netz zugreifen wie Sie.

Wie kommt ein MCP-Server an Webdaten?

Aktuelle Webdaten gehören zu den Fähigkeiten, die KI-Anwendungen am häufigsten brauchen. Ein MCP-Server liefert sie meist auf einem von drei Wegen:

  • Such-Tool: sendet eine Anfrage an eine Such-API und liefert eine Liste von Titeln und Adressen.
  • Tool zum Seitenabruf: ruft eine bestimmte Adresse mit einem HTTP-Client ab und liefert deren Text.
  • Browser-Tool: steuert einen Headless-Browser; öffnet Seiten, die per JavaScript laden, klickt und erstellt Screenshots.

Netzwerkseitig sind diese Tools gewöhnliche HTTP-Anfragen, und jede Regel des Web Scrapings gilt auch hier. In diesem Aufbau sitzt der Proxy am Ausgangspunkt des Servers zur Außenwelt:

  • Standort: Der Server nutzt eine Adresse aus einem bestimmten Land, um abzurufen, wie ein Produkt oder Inhalt von dort aussieht. Für Aufgaben, die die Sicht eines echten Privatanschlusses brauchen, wird ein Residential-Proxy bevorzugt.
  • Lastverteilung: Ein Tool, das viele verschiedene öffentliche Seiten abruft, kann mit einem Rotierender Proxy Anfragen über eine Adresse auf verschiedene Ausgangs-IPs verteilen; Rate-Limits und Regeln der Websites gelten weiterhin.
  • Ausgangskontrolle und Protokollierung: Welche Domains der Server erreicht, wird an einer Stelle überwacht und begrenzt.
  • Isolierung: Der Webverkehr des Servers bleibt vom internen Netz und den Haupt-IP-Adressen des Unternehmens getrennt.

Wie Sie ein Tool für Webzugriff mit Positivliste, Rate-Limits, Sperre interner Netzwerkadressen und Inhaltsbereinigung sicher machen, erklären wir mit getestetem Beispiel in Sicherer Webzugriff für LLMs: Rate-Limits und Berechtigungen. Den allgemeinen Aufbau der Datenerfassung zeigt unsere Seite zur Datenerfassung.

Der kleinste MCP-Server

Das folgende Beispiel ist ein MCP-Server mit einem einzigen Tool, geschrieben mit dem offiziellen Python-SDK. Das Tool ruft nur HTTPS-Seiten erlaubter Domains ab und sendet die Anfrage über einen optionalen Ausgangs-Proxy. In Version 2 des SDK heißt die Serverklasse MCPServer; FastMCP-Beispiele aus Version 1 laufen auf dieser Version nicht direkt.

bash
pip install mcp httpx
python
# server.py
import os
from urllib.parse import urlsplit

import httpx
from mcp.server.mcpserver import MCPServer

ALLOWED = {d.strip().lower() for d in os.environ.get("ALLOWED_DOMAINS", "example.com").split(",")}
PROXY = os.environ.get("EGRESS_PROXY")  # z. B. http://user:pass@pr.proxynet.io:8000

mcp = MCPServer("web-reader")


@mcp.tool()
async def fetch_page(url: str) -> str:
    """Liefert die ersten 5.000 Zeichen einer Seite auf einer erlaubten Domain."""
    parts = urlsplit(url)
    if parts.scheme != "https" or (parts.hostname or "").lower() not in ALLOWED:
        return f"Diese Adresse steht nicht auf der Positivliste: {url}"
    async with httpx.AsyncClient(proxy=PROXY, timeout=15, follow_redirects=False) as client:
        response = await client.get(url, headers={"User-Agent": "ExampleMCP/1.0"})
    return response.text[:5000]


if __name__ == "__main__":
    mcp.run(transport="stdio")

Der Funktionsname wird zum Namen des Tools, der Docstring zur Beschreibung, und die Typangaben werden zum Parameterschema. Das SDK wandelt das automatisch in eine MCP-Tooldefinition um.

Um den Server von einem Client aus aufzurufen:

python
# client.py
import asyncio
import sys

from mcp.client.session import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client

SERVER = StdioServerParameters(
    command=sys.executable,
    args=["server.py"],
    env={"ALLOWED_DOMAINS": "example.com", "EGRESS_PROXY": "http://user:pass@pr.proxynet.io:8000"},
)


async def main():
    async with stdio_client(SERVER) as (read, write):
        async with ClientSession(read, write) as session:
            await session.discover()  # Version und Fähigkeiten des Servers erfahren
            tools = await session.list_tools()
            print([t.name for t in tools.tools])

            result = await session.call_tool("fetch_page", {"url": "https://example.com/"})
            print(result.content[0].text[:200])


asyncio.run(main())

Beachten Sie zwei Details. Erstens erfährt der Client vor dem Auflisten der Tools mit discover(), welche Protokollversion und Fähigkeiten der Server unterstützt; wird dieser Schritt übersprungen, lehnt der Server die Anfrage mit einem Fehler wegen ungültiger Parameter ab. Für Server mit älteren Protokollversionen gibt es im SDK außerdem den Aufruf initialize(). Zweitens übergibt das SDK beim Start eines stdio-Servers nicht alle Umgebungsvariablen, sondern nur eine begrenzte Liste wie PATH; Werte, die der Server braucht, etwa ALLOWED_DOMAINS und EGRESS_PROXY, müssen ausdrücklich mit dem Parameter env übergeben werden.

Im echten Einsatz schreiben Sie den Client nicht selbst; Sie tragen den Server in die Einstellungen einer Host-Anwendung mit MCP-Unterstützung ein, und der Host startet ihn. Dieser Beispiel-Client genügt, um zu testen, ob der Server korrekt arbeitet.

Das Beispiel ist bewusst klein. In der Produktion sollten diesem Tool Rate-Limits, eine Prüfung auf interne Netzwerkadressen, ein Größenlimit für Antworten und eine Inhaltsbereinigung hinzugefügt werden.

Sicherheitsrisiken

Dass MCP-Tools beliebigen Code ausführen und Inhalte aus externen Quellen abrufen können, macht das Protokoll so riskant, wie es mächtig ist. Die Spezifikation selbst nennt Nutzerzustimmung, Datenschutz und Tool-Sicherheit als Grundprinzipien und verlangt von Hosts, vor dem Aufruf eines Tools die ausdrückliche Zustimmung des Nutzers einzuholen. Die wichtigsten Risiken:

  • Tool Poisoning. Weil das Modell anhand der Beschreibung entscheidet, wie es ein Tool nutzt, kann ein bösartiger Server in der Beschreibung Anweisungen an das Modell verstecken. Die Spezifikation sagt, dass Tool-Beschreibungen und -Annotationen als nicht vertrauenswürdig zu behandeln sind, sofern sie nicht von einem vertrauenswürdigen Server stammen.
  • Übermäßige Berechtigungen. Einem Server mehr Zugriff geben, als er braucht: Schreibzugriff für eine reine Leseaufgabe, das ganze Dateisystem statt eines Ordners, ein Admin-Konto statt einer Datenbanktabelle.
  • Prompt Injection über Tool-Ergebnisse. Der Inhalt, den ein Tool zum Seitenabruf liefert, kann Text enthalten, der wie Anweisungen an das Modell aussieht. Folgt das Modell diesen Anweisungen, ruft es womöglich ein Tool auf einem anderen Server auf.
  • Tokens weiterreichen. Leitet ein MCP-Server ein erhaltenes Zugriffstoken ungeprüft an andere Dienste weiter, können Autorisierungsprüfungen umgangen werden. Das Dokument mit Sicherheitsempfehlungen des Protokolls verbietet diese Art der Token-Weitergabe ausdrücklich und verlangt, dass Server nur für sie ausgestellte Tokens akzeptieren.
  • SSRF. Ein bösartiger Server kann den Client während des Autorisierungsablaufs dazu bringen, Anfragen an interne Netzwerkadressen oder Cloud-Metadatenadressen zu senden.
  • Nicht vertrauenswürdige lokale Server. Weil stdio-Server mit den Rechten des Nutzers laufen, gleicht die Installation eines Servers ungeprüfter Herkunft dem Ausführen eines ungeprüften Programms.

Praktische Maßnahmen:

  • Installieren Sie nur Server, deren Quelle Sie kennen und deren Code Sie prüfen können.
  • Geben Sie jedem Server die geringsten nötigen Rechte; teilen Sie Aktionen wie Schreiben und Löschen in eigene Tools auf.
  • Schalten Sie die Nutzerzustimmung für Tool-Aufrufe mit Nebenwirkungen nicht ab.
  • Kennzeichnen Sie die Ausgabe von Tools, die Webinhalte abrufen, als nicht vertrauenswürdige Daten.
  • Prüfen Sie bei entfernten Servern die Zielgruppe (Audience) des Tokens und reichen Sie Tokens nicht weiter.
  • Protokollieren Sie Tool-Aufrufe und achten Sie auf unerwartete Aufruffolgen.

Der Unterschied zwischen MCP und einer API

MCP ersetzt keine API; die meisten MCP-Server kapseln ohnehin eine. Der Unterschied liegt darin, für wen sie gestaltet sind.

KriteriumDirekte Nutzung einer APIMCP-Server
NutzerVon Entwicklern geschriebener AnwendungscodeDie KI-Host-Anwendung und das Modell
EntdeckungEntwickler liest die DokumentationDer Host holt Toolliste und Schemas zur Laufzeit
Wer löst den Aufruf aus?Code, mit vorab festgelegter LogikDas Modell, je nach Situation
Zahl der IntegrationenFür jede Anwendung separatEinmal geschrieben, in jedem MCP-Host genutzt
VorhersagbarkeitHochAbhängig von der Entscheidung des Modells
SicherheitsmodellEigene Autorisierung der AnwendungHost-Zustimmung, Server-Isolierung, geringste Rechte
Geeignete ArbeitFeste Abläufe, System-zu-System-IntegrationKI-Assistenten und Agenten Fähigkeiten geben

MCP oder direkte API?

Ihre SituationEmpfehlung
Ihr Anwendungscode ruft einen bestimmten Dienst in festem Ablauf aufDirekte API
Sie wollen ein Tool in mehreren KI-Anwendungen nutzenMCP-Server
Das Modell soll entscheiden, welches Tool wann genutzt wirdMCP-Server
Die Aktion ist unumkehrbar und jeder Schritt braucht strenge KontrolleDirekte API oder bei Bedarf ein MCP-Tool mit Zustimmung
Eine interne Ressource für die Assistenten von Mitarbeitenden öffnenEntfernter MCP-Server mit Autorisierung
Ein einzelnes lokales EntwicklungswerkzeugLokaler stdio-MCP-Server

Anwendungsfälle

  • Entwicklerwerkzeuge: Den Assistenten im Code-Editor Code-Repository, Fehlerprotokolle und Dokumentation lesen lassen.
  • Zugriff auf internes Wissen: Die Assistenten von Mitarbeitenden das interne Wiki, Support-Tickets und Produktdokumentation durchsuchen lassen.
  • Datenanalyse: Eine Datenbank als schreibgeschützten MCP-Server bereitstellen, damit Analysten in natürlicher Sprache abfragen können.
  • Webrecherche: Agenten erreichen aktuelle Informationen über ein Tool zum Seitenabruf mit Positivliste und Rate-Limits. Ein Beispiel, wie Sprachmodelle strukturierte Informationen aus Webdaten gewinnen, finden Sie in Web Scraping mit GPT-6 Astra.
  • Betriebswerkzeuge: Metriken aus Überwachungssystemen lesen und Vorfallszusammenfassungen erstellen; Eingriffe in eigenen Tools, die eine Freigabe verlangen.

Häufige Fehler

  • Server unbekannter Herkunft installieren. Die Installation eines MCP-Servers verlangt dasselbe Vertrauen wie das Ausführen eines Programms.
  • Einem Server alle Rechte geben. Lese- und Schreib-Tools nicht trennen.
  • Kurze, vage Tool-Beschreibungen schreiben. Das Modell ruft das Tool in der falschen Situation auf.
  • Tool-Ergebnisse als vertrauenswürdige Inhalte behandeln. Web- und Dokumentinhalte können Anweisungen enthalten.
  • Zustimmungsschritte abschalten. Nutzerzustimmung ist eine grundlegende Sicherheitsebene, besonders bei Tools mit Nebenwirkungen.
  • Die Version der Spezifikation nicht prüfen. Weil sich das Protokoll schnell entwickelt, funktionieren für ältere Versionen geschriebene Beispiele womöglich nicht mit aktuellen SDKs.

Häufig gestellte Fragen

Wer hat MCP entwickelt?

MCP wurde von Anthropic als offenes Protokoll angekündigt und wird mit Spezifikation, SDKs und Dokumentation als Open-Source-Projekt entwickelt. KI-Anwendungen und Tools verschiedener Unternehmen unterstützen das Protokoll.

Funktioniert MCP nur mit einem bestimmten KI-Modell?

Nein. MCP legt die Kommunikation zwischen einer Anwendung und einem Tool fest und ist modellunabhängig. Welches Modell die Host-Anwendung auch nutzt, sie bietet diesem Modell die Tools der MCP-Server an.

In welchen Sprachen kann ich einen MCP-Server schreiben?

Das Projekt bietet offizielle SDKs für viele Sprachen, allen voran Python und TypeScript. Weil das Protokoll auf JSON-RPC beruht, lässt sich ein Server auch in einer Sprache ohne SDK schreiben, indem man der Spezifikation folgt.

Was ist der Unterschied zwischen MCP und Function Calling?

Function Calling ist die Fähigkeit eines Modells, strukturierte Tool-Aufrufe zu erzeugen, und ist spezifisch für die API des Modellanbieters. MCP ist das Protokoll, mit dem diese Tools anwendungsübergreifend standardisiert definiert, entdeckt und aufgerufen werden. Der Host bietet die Tools, die er von MCP-Servern erhält, dem Modell über Function Calling an.

Wie wähle ich zwischen lokalem und entferntem MCP-Server?

Für persönliche Nutzung und Zugriff auf lokale Dateien genügt ein lokaler Server über stdio. Für Tools, die ein Team oder Unternehmen teilt und die zentral verwaltet und autorisiert werden müssen, passt ein entfernter Server über Streamable HTTP.

Wie wird ein Proxy genutzt, wenn ein MCP-Server auf das Web zugreift?

Der Proxy wird an den HTTP-Client oder Browser im Server übergeben; mit dem MCP-Protokoll selbst hat er nichts zu tun. Im Beispiel oben wird die Proxy-Adresse aus einer Umgebungsvariablen gelesen und an den HTTP-Client übergeben, sodass der gesamte Webverkehr des Servers über einen kontrollierten Ausgangspunkt läuft.

Fazit

MCP ist ein offenes Protokoll, das KI-Anwendungen standardisiert mit Tools und Datenquellen verbindet. Jeder Client in einer Host-Anwendung verbindet sich mit einem Server; Server bieten Tools, Ressourcen und Prompt-Vorlagen; Nachrichten werden mit JSON-RPC über stdio oder Streamable HTTP transportiert. Die aktuelle Spezifikation ist zu einer zustandslosen Struktur übergegangen, und das Protokoll entwickelt sich schnell. Weil Tools Code ausführen und externe Inhalte abrufen können, müssen geringste Rechte, Nutzerzustimmung, der Umgang mit nicht vertrauenswürdigen Inhalten und Protokollierung Teil des Designs sein. Um den Webzugriff Ihrer MCP-Server mit Standort- und Ausgangskontrolle zu steuern, sehen Sie sich unsere Proxy-Dienste an.

ChatGPT fragenClaude fragen