Model Context Protocol: 30 Fragen und Antworten zum offenen Standard für KI-Integrationen

Model Context Protocol: Der offene Standard für KI-Integrationen  

KI-Anwendungen wie Claude, ChatGPT oder Cursor benötigen Zugriff auf externe Daten, Tools und APIs, um wirklich nützlich zu sein. Bisher erforderte jede Integration eine maßgeschneiderte Anbindung – ein fragmentiertes M-mal-N-Problem, bei dem jede Kombination aus KI-Anwendung und Datenquelle individuell gelöst werden musste. Das Model Context Protocol (MCP) löst dieses Problem durch einen offenen Standard, der KI-Anwendungen auf einheitliche Weise mit externen Systemen verbindet .

Anthropic hat MCP Ende 2024 veröffentlicht und beschreibt es als "USB-C für KI-Anwendungen" : Statt für jede Datenquelle einen eigenen Adapter zu bauen, definiert MCP ein universelles Protokoll, über das beliebige KI-Hosts mit beliebigen Servern kommunizieren. Das Protokoll basiert auf JSON-RPC 2.0, unterstützt zustandsbehaftete Verbindungen und wird mittlerweile von einer breiten Allianz getragen – darunter Claude, VS Code, Cursor, Gemini CLI, Amazon Q und viele mehr; bei ChatGPT ist der Umfang laut OpenAI aktuell plan-, modus- und einsatzabhängig .

Ob Sie MCP zum ersten Mal einsetzen oder Ihre bestehende Architektur optimieren – hier finden Sie 30 fundierte Antworten, von den Grundlagen über die Architektur bis zu Sicherheit und Best Practices.

Interaktive Demo: MCP in Aktion  

Erleben Sie die drei Kernkonzepte von MCP Schritt für Schritt -- von der Architektur über den JSON-RPC-Lifecycle bis zum Tool-Aufruf:

JSON-RPC-Nachricht erscheint nach Start...

Antwort erscheint nach Simulation...

Inhaltsverzeichnis  

Schnellübersicht: Alle 30 Fragen  

Klicken Sie auf eine Frage, um zur ausführlichen Antwort zu springen.

Kategorie 1: Grundlagen & Konzepte  

Kategorie 2: Architektur & Komponenten  

Kategorie 3: Transport & Verbindungen  

Kategorie 4: Server-Features im Detail  

Kategorie 5: Ökosystem & Clients  

Kategorie 6: Sicherheit & Best Practices  

Kategorie 7: Praxis, Dos & Don'ts  

1.1. Was ist das Model Context Protocol und welches Problem löst es?  

Kurze Antwort: MCP ist ein offener Standard von Anthropic, der KI-Anwendungen über ein einheitliches Protokoll mit externen Datenquellen, Tools und APIs verbindet – und damit das M-mal-N-Problem fragmentierter Integrationen löst .

Detaillierte Erklärung:

Ohne MCP muss jede KI-Anwendung (Claude, ChatGPT, Cursor usw.) für jede Datenquelle (GitHub, Slack, Datenbanken usw.) eine eigene Integration bauen. Bei M Anwendungen und N Datenquellen entstehen so M x N individuelle Anbindungen – ein enormer Aufwand, der schlecht skaliert .

MCP reduziert dieses Problem auf M + N: Jede KI-Anwendung implementiert einmal den MCP-Client, jede Datenquelle einmal den MCP-Server. Danach können alle Clients mit allen Servern kommunizieren .

Konkrete Anwendungsbeispiele aus der MCP-Dokumentation: Google Calendar und Notion mit einer KI verbinden, Figma-Designs direkt in Web-Applikationen umwandeln, Unternehmens-Datenbanken über natürliche Sprache abfragen oder 3D-Designs in Blender per KI erstellen .

1.2. Wie unterscheidet sich MCP von klassischen API-Integrationen?  

Kurze Antwort: Klassische APIs sind statisch und aufgabenspezifisch; MCP bietet dynamische Discovery, standardisierte Capability-Negotiation und zustandsbehaftete Sessions in einem einheitlichen Protokoll .

Detaillierte Erklärung:

Ein entscheidender Vorteil ist die dynamische Tool-Discovery: Ein MCP-Server kann zur Laufzeit seine verfügbaren Tools ändern und den Client per notifications/tools/list_changed informieren. Der Client fragt dann erneut tools/list ab und kennt die neuen Fähigkeiten – ohne Neustart oder manuellen Eingriff .

Zusätzlich verhandeln Client und Server beim Verbindungsaufbau ihre Capabilities: Welche Primitives werden unterstützt? Welche Protokollversion? Dieses Handshake-Verfahren macht MCP-Verbindungen robuster und zukunftssicherer als starre API-Verträge .

1.3. Wer hat MCP entwickelt und wer unterstützt es?  

Kurze Antwort: Anthropic hat MCP entwickelt und als offenen Standard veröffentlicht. Das Protokoll wird mittlerweile von Microsoft (VS Code, GitHub Copilot), Google (Gemini CLI), Block, Amazon und zahlreichen Tool-Herstellern unterstützt; bei OpenAI/ChatGPT ist der MCP-Umfang aktuell plan-, modus- und einsatzabhängig .

Detaillierte Erklärung:

Anthropic veröffentlichte MCP als offenen Standard mit dem Ziel, fragmentierte KI-Integrationen durch ein einheitliches Protokoll zu ersetzen . Die frühe Adoption verlief bemerkenswert schnell:

Block CTO Dhanji R. Prasanna fasst die Bedeutung zusammen: "Open technologies like the Model Context Protocol are the bridges that connect AI to real-world applications" .

Die gesamte Spezifikation, alle SDKs und die Referenz-Server stehen auf github.com/modelcontextprotocol unter offener Lizenz . Die Community kann direkt zur Weiterentwicklung beitragen.

1.4. Was bedeutet die "USB-C für KI"-Analogie?  

Kurze Antwort: So wie USB-C einen universellen Anschluss für Geräte bietet, schafft MCP einen universellen Standard für KI-Integrationen – ein Protokoll statt vieler proprietärer Adapter .

Detaillierte Erklärung:

Die offizielle MCP-Einführung beschreibt es so: "Think of MCP like a USB-C port for AI applications" . Die Analogie funktioniert auf mehreren Ebenen:

Der Vergleich verdeutlicht den Kernvorteil: Statt für jede Kombination aus KI-Anwendung und Datenquelle eine maßgeschneiderte Integration zu bauen, implementieren beide Seiten einmalig den MCP-Standard. Das Ergebnis ist universelle Kompatibilität – jeder MCP-Client kann mit jedem MCP-Server arbeiten, so wie jedes USB-C-Gerät mit jedem USB-C-Kabel funktioniert.

1.5. Wie ist die Beziehung zwischen MCP und dem Language Server Protocol?  

Kurze Antwort: MCP ist vom Language Server Protocol (LSP) inspiriert und überträgt dessen Prinzip – standardisierte Kommunikation zwischen Hosts und Capability-Servern – auf den Bereich der KI-Integrationen .

Detaillierte Erklärung:

LSP löste ein ähnliches M-mal-N-Problem in der IDE-Welt: Statt für jede Kombination aus Editor und Programmiersprache einen eigenen Language-Service zu schreiben, definierte LSP ein einheitliches Protokoll. Das Ergebnis: Ein Language Server für Python funktioniert in VS Code, Neovim und jedem anderen LSP-kompatiblen Editor.

MCP überträgt genau dieses Prinzip auf KI-Anwendungen :

Beide Protokolle basieren auf JSON-RPC und folgen dem Prinzip der Capability-Negotiation: Server und Client verhandeln beim Verbindungsaufbau, welche Features sie unterstützen. Die Architektur-Entscheidung, auf LSP aufzubauen, ermöglicht es Entwickler:innen mit LSP-Erfahrung, schnell in die MCP-Welt einzusteigen.

2.1. Wie ist die MCP-Architektur aufgebaut (Hosts, Clients, Servers)?  

Kurze Antwort: MCP folgt einer dreischichtigen Architektur: Der Host (z.B. Claude Desktop) verwaltet mehrere Clients, die jeweils eine 1:1-Verbindung zu einem Server unterhalten .

Detaillierte Erklärung:

Die drei Schichten haben klar definierte Rollen :

Ein konkretes Beispiel aus der MCP-Dokumentation: VS Code fungiert als Host und erzeugt intern einen MCP Client für die Sentry-Anbindung und einen weiteren für den Dateisystem-Zugriff. Jeder Client verhandelt unabhängig seine Capabilities mit dem jeweiligen Server .

Unterhalb der Architektur-Schichten arbeiten zwei Ebenen: die Datenschicht (JSON-RPC 2.0 als Nachrichtenformat) und die Transportschicht (stdio oder Streamable HTTP als Übertragungskanal) .

2.2. Was sind die drei Server-Primitives (Tools, Resources, Prompts)?  

Kurze Antwort: MCP-Server exponieren drei Arten von Capabilities: Tools (modellgesteuerte Aktionen), Resources (anwendungsgesteuerte Daten) und Prompts (nutzer:innengesteuerte Interaktions-Templates) .

Detaillierte Erklärung:

Der entscheidende Unterschied liegt in der Steuerungsebene – wer entscheidet, wann ein Primitive genutzt wird :

Tools sind das am häufigsten genutzte Primitive: Das LLM entscheidet basierend auf dem Kontext, welches Tool aufgerufen wird. Tools können Seiteneffekte haben (z.B. E-Mails senden, Dateien schreiben) und liefern strukturierte Ergebnisse zurück .

Resources sind dagegen rein datenliefernd: Die Anwendung entscheidet, welche Resources als Kontext eingebunden werden. Sie funktionieren ähnlich wie GET-Endpoints in REST – schreibgeschützt und adressiert über URIs wie trips://history/ .

Prompts werden explizit von Nutzer:innen aufgerufen, z.B. als Slash-Commands. Ein plan-vacation-Prompt könnte strukturierte Argumente wie Zielort und Reisedaten erwarten und daraus eine mehrteilige Konversation erzeugen .

2.3. Was sind Client-Primitives (Sampling, Elicitation, Roots)?  

Kurze Antwort: Client-Primitives sind Rückkanal-Capabilities, die der Server beim Client anfordern kann: Sampling (LLM-Completions), Elicitation (strukturierter Nutzer:innen-Input) und Roots (Dateisystem-Grenzen) .

Detaillierte Erklärung:

Während Server-Primitives Daten und Funktionen an den Client liefern, ermöglichen Client-Primitives den umgekehrten Weg – der Server kann Anfragen an den Client stellen :

Sampling ist besonders mächtig: Es ermöglicht agentische Verhaltensweisen innerhalb von MCP-Server-Features. Der Server kann das LLM "um Rat fragen", ohne einen eigenen API-Key zu benötigen – die Anfrage läuft über den Client, der den Zugang zum Modell kontrolliert .

Elicitation ist ein neueres Primitive, das in der aktuellen Spezifikation eingeführt wurde. Es ist bewusst auf flache Objekte mit primitiven Eigenschaften (String, Number, Boolean, Enum) beschränkt .

Roots geben dem Server Orientierung über den Arbeitskontext – z.B. file:///home/user/project/. Sie sind bewusst advisory und werden nicht technisch erzwungen, um Flexibilität zu bewahren .

2.4. Wie funktioniert der Protokoll-Lifecycle?  

Kurze Antwort: Der MCP-Lifecycle besteht aus drei Phasen: Initialisierung (Capability-Negotiation), Operation (bidirektionaler Nachrichtenaustausch) und Shutdown (sauberes Beenden der Verbindung) .

Detaillierte Erklärung:

Beim Verbindungsaufbau verhandeln Client und Server ihre Fähigkeiten in einem standardisierten Handshake :

// 1. Client sendet initialize-Request
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
  "protocolVersion": "2025-11-25",
  "capabilities": {
    "roots": { "listChanged": true },
    "sampling": {}
  },
  "clientInfo": {
    "name": "ExampleClient",
    "version": "1.0.0"
  }

Nach der Initialisierung können Client und Server bidirektional Nachrichten austauschen: Der Client kann Tools aufrufen und Resources abfragen; der Server kann Sampling-Requests und Elicitation-Anfragen senden. Notifications (ohne Response) ermöglichen ereignisbasierte Updates .

2.5. Welche Rolle spielt JSON-RPC 2.0 in MCP?  

Kurze Antwort: JSON-RPC 2.0 bildet die Nachrichtenschicht von MCP: Alle Kommunikation – Requests, Responses und Notifications – wird als standardisierte JSON-RPC-Nachrichten kodiert .

Detaillierte Erklärung:

MCP nutzt drei JSON-RPC-Nachrichtentypen :

Die Wahl von JSON-RPC 2.0 bringt mehrere Vorteile: Das Format ist sprachunabhängig, gut dokumentiert und leichtgewichtig. Es unterstützt sowohl synchrone Request-Response-Muster als auch asynchrone Notifications. Zwei Fehlertypen sind definiert: Protokoll-Fehler (als JSON-RPC Error-Objekte) und Tool-Ausführungsfehler (als Ergebnis mit isError: true) .

Die Protokollversion wird beim Handshake als protocolVersion-Feld ausgetauscht. Die aktuelle Version lautet "2025-11-25" . Zusätzlich wird bei Streamable-HTTP-Verbindungen ein MCP-Protocol-Version-Header mitgesendet .

3.1. Welche Transport-Mechanismen unterstützt MCP?  

Kurze Antwort: MCP definiert zwei offizielle Transports: stdio für lokale Subprozesse und Streamable HTTP für Remote-Server. Beide transportieren die gleichen JSON-RPC-Nachrichten .

Detaillierte Erklärung:

stdio ist der einfachere Transport: Der Client startet den Server als Kindprozess und kommuniziert über die Standard-Streams. Jede JSON-RPC-Nachricht wird als eigene Zeile gesendet. stderr wird für Logging verwendet und darf keine Protokoll-Nachrichten enthalten .

Streamable HTTP ersetzt den früheren HTTP+SSE-Transport. Der Client sendet JSON-RPC-Nachrichten als HTTP POST an den Server-Endpoint. Der Server kann entweder direkt mit JSON antworten oder einen SSE-Stream öffnen, über den mehrere Nachrichten gestreamt werden .

3.2. Was ist der Unterschied zwischen stdio und Streamable HTTP?  

Kurze Antwort: stdio kommuniziert über die Standard-Streams eines Kindprozesses (einfach, lokal); Streamable HTTP nutzt HTTP POST mit optionalem SSE-Streaming (flexibel, remote-fähig, mit Session-Management) .

Detaillierte Erklärung:

Bei stdio startet der Client den Server als Subprozess. Die Kommunikation verläuft wie folgt :

Bei Streamable HTTP arbeitet der Server als HTTP-Endpoint :

3.3. Wie funktioniert Session Management bei Streamable HTTP?  

Kurze Antwort: Nach der Initialisierung vergibt der Server eine Mcp-Session-Id, die der Client in jedem nachfolgenden Request als HTTP-Header mitsendet. Der Server kann ungültige oder fehlende Session-IDs ablehnen .

Detaillierte Erklärung:

Das Session-Management bei Streamable HTTP verläuft in definierten Schritten :

Dieser Mechanismus ermöglicht zustandsbehaftete Verbindungen über das zustandslose HTTP-Protokoll. Der Server kann Session-spezifische Daten verwalten (z.B. aktive Subscriptions, Nutzer:innen-Kontext) und bei Bedarf Sessions beenden .

3.4. Was ist Resumability und wie wird Message-Verlust verhindert?  

Kurze Antwort: Resumability nutzt SSE-Event-IDs und den Last-Event-ID-Header, um bei Verbindungsabbrüchen nahtlos dort fortzufahren, wo die Kommunikation unterbrochen wurde .

Detaillierte Erklärung:

Bei Streamable HTTP können Verbindungen jederzeit abbrechen – Netzwerkprobleme, Timeouts oder Server-Neustarts. Resumability verhindert, dass dabei Nachrichten verloren gehen :

Dieses Muster ist besonders relevant für lang laufende Operationen wie große Dateiexporte oder komplexe Tool-Ausführungen. Ohne Resumability müsste der Client die gesamte Operation bei jedem Verbindungsabbruch von vorne starten. Mit Event-IDs wird stattdessen nur der fehlende Teil nachgeliefert .

4.1. Wie funktionieren MCP Tools – von der Discovery bis zur Ausführung?  

Kurze Antwort: Tools durchlaufen einen vierstufigen Lifecycle: Discovery (tools/list), Auswahl durch das LLM, Ausführung (tools/call) und dynamische Aktualisierung via Notifications .

Detaillierte Erklärung:

Jedes Tool wird über eine strukturierte Definition beschrieben :

Tool-Ergebnisse können verschiedene Inhaltstypen zurückliefern: Text, Bilder, Audio, Resource-Links und eingebettete Ressourcen . Bei Fehlern unterscheidet MCP zwischen Protokoll-Fehlern (JSON-RPC Error) und Tool-Ausführungsfehlern (Ergebnis mit isError: true), was eine differenzierte Fehlerbehandlung ermöglicht.

4.2. Was sind MCP Resources und wie unterscheiden sie sich von Tools?  

Kurze Antwort: Resources sind URI-identifizierte, schreibgeschützte Datenquellen, die Kontext liefern, während Tools Aktionen ausführen .

Detaillierte Erklärung:

Resources repräsentieren Daten, die eine KI-Anwendung als Kontext einbinden kann – ähnlich wie GET-Endpoints in REST . Es gibt zwei Arten:

Resources unterstützen verschiedene URI-Schemes: https://, file://, git:// und benutzerdefinierte Schemes wie calendar://events/2024 oder trips://history/ . Die Inhalte können Text oder binär (Base64-kodiert) sein.

Der fundamentale Unterschied zu Tools: Resources haben keine Seiteneffekte. Sie liefern Daten, verändern aber nichts. Sie dienen damit als Kontextschnittstelle, während Tools auf Ausführung und Aktionen ausgerichtet sind .

Zusätzlich unterstützen Resources Subscriptions: Der Client kann sich für Änderungsbenachrichtigungen registrieren und wird per Notification informiert, wenn sich eine Resource ändert. Annotations wie audience, priority und lastModified liefern Metadaten zur Priorisierung .

4.3. Wie funktionieren MCP Prompts und wofür setzt man sie ein?  

Kurze Antwort: Prompts sind nutzer:innengesteuerte Interaktions-Templates, die über prompts/list entdeckt und über prompts/get mit Argumenten aufgerufen werden – typischerweise als Slash-Commands in der UI exponiert .

Detaillierte Erklärung:

MCP Prompts unterscheiden sich grundlegend von Tools und Resources durch ihre Steuerungsebene: Sie werden explizit von Nutzer:innen ausgelöst, nicht vom LLM oder der Anwendung .

Ein Prompt besteht aus :

Ein praktisches Beispiel: Ein plan-vacation-Prompt könnte Argumente wie destination und dates erwarten. Beim Aufruf generiert der Server daraus eine mehrteilige Konversation, die das LLM als Ausgangspunkt für die Urlaubsplanung nutzt – inklusive eingebetteter Resources wie trips://history/ für vergangene Reisen .

Prompts unterstützen auch Multi-Turn-Konversationen: Der Server kann mehrere aufeinanderfolgende Messages mit abwechselnden Rollen zurückgeben, um komplexe Interaktionsmuster vorzustrukturieren .

4.4. Was ist Sampling und wie kann ein Server LLM-Completions anfordern?  

Kurze Antwort: Sampling ermöglicht es einem MCP-Server, über den Client eine LLM-Completion anzufordern – ohne eigene API-Keys zu benötigen. Nutzer:innen behalten durch Human-in-the-Loop die volle Kontrolle .

Detaillierte Erklärung:

Sampling löst ein praktisches Problem: MCP-Server benötigen manchmal die Unterstützung eines LLM, um ihre Aufgaben zu erfüllen – z.B. um unstrukturierte Daten zu analysieren oder Entscheidungen zu treffen. Ohne Sampling müsste der Server eigene API-Keys verwalten. Mit Sampling nutzt er den Zugang des Clients .

Der Server kann beim Sampling Modell-Präferenzen angeben :

Der Human-in-the-Loop ist doppelt: Nutzer:innen können sowohl den Request des Servers prüfen und modifizieren als auch die LLM-Antwort vor der Rückgabe an den Server einsehen und freigeben. Der Client hat das letzte Wort – er kann die Modellauswahl überschreiben, Anfragen kürzen oder ganz ablehnen .

4.5. Was ist Elicitation und wie fordert ein Server Nutzer:innen-Input an?  

Kurze Antwort: Elicitation ist ein neueres MCP-Primitive, das es Servern ermöglicht, strukturierte Daten direkt von Nutzer:innen abzufragen – mit JSON-Schema-Validierung und drei Antwort-Aktionen: accept, decline oder cancel .

Detaillierte Erklärung:

Elicitation löst das Problem, dass Server manchmal Informationen benötigen, die weder aus dem LLM-Kontext noch aus vorhandenen Daten abgeleitet werden können. Beispiel: Ein Deployment-Server benötigt die Bestätigung einer Umgebung, bevor er fortfährt .

Der Ablauf :

Das JSON Schema ist bewusst eingeschränkt: Nur flache Objekte mit primitiven Eigenschaften (String, Number, Boolean, Enum) sind erlaubt – keine verschachtelten Objekte oder Arrays .

5.1. Welche KI-Anwendungen unterstützen MCP als Client?  

Kurze Antwort: MCP wird von einem breiten Spektrum an KI-Anwendungen unterstützt, darunter Claude Desktop, Claude Code, Claude.ai, VS Code (via GitHub Copilot), Cursor, Gemini CLI, Amazon Q und zahlreiche weitere. ChatGPT bietet ebenfalls MCP-Unterstützung, deren Umfang laut OpenAI derzeit jedoch plan-, modus- und einsatzabhängig ist .

Detaillierte Erklärung:

Die Client-Unterstützung variiert je nach implementierten Features. Die MCP-Dokumentation trackt folgende Capabilities pro Client; für ChatGPT sollte zusätzlich die aktuelle OpenAI-Dokumentation beachtet werden, da Verfügbarkeit und Berechtigungen derzeit plan- und modusabhängig sind :

Darüber hinaus unterstützen zahlreiche weitere Anwendungen MCP: Cline, Continue, Goose, fast-agent, OpenAI Codex, 5ire, AgenticFlow, BoltAI, Chatbox und viele mehr .

Für ChatGPT gilt aktuell ein Sonderfall: Laut OpenAI ist volles MCP mit Schreib-/Änderungsaktionen derzeit im Beta-Rollout für Business, Enterprise und Edu; Pro unterstützt derzeit MCP in Developer Mode mit Read/Fetch-Berechtigungen .

VS Code bietet besonders umfangreiche MCP-Integration: Konfiguration über .vscode/mcp.json, Sandbox-Support auf macOS/Linux, Auto-Discovery aus Claude-Desktop-Konfigurationen und CLI-Installation via code --add-mcp .

5.2. Welche SDKs gibt es und in welchen Sprachen?  

Kurze Antwort: Offizielle SDKs existieren in drei Tiers: Tier 1 (TypeScript, Python, C#, Go), Tier 2 (Java, Rust) und Tier 3 (Swift, Ruby, PHP). Kotlin ist in Planung .

Detaillierte Erklärung:

Alle SDKs werden unter github.com/modelcontextprotocol gepflegt :

Die Tier-Einteilung spiegelt den Reifegrad und die Wartungsintensität wider: Tier 1 SDKs erhalten die schnellsten Updates bei neuen Spec-Versionen, Tier 2 folgt zeitnah, Tier 3 mit etwas Verzögerung .

5.3. Welche Reference-Server stellt das offizielle Repository bereit?  

Kurze Antwort: Das offizielle Repository enthält 7 aktive Referenz-Server (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time) und über 12 archivierte Server, die als Lernressourcen dienen .

Detaillierte Erklärung:

Die aktiven Referenz-Server auf github.com/modelcontextprotocol/servers :

Zusätzlich existieren über 12 archivierte Server im servers-archived-Repository, darunter AWS KB Retrieval, Brave Search, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack und SQLite . Diese wurden als eigenständige Projekte weitergeführt und dienen als Referenz-Implementierungen für unterschiedliche Integrations-Patterns.

5.4. Wie baut man einen eigenen MCP-Server?  

Kurze Antwort: Mit einem offiziellen SDK wählen, Tools, Resources und/oder Prompts definieren, den gewünschten Transport konfigurieren und den Server registrieren. Ein minimaler Server ist in unter 100 Zeilen Code möglich .

Detaillierte Erklärung:

Der Aufbau eines MCP-Servers folgt einem einheitlichen Pattern, unabhängig von der Sprache :

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
name: "weather-server",
version: "1.0.0",
});

// Tool definieren
server.tool(
"get-weather",
"Aktuelles Wetter für eine Stadt abrufen",
{ city: z.string().describe("Name der Stadt") },
async ({ city }) => ({

Die offizielle Clients-Seite dokumentiert, welche Clients welche Features unterstützen – testen Sie Ihren Server gezielt mit Clients, die die von Ihnen implementierten Primitives unterstützen .

6.1. Welche Sicherheitsprinzipien definiert MCP?  

Kurze Antwort: MCP definiert vier Kernprinzipien: User Consent and Control, Data Privacy, Tool Safety und LLM Sampling Controls .

Detaillierte Erklärung:

Die Sicherheitsarchitektur von MCP basiert auf dem Grundsatz, dass Nutzer:innen die finale Kontrollinstanz bleiben :

Diese Prinzipien sind normativ – Implementierungen müssen sie einhalten, um MCP-konform zu sein. Der Host (die KI-Anwendung) trägt die Hauptverantwortung: Er muss Sicherheitsrichtlinien durchsetzen, User Consent einholen und die Isolation zwischen verschiedenen MCP-Servern gewährleisten .

6.2. Wie werden Tool-Aufrufe abgesichert (Human-in-the-Loop)?  

Kurze Antwort: Hosts müssen Tool-Aufrufe vor der Ausführung durch Nutzer:innen bestätigen lassen. Das LLM schlägt einen Tool-Aufruf vor; der Host zeigt ihn an; die Nutzer:in genehmigt, modifiziert oder lehnt ab .

Detaillierte Erklärung:

Das Human-in-the-Loop-Modell in MCP arbeitet auf mehreren Ebenen :

Tool-Annotations unterstützen diesen Prozess: readOnlyHint signalisiert, dass ein Tool keine Daten verändert; destructiveHint warnt vor potenziell zerstörerischen Operationen. Hosts können diese Annotations nutzen, um automatische Genehmigungen für sichere Tools zu implementieren und bei riskanten Tools extra Bestätigung einzufordern .

6.3. Welche Risiken bestehen bei MCP und wie minimiert man sie?  

Kurze Antwort: Die Hauptrisiken sind Prompt Injection (bösartige Inhalte in Tool-Ergebnissen), übermäßige Berechtigungen und fehlende Input-Validierung. Gegenmaßnahmen: strikte Validierung, Principle of Least Privilege und Server-Isolation .

Detaillierte Erklärung:

Die Spezifikation empfiehlt eine Defense-in-Depth-Strategie :

6.4. Wie behandelt MCP Datenschutz und User Consent?  

Kurze Antwort: MCP verlangt explizite Zustimmung vor jeder Datenfreigabe, folgt dem Principle of Least Privilege und gibt Hosts die Pflicht, den Datenfluss zwischen LLM und Servern zu kontrollieren .

Detaillierte Erklärung:

Das Datenschutz-Modell von MCP definiert klare Verantwortlichkeiten :

Für Sampling gilt ein besonders strenges Consent-Modell: Der Mensch sieht sowohl die Anfrage des Servers als auch die LLM-Antwort und kann beides modifizieren oder ablehnen. Damit wird verhindert, dass ein Server unkontrolliert LLM-Kapazitäten nutzt oder das LLM mit manipulativen Prompts füttert .

Das Prinzip der minimalen Exposition bedeutet: Nur die Daten, die ein Server für seine Funktion benötigt, werden ihm zugänglich gemacht. Hosts sollten nicht pauschal alle Resources aller Server sichtbar machen, sondern gezielt kontrollieren, welcher Server welche Kontextdaten erhält .

7.1. Was sind die wichtigsten Dos und Don'ts beim MCP-Einsatz?  

Kurze Antwort: Die wichtigsten Grundsätze: Fokussierte Server statt Monolithen, strikte Input-Validierung, aussagekräftige Tool-Beschreibungen und konsequente Human-in-the-Loop-Kontrolle .

Detaillierte Erklärung:

7.2. Wie sieht die Zukunft von MCP aus?  

Kurze Antwort: MCP entwickelt sich aktiv weiter mit neuen Spec-Versionen, wachsendem Ökosystem und zunehmender Industrie-Adoption. Neue Features wie Elicitation und Tasks (experimentell) erweitern die Möglichkeiten .

Detaillierte Erklärung:

Mehrere Entwicklungen deuten auf eine starke Zukunft von MCP hin:

Besonders bemerkenswert ist die Dynamik des Ökosystems: Die MCP-Architektur-Dokumentation listet bereits experimentelle Features wie Tasks (für lang laufende Operationen), Notifications und Progress-Tracking . Die offene Spezifikation auf GitHub ermöglicht es der Community, direkt zur Weiterentwicklung beizutragen .

7.3. Wie konfiguriere ich MCP in VS Code, Cursor oder Claude Desktop?  

Kurze Antwort: Jede Host-Anwendung bietet einen eigenen Konfigurationsweg – VS Code nutzt eine .vscode/mcp.json-Datei, Cursor konfiguriert über die Settings, und Claude Desktop verwendet eine lokale JSON-Konfiguration .

Detaillierte Erklärung:

Die drei populärsten MCP-Hosts unterscheiden sich in der Konfiguration:

{
"servers": {
  "filesystem": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/pfad/zum/projekt"]
  },
  "github": {
    "type": "http",
    "url": "https://api.githubcopilot.com/mcp"
  }
}
}

Zusammenfassung  

Quellen