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

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

KI-Programme wie Claude, ChatGPT oder Cursor brauchen fremde Daten. Sie brauchen auch Werkzeuge und Schnittstellen. Fachleute nennen Schnittstellen auch APIs. Nur so sind diese Programme wirklich nützlich.

Bisher brauchte jede Verbindung eine eigene Lösung. Fachleute nennen das M-mal-N-Problem. Entwickler programmierten jede Verbindung einzeln. Das kostete viel Zeit.

Das Model Context Protocol (MCP) löst dieses Problem . Es ist ein offener Standard. Dieser Standard verbindet KI-Programme mit fremden Systemen. Alle nutzen dabei die gleichen Regeln.

Die Firma Anthropic hat MCP Ende 2024 veröffentlicht. Sie nennt es "USB-C für KI-Programme" .

Entwickler bauen nicht mehr für jede Datenquelle einen Adapter. MCP ist ein allgemeines Protokoll. Ein Protokoll ist eine feste Regel für den Datenaustausch. Damit sprechen alle KI-Programme mit allen Servern.

Das Protokoll nutzt die Technik JSON-RPC 2.0. Das Protokoll merkt sich den Zustand der Verbindung. Viele Programme unterstützen MCP schon.

Dazu gehören zum Beispiel:

• Claude
• VS Code
• Cursor
• Gemini CLI
• Amazon Q

Bei ChatGPT hängt die Nutzung von verschiedenen Dingen ab . Das liegt am jeweiligen Plan oder Modus.

Vielleicht nutzen Sie MCP zum ersten Mal. Vielleicht wollen Sie Ihr bestehendes System verbessern. Hier finden Sie 30 gute Antworten. Wir erklären Ihnen die Grundlagen und den Aufbau. Wir sprechen auch über Sicherheit und die besten Arbeitsweisen.

MCP im Einsatz: Eine Vorschau zum Mitmachen  

Sehen Sie sich die drei wichtigsten Teile von MCP an. Wir zeigen Ihnen den Aufbau Schritt für Schritt. Sie sehen den Ablauf von JSON-RPC. Sie sehen auch den Aufruf von Werkzeugen:

JSON-RPC-Nachricht erscheint nach Start...

Antwort erscheint nach Simulation...

Inhaltsverzeichnis  

Schnelle Übersicht: Alle 30 Fragen  

Klicken Sie auf eine Frage. Dann kommen Sie direkt zur Antwort.

Teil 1: Grundlagen und wichtige Begriffe  

Kategorie 2: Architektur und Bestandteile  

Kategorie 3: Transport und Verbindungen  

Kategorie 4: Server-Funktionen im Detail  

Kategorie 5: Ökosystem und Clients  

Kategorie 6: Sicherheit und beste Vorgehensweisen  

Kategorie 7: Anwendung, Regeln und Tipps  

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

Kurze Antwort:

MCP ist ein offener Standard. Ein offener Standard ist eine offene Regel für alle. Die Firma Anthropic hat MCP gemacht. MCP verbindet KI-Programme mit anderen Daten und Werkzeugen. Dazu gehören auch Schnittstellen für Programme (APIs). Damit löst MCP ein großes Problem. Das Problem heißt M-mal-N-Problem. Vorher brauchte man zu viele verschiedene Verbindungen.

Genaue Erklärung:

Ohne MCP ist die Arbeit sehr schwer. Jedes KI-Programm braucht eine eigene Verbindung. Zum Beispiel Programme wie Claude, ChatGPT oder Cursor. Sie brauchen Verbindungen für jede Datenquelle. Datenquellen sind zum Beispiel GitHub, Slack oder Datenbanken. Das bedeutet sehr viele einzelne Verbindungen. Man nennt das M mal N Verbindungen. Das macht enorm viel Arbeit. Es funktioniert nicht gut bei vielen Programmen.

MCP macht dieses Problem viel kleiner. Aus M mal N wird M plus N. Das bedeutet: Jedes KI-Programm baut nur einen MCP-Client ein. Jede Datenquelle baut nur einen MCP-Server ein. Danach ist alles ganz einfach. Alle Clients können mit allen Servern sprechen.

Es gibt gute Beispiele für den Einsatz von MCP: Sie können Ihren Kalender mit einer KI verbinden. Sie können Bilder aus dem Programm Figma in Internetseiten verwandeln. Sie können Fragen an die Datenbank von Ihrer Firma stellen. Das machen Sie einfach mit normalen Worten. Sie können mit einer KI auch 3D-Bilder im Programm Blender bauen.

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

Kurze Antwort: Normale APIs sind fest und für eine bestimmte Aufgabe. MCP ist sehr flexibel. MCP findet neue Funktionen automatisch. Das nennt man dynamische Discovery. MCP und das Programm einigen sich automatisch. Sie nutzen dafür einen gemeinsamen Standard. Sie merken sich auch den Stand der Arbeit.

Genaue Erklärung:

Ein großer Vorteil ist das automatische Finden von Werkzeugen. Das nennt man dynamische Tool-Discovery. Ein MCP-Server kann seine Werkzeuge im laufenden Betrieb ändern. Er informiert dann das verbundene Programm. Das passiert über den Befehl notifications/tools/list_changed. Das Programm fragt dann mit tools/list noch einmal nach. Es kennt danach die neuen Fähigkeiten. Ein Neustart ist nicht nötig. Kein Mensch muss etwas von Hand tun.

Das Programm und der Server sprechen beim Start miteinander. Sie verhandeln dabei ihre Fähigkeiten. Das nennt man auf Englisch Capabilities. Sie klären: Welche Befehle sind möglich? Welche Version vom Protokoll nutzen wir? Dieses Abstimmen nennt man Handshake. Das macht die Verbindung von MCP sehr stabil. Es ist besser für die Zukunft als feste API-Regeln.

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

Kurze Antwort: Die Firma Anthropic hat MCP entwickelt. Anthropic hat MCP als offenen Standard veröffentlicht. Das bedeutet: Jeder darf es frei nutzen.

Viele große Firmen unterstützen MCP. Dazu gehören Microsoft, Google, Block und Amazon. Microsoft nutzt es für VS Code und GitHub Copilot. Google nutzt es für Gemini CLI. Auch OpenAI nutzt MCP für ChatGPT. Aber hier hängt die Nutzung vom genauen Vertrag und Modus ab .

Genaue Erklärung:

Die Firma Anthropic hat ein klares Ziel für MCP. Bisher gab es viele verschiedene Anbindungen für Künstliche Intelligenz. Diese passten oft nicht gut zusammen. MCP ersetzt diese alten Anbindungen. MCP ist nun ein einheitliches Protokoll für alle . Sehr viele Firmen haben MCP sehr schnell genutzt:

Der Technik-Chef der Firma Block heißt Dhanji R. Prasanna. Er erklärt die Bedeutung von MCP so: "Offene Techniken wie MCP sind Brücken. Sie verbinden die Künstliche Intelligenz mit echten Anwendungen" .

Im Internet finden Sie alle genauen Beschreibungen für MCP. Dort gibt es auch Werkzeuge für Programmierer (SDKs). Und es gibt dort Referenz-Server. Das sind fertige Muster für die Server. Die Internetadresse ist github.com/modelcontextprotocol. Die Regeln erlauben die freie Nutzung . Viele Programmierer arbeiten gemeinsam an MCP weiter.

1.4. Was bedeutet der Vergleich: "USB-C für KI"?  

Kurze Antwort:

USB-C ist ein einheitlicher Anschluss für viele Geräte. MCP macht das Gleiche für KI-Programme. MCP schafft einen gemeinsamen Standard für alle . Ein Standard ist eine feste Regel.

Genaue Erklärung:

Die Erfinder von MCP sagen: "Denken Sie an MCP wie an einen USB-C-Anschluss für KI-Programme" . Dieser Vergleich passt aus mehreren Gründen:

Der Vergleich zeigt den größten Vorteil. Früher brauchte man für jedes KI-Programm eine eigene Verbindung. Heute nutzen beide Seiten einfach den MCP-Standard. Ein Standard ist eine gemeinsame Regel. Sie programmieren die Verbindung nur ein einziges Mal.

Das Ergebnis ist eine vollständige Zusammenarbeit. Jeder MCP-Client funktioniert mit jedem MCP-Server. Es ist genau wie bei USB-C. Jedes Gerät mit USB-C funktioniert mit jedem USB-C-Kabel.

1.5. Wie hängen MCP und das Language Server Protocol zusammen?  

Kurze Antwort: Das Language Server Protocol (LSP) ist das Vorbild für MCP. Das LSP verbindet Programme nach festen Regeln. MCP nutzt diese Regeln nun für KI-Integrationen .

Genaue Erklärung:

Das LSP löste ein Problem bei Schreibprogrammen für Code. Diese Programme heißen auch Editoren. Früher brauchte jede Programmiersprache eine eigene Verbindung zum Editor. Das LSP brachte eine feste und einheitliche Regel dafür. Das Ergebnis: Ein Programm für Python funktioniert jetzt überall. Es klappt in VS Code und in jedem anderen passenden Editor.

MCP macht das jetzt genauso für KI-Anwendungen :

Beide Protokolle nutzen die Technik JSON-RPC. Beide nutzen auch die sogenannte Capability-Negotiation. Das bedeutet: Server und Client sprechen sich ab. Sie klären beim Start ihre gemeinsamen Fähigkeiten. Die Macher haben sich bewusst für diese Ähnlichkeit entschieden. So lernen Entwickler die MCP-Welt sehr schnell kennen.

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

Kurze Antwort: MCP hat einen Aufbau aus 3 Schichten. Der Host verwaltet mehrere Clients. Ein Host ist zum Beispiel Claude Desktop. Jeder Client verbindet sich direkt mit genau einem Server .

Genaue Erklärung:

Die 3 Schichten haben ganz klare Aufgaben :

Hier ist ein Beispiel aus der Anleitung. VS Code arbeitet als Host. VS Code erstellt einen eigenen MCP Client für Sentry. VS Code erstellt einen zweiten Client für das Dateisystem. Jeder Client spricht alleine mit seinem Server. Die beiden stimmen ihre Funktionen miteinander ab .

Unter diesen 3 Schichten gibt es 2 weitere Ebenen . Das ist einmal die Datenschicht. Sie bestimmt das Format der Nachrichten. Das Format heißt JSON-RPC 2.0. Die zweite Ebene ist die Transportschicht. Sie bestimmt den Weg der Übertragung. Dafür nutzt sie stdio oder Streamable HTTP.

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

Kurze Antwort: Ein MCP-Server hat drei verschiedene Funktionen . Das sind Tools, Resources und Prompts. Ein Modell steuert die Tools. Ein Programm steuert die Resources. Die Nutzer und Nutzerinnen steuern die Prompts.

Genaue Erklärung:

Der wichtigste Unterschied ist die Steuerung . Wer entscheidet über den Einsatz von einer Funktion?

Tools sind die wichtigsten Funktionen. Das Sprachmodell (LLM) entscheidet über den Einsatz. Das LLM wählt das passende Tool aus. Tools führen echte Aktionen aus. Sie senden zum Beispiel E-Mails. Sie können auch Dateien schreiben. Danach liefern sie klare Ergebnisse zurück .

Resources liefern nur Daten. Das Programm wählt die passenden Resources aus. Das Programm nutzt diese Daten als Hintergrundwissen. Man kann diese Daten nur lesen. Man kann sie nicht verändern. Sie haben eine eigene Adresse im System. Diese Adresse nennt man URI. Ein Beispiel für eine Adresse ist trips://history/ .

Die Nutzer und Nutzerinnen rufen Prompts direkt auf. Das geht zum Beispiel über einen direkten Befehl. Ein Prompt heißt zum Beispiel plan-vacation. Dieser Prompt fragt nach genauen Reisedaten. Er braucht das Reiseziel und das Datum. Daraus entsteht dann ein längeres Gespräch mit der KI .

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

Kurze Antwort: Client-Primitives sind besondere Funktionen. Der Server fragt damit etwas vom Client ab. Es gibt drei wichtige Funktionen. Diese heißen Sampling, Elicitation und Roots.

Genaue Erklärung:

Server-Primitives senden Daten an den Client. Client-Primitives machen genau das Gegenteil. Der Server stellt eine Anfrage an den Client :

Sampling ist eine sehr starke Funktion. Der Server kann damit selbstständig handeln. Der Server stellt eine Frage an das Sprachmodell. Er braucht dafür keinen eigenen API-Key. Die Anfrage geht immer über den Client. Der Client kontrolliert den Zugang zum Sprachmodell .

Elicitation ist eine neue Funktion. Die Entwickler haben diese Funktion erst kürzlich hinzugefügt. Der Server fragt Sie damit direkt nach Informationen. Diese Informationen müssen sehr einfach sein. Zum Beispiel einfacher Text oder Zahlen .

Roots zeigen dem Server seinen Arbeitsplatz. Der Server sieht damit seine erlaubten Ordner. Zum Beispiel file:///home/user/project/. Diese Vorgabe ist nur eine Empfehlung. Das System erzwingt diese Grenzen nicht technisch. Das gibt Ihnen mehr Freiheit bei der Arbeit .

2.4. Wie funktioniert der Ablauf bei dem Protokoll?  

Kurze Antwort:

Der Ablauf bei MCP hat 3 Phasen. Die erste Phase ist der Start. Beide Seiten prüfen ihre Fähigkeiten. Die zweite Phase ist die Arbeit. Client und Server tauschen Nachrichten aus. Die dritte Phase ist das Ende. Das schließt die Verbindung sicher .

Genaue Erklärung:

Beim Start prüfen Client und Server ihre Fähigkeiten. Sie nutzen dafür einen festen Ablauf. Man nennt diesen Ablauf Handshake :

// 1. Client schickt Anfrage fuer den Start
{
"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 dem Start tauschen Client und Server Nachrichten aus. Das passiert in beide Richtungen. Der Client ruft Tools auf. Er fragt auch Resources ab. Resources sind bestimmte Datenquellen. Der Server schickt auch Anfragen an den Client. Diese Anfragen nennt man Sampling. Es gibt auch schnelle Benachrichtigungen. Diese nennt man Notifications. Notifications brauchen keine direkte Antwort. Sie melden sofort neue Ereignisse .

2.5. Welche Rolle hat JSON-RPC 2.0 bei MCP?  

Kurze Antwort: JSON-RPC 2.0 ist die Schicht für Nachrichten von MCP. MCP verpackt die ganze Kommunikation in standardisierte Nachrichten. Diese Nachrichten haben das Format JSON-RPC .

Genaue Erklärung:

MCP verwendet drei Arten von Nachrichten für JSON-RPC :

Die Wahl von JSON-RPC 2.0 hat viele Vorteile. Das Format funktioniert mit vielen Programmiersprachen. Es ist sehr gut beschrieben und einfach aufgebaut. Es unterstützt direkte Anfragen und Antworten. Es unterstützt auch zeitversetzte Meldungen. Es gibt genau zwei Arten von Fehlern. Erstens: Fehler im Protokoll. Diese Fehler sind eigene Objekte in JSON-RPC. Zweitens: Fehler bei Werkzeugen. Das System zeigt dann den Wert isError: true .

Die Programme tauschen beim Verbindungsaufbau die Version vom Protokoll aus. Sie nutzen dafür das Feld protocolVersion. Die aktuelle Version ist "2025-11-25" . Manche Verbindungen nutzen Streamable HTTP. Dort sendet das System zusätzlich den Header MCP-Protocol-Version mit .

3.1. Welche Arten der Datenübertragung unterstützt MCP?  

Kurze Antwort: Es gibt zwei offizielle Wege für die Daten. Diese Wege nennt man Transports. Der erste Weg heißt stdio. Sie nutzen ihn für lokale Unterprogramme. Der zweite Weg heißt Streamable HTTP. Sie nutzen ihn für externe Server. Beide Wege übertragen die gleichen JSON-RPC-Nachrichten .

Genaue Erklärung:

stdio ist der einfachere Weg. Der Client startet den Server als Unterprogramm. Beide tauschen Daten über normale Datenströme aus. Sie senden jede JSON-RPC-Nachricht in einer eigenen Zeile. Das System nutzt den Kanal stderr für das Aufzeichnen. Diese Aufzeichnungen nennt man auch Logging. Der Kanal stderr darf keine Nachrichten vom Protokoll enthalten .

Streamable HTTP ersetzt den alten Weg HTTP+SSE. Der Client sendet JSON-RPC-Nachrichten über HTTP POST. Er sendet diese an den Endpunkt vom Server. Der Server kann direkt mit JSON antworten. Oder der Server öffnet einen SSE-Stream. Ein Stream ist eine fließende Verbindung. Darüber sendet der Server mehrere Nachrichten nacheinander .

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

Kurze Antwort: stdio nutzt die normalen Kanäle von einem eigenen Programm. Das ist einfach und funktioniert direkt auf Ihrem Computer. Streamable HTTP nutzt das Internet-Protokoll HTTP POST. Es kann Daten auch als durchgehenden Strom senden. Das ist flexibel und funktioniert über das Internet. Es verwaltet auch die Verbindungen .

Genaue Erklärung:

Bei stdio startet der Client den Server als eigenes Programm. Die Kommunikation funktioniert so :

Bei Streamable HTTP arbeitet der Server als HTTP-Endpunkt :

3.3. Wie funktioniert das Session Management bei Streamable HTTP?  

Kurze Antwort: Zuerst startet der Client die Verbindung. Dann erstellt der Server eine Mcp-Session-Id. Das ist eine Nummer für die laufende Sitzung. Der Client schickt diese Nummer bei jeder Anfrage mit. Der Server prüft diese Nummer. Er lehnt Anfragen ohne richtige Nummer ab .

Genaue Erklärung:

Die Verwaltung der Sitzung passiert in festen Schritten :

Normalerweise merkt sich das HTTP-Protokoll keine alten Anfragen. Durch die Session-ID merkt sich der Server die Verbindung. Das nennt man eine zustandsbehaftete Verbindung. Der Server kann sich so Daten für die Sitzung merken. Zum Beispiel laufende Abos oder Daten zur Person. Der Server kann die Sitzung auch jederzeit beenden .

3.4. Was ist Resumability und wie verhindert man den Verlust von Nachrichten?  

Kurze Antwort: Die Wiederaufnahme von Verbindungen heißt Resumability. Sie nutzt SSE-Event-IDs und den Last-Event-ID-Header. So geht die Kommunikation nach einem Abbruch einfach weiter .

Genaue Erklärung:

Bei Streamable HTTP können Verbindungen oft abbrechen. Das passiert bei Netzwerkproblemen, Timeouts oder Neustarts. Die Wiederaufnahme verhindert den Verlust von Nachrichten :

Dieses Vorgehen ist wichtig für lang laufende Aufgaben. Zum Beispiel für große Exporte von Dateien. Oder für die Ausführung von komplexen Werkzeugen. Ohne die Wiederaufnahme startet der Client bei einem Abbruch neu. Mit Event-IDs liefert der Server nur den fehlenden Teil nach .

4.1. Wie funktionieren die MCP Tools?  

Kurze Antwort: Die Tools haben einen Ablauf mit 4 Schritten :

• Finden (Discovery über tools/list)
• Auswählen durch das LLM
• Ausführen (tools/call)
• Aktualisieren durch Benachrichtigungen

Genaue Erklärung:

Der Server beschreibt jedes Tool ganz genau . Das sieht so aus:

Ein Tool liefert ein Ergebnis zurück. Das Ergebnis hat verschiedene Formen . Zum Beispiel Text, Bilder oder Audiodateien. Es gibt auch Links zu anderen Daten. Manchmal passieren Fehler. MCP erkennt 2 Arten von Fehlern. Die erste Art sind Fehler im Protokoll. Das nennt man JSON-RPC Fehler. Die zweite Art sind Fehler im Tool selbst. Dann steht in der Antwort isError: true. So können Sie Fehler genau erkennen. Das hilft bei der Lösung von Problemen.

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

Kurze Antwort: Resources sind Datenquellen mit einer festen Adresse. Diese Adresse heißt URI. Sie können diese Daten nur lesen. Resources liefern wichtige Informationen. Tools machen dagegen echte Handlungen .

Genaue Erklärung:

Resources sind Daten. Eine KI-Anwendung nutzt diese Daten für den Zusammenhang. Das funktioniert ähnlich wie GET-Endpoints bei REST . Das sind bestimmte Datenabfragen bei Programmen. Es gibt 2 Arten von Resources:

Resources nutzen verschiedene Arten von Adressen. Diese Arten heißen URI-Schemes. Beispiele sind https://, file:// und git://. Sie können auch eigene Adressen verwenden. Zum Beispiel calendar://events/2024 oder trips://history/ . Die Inhalte von Resources sind oft Text. Oder die Inhalte sind binär. Binär ist ein Format für Maschinen. Dafür nutzt man eine Base64-Kodierung.

Es gibt einen großen Unterschied zu Tools. Resources verändern keine anderen Dinge. Fachleute sagen: Sie haben keine Seiteneffekte. Resources liefern nur Daten. Sie verändern aber nichts. Resources sind nur eine Schnittstelle für Informationen. Tools führen dagegen echte Handlungen aus .

Resources haben noch eine weitere Funktion. Diese Funktion heißt Subscriptions (Abonnements). Ein Programm kann sich für Nachrichten anmelden. Das Programm bekommt dann automatisch eine Nachricht. Das passiert bei jeder Änderung der Resource. Zusätzlich gibt es sogenannte Annotations. Das ist ein englisches Wort für Anmerkungen. Beispiele sind audience, priority und lastModified. Diese Anmerkungen liefern zusätzliche Daten. Damit kann das System die Wichtigkeit gut bestimmen .

4.3. Wie funktionieren MCP Prompts und wofür nutzen Sie diese?  

Kurze Antwort: Prompts sind Vorlagen für Befehle. Sie steuern diese Vorlagen selbst. Das System findet sie über den Befehl prompts/list. Sie rufen die Prompts über prompts/get auf. Dabei geben Sie bestimmte Werte mit. Sie sehen diese Befehle oft direkt in der Benutzeroberfläche .

Genaue Erklärung:

MCP Prompts sind anders als Tools und Resources. Sie haben eine andere Steuerung. Sie als Mensch starten die Prompts direkt. Das Sprachmodell startet die Prompts nicht. Die Anwendung startet die Prompts auch nicht .

Ein Prompt besteht aus diesen Teilen :

Ein Beispiel aus der Praxis: Es gibt einen Prompt für die Urlaubsplanung. Er heißt plan-vacation. Dieser Prompt braucht bestimmte Werte. Er braucht zum Beispiel das Ziel (destination). Er braucht auch das Datum (dates). Sie rufen diesen Prompt auf. Der Server macht daraus ein längeres Gespräch. Das Sprachmodell nutzt das als Startpunkt. Das Sprachmodell plant damit den Urlaub. Es nutzt dafür auch eingebaute Resources. Ein Beispiel ist trips://history/ für alte Reisen .

Prompts erlauben auch Gespräche in mehreren Schritten. Der Server gibt dabei mehrere Nachrichten nacheinander zurück. Die Rollen wechseln sich dabei ab. Das System bereitet so schwierige Abläufe vor .

4.4. Was ist Sampling? Wie fragt ein Server nach Texten?  

Kurze Antwort:

Ein Server kann durch Sampling Texte von einer KI anfordern. Das nennt man LLM-Completion. Dafür fragt der Server bei dem Client nach. Der Server braucht dafür keine eigenen Passwörter. Diese Passwörter nennt man API-Keys. Sie behalten bei dem Vorgang immer die Kontrolle. Dieses Prinzip nennt man Human-in-the-Loop. Das bedeutet: Ein Mensch prüft alle Schritte.

Genaue Erklärung:

Sampling löst ein wichtiges Problem. Manchmal braucht der Server die Hilfe von einem LLM. Ein LLM ist ein großes Sprachmodell. Der Server muss zum Beispiel Daten prüfen. Oder der Server muss eine Entscheidung treffen. Dafür braucht man oft einen API-Key. Das ist ein Passwort für die KI. Ohne Sampling braucht der Server einen eigenen API-Key. Mit Sampling nutzt der Server den API-Key von dem Client.

Der Server kann beim Sampling Wünsche äußern. Diese Wünsche nennt man Modell-Präferenzen:

Sie haben bei diesem Vorgang die volle Kontrolle. Das nennt man Human-in-the-Loop. Sie prüfen die Anfrage von dem Server. Sie können die Anfrage auch ändern. Danach sehen Sie die Antwort von der KI. Sie geben die Antwort erst frei. Dann bekommt der Server die Antwort. Der Client hat immer das letzte Wort. Der Client kann ein anderes Modell wählen. Er kann Anfragen kürzen. Oder er kann Anfragen komplett ablehnen.

4.5. Was ist Elicitation? Wie fragt ein Server nach Eingaben?  

Kurze Antwort:

Elicitation ist eine neue Funktion von MCP. Server fragen damit Daten direkt von Nutzern ab. Das passiert über eine Prüfung per JSON Schema. Es gibt 3 mögliche Antworten: accept, decline oder cancel .

Genaue Erklärung:

Manchmal brauchen Server neue Informationen. Diese Informationen fehlen im System. Ein Deployment-Server braucht zum Beispiel eine Bestätigung. Erst danach arbeitet er weiter .

So funktioniert der Ablauf :

Das JSON Schema hat klare Regeln. Es erlaubt nur einfache Objekte. Das sind einfache Texte, Zahlen oder Ja-Nein-Werte. Es erlaubt keine verschachtelten Daten oder Arrays .

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

Kurze Antwort: Sehr viele KI-Programme unterstützen MCP. Dazu gehören Claude Desktop, Claude Code und Claude.ai. Auch VS Code (über GitHub Copilot) nutzt MCP. Weitere Beispiele sind Cursor, Gemini CLI und Amazon Q. Es gibt noch viele weitere Programme.

ChatGPT unterstützt MCP ebenfalls. Aber die genauen Funktionen sind unterschiedlich. Das sagt die Firma OpenAI. Es hängt von Ihrem Vertrag ab. Es hängt auch von den Einstellungen ab .

Genaue Erklärung:

Die Programme unterstützen unterschiedliche Funktionen. Die Anleitung von MCP zeigt diese Funktionen. Bei ChatGPT müssen Sie aufpassen. Lesen Sie dazu die Anleitung von OpenAI. Dort ändern sich die Rechte und Funktionen oft. Hier ist eine Übersicht :

Viele andere Programme unterstützen MCP auch. Beispiele dafür sind Cline, Continue, Goose und fast-agent. Auch OpenAI Codex, 5ire, AgenticFlow, BoltAI und Chatbox gehören dazu. Es gibt noch viele mehr .

Für ChatGPT gibt es gerade eine Ausnahme. Die Firma OpenAI testet MCP noch. Firmen und Schulen bekommen bald alle Funktionen. Sie können dann auch Daten schreiben und ändern. Diese Verträge heißen Business, Enterprise und Edu. Nutzer mit dem Vertrag Pro haben andere Rechte. Sie können im Moment nur Daten lesen. Dafür brauchen sie den Entwickler-Modus .

Das Programm VS Code arbeitet sehr gut mit MCP zusammen. Sie speichern die Einstellungen in der Datei .vscode/mcp.json. Es gibt einen sicheren Bereich auf den Systemen macOS und Linux. Das Programm findet die Einstellungen von Claude Desktop ganz automatisch. Sie können MCP auch über einen Befehl installieren. Der Befehl heißt code --add-mcp .

5.2. Welche SDKs gibt es und in welchen Sprachen?  

Kurze Antwort:

Es gibt offizielle SDKs in 3 Gruppen. Man nennt diese Gruppen Tiers. Das sind die Gruppen:

• Tier 1: TypeScript, Python, C#, Go
• Tier 2: Java, Rust
• Tier 3: Swift, Ruby, PHP

Ein SDK für Kotlin kommt bald .

Genaue Erklärung:

Sie finden alle SDKs auf dieser Internetseite: github.com/modelcontextprotocol . Hier ist eine Übersicht:

Die Einteilung in Tiers hat einen Grund. Sie zeigt den Stand der Entwicklung. Sie zeigt auch die Pflege der Software.

Tier 1 bekommt sehr schnell Updates. Tier 2 bekommt Updates ein wenig später. Tier 3 bekommt Updates mit mehr Wartezeit .

5.3. Welche Reference-Server gibt es im offiziellen Repository?  

Kurze Antwort: Das offizielle Repository enthält 7 aktive Reference-Server. Das sind Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking und Time. Es gibt auch über 12 archivierte Server zum Lernen .

Genaue Erklärung:

Das sind die aktiven Reference-Server auf github.com/modelcontextprotocol/servers :

Es gibt auch über 12 archivierte Server im servers-archived-Repository . Dazu gehören zum Beispiel AWS KB Retrieval, Brave Search und GitHub. Auch GitLab, Google Drive, Google Maps und PostgreSQL sind dabei. Weitere sind Puppeteer, Redis, Sentry, Slack und SQLite. Diese Server sind heute eigene Projekte. Sie dienen als Referenz-Implementierungen. Sie zeigen verschiedene Muster für die Integration.

5.4. Wie baut man einen eigenen MCP-Server?  

Kurze Antwort: Sie wählen ein offizielles Bau-Paket. Das nennt man SDK. Sie legen die Tools, Resources und Prompts fest. Sie stellen die Verbindung ein. Dann melden Sie den Server an. Ein kleiner Server braucht weniger als 100 Zeilen Code .

Genaue Erklärung:

Der Bau von einem MCP-Server ist immer gleich. Die Programmier-Sprache ist dabei egal :

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",
});

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

Auf der offiziellen Internetseite für Clients steht eine Liste. Dort sehen Sie die Funktionen von jedem Client. Testen Sie Ihren Server mit passenden Clients. Der Client muss Ihre eingebauten Bausteine verstehen .

6.1. Welche Sicherheitsregeln gibt MCP vor?  

Kurze Antwort: MCP hat 4 wichtige Regeln. Die englischen Namen sind: User Consent and Control, Data Privacy, Tool Safety und LLM Sampling Controls .

Genaue Erklärung:

Die Sicherheit von MCP folgt einer wichtigen Idee. Sie als Nutzer haben immer die Kontrolle.

Diese Regeln sind Pflicht. Alle Programme müssen sich an diese Regeln halten. Nur so passen sie richtig zu MCP. Der Host hat die meiste Verantwortung. Der Host ist Ihre KI-Anwendung. Er muss für Sicherheit sorgen. Er muss Sie um Erlaubnis fragen. Er muss die MCP-Server streng voneinander trennen .

6.2. Wie werden Tool-Aufrufe sicher gemacht?  

Kurze Antwort: Der Host braucht immer eine Bestätigung von Ihnen. Das passiert vor der Ausführung von einem Tool. Das KI-Modell schlägt einen Tool-Aufruf vor. Der Host zeigt Ihnen diesen Vorschlag. Sie können den Vorschlag annehmen, ändern oder ablehnen .

Genaue Erklärung:

Die Sicherheit durch den Menschen funktioniert in mehreren Schritten :

Tool-Annotations helfen bei diesem Ablauf. Das sind wichtige Hinweise. Der Hinweis readOnlyHint bedeutet: Das Tool ändert keine Daten. Der Hinweis destructiveHint warnt vor gefährlichen Aktionen. Der Host nutzt diese Hinweise für Ihre Sicherheit. Sichere Tools können dadurch automatisch starten. Gefährliche Tools fordern eine extra Bestätigung von Ihnen .

6.3. Welche Risiken gibt es bei MCP? Und was schützt Sie davor?  

Kurze Antwort: Es gibt drei große Gefahren. Erstens: Prompt Injection. Das sind schädliche Inhalte in den Ergebnissen der Werkzeuge. Zweitens: Zu viele Rechte. Drittens: Fehlende Prüfungen von Eingaben. Folgende Dinge schützen Sie: Strenge Prüfungen. Nur so viele Rechte vergeben wie nötig. Und Server voneinander trennen .

Genaue Erklärung:

Die Anleitung empfiehlt eine Strategie mit vielen Schutzebenen :

6.4. Wie behandelt MCP den Datenschutz und die Zustimmung der Nutzer?  

Kurze Antwort: MCP braucht immer eine klare Zustimmung. Das gilt vor jeder Weitergabe von Daten. MCP nutzt das Prinzip der geringsten Rechte. Das bedeutet: Jeder bekommt nur die wirklich nötigen Rechte. Hosts müssen den Fluss der Daten kontrollieren. Der Datenfluss geht zwischen LLM und Servern.

Genaue Erklärung:

Das Modell für den Datenschutz von MCP ist sehr klar. Es gibt ganz klare Aufgaben :

Für das Sampling gibt es sehr strenge Regeln für die Zustimmung. Sampling bedeutet: Das System fragt das Sprachmodell um Hilfe. Sie als Mensch sehen die Anfrage vom Server. Sie sehen auch die Antwort vom Sprachmodell. Sie können beides ändern oder ablehnen. Das verhindert einen großen Fehler: Ein Server darf das Sprachmodell nicht unkontrolliert nutzen. Ein Server darf dem Sprachmodell keine falschen Befehle geben.

Es gibt das Prinzip der minimalen Sichtbarkeit. Das bedeutet: Ein Server bekommt nur die wirklich nötigen Daten. Hosts dürfen nicht einfach alle Daten für alle Server zeigen. Hosts müssen das genau kontrollieren. Jeder Server darf nur die passenden Daten bekommen.

7.1. Was sind die wichtigsten Regeln für MCP?  

Kurze Antwort: Das sind die wichtigsten Regeln: Nutzen Sie spezielle Server für einzelne Aufgaben. Prüfen Sie alle Eingaben streng. Schreiben Sie gute Beschreibungen für Werkzeuge. Der Mensch muss immer die Kontrolle behalten .

Genaue Erklärung:

7.2. Wie sieht die Zukunft von MCP aus?  

Kurze Antwort:

MCP entwickelt sich immer weiter. Es gibt neue Versionen der Spezifikation. Eine Spezifikation ist ein genauer Bauplan. Immer mehr Firmen nutzen MCP. Es gibt auch neue Funktionen. Dazu gehören zum Beispiel Elicitation und Tasks. Elicitation bedeutet das gezielte Abfragen von Daten. Tasks sind große Aufgaben für das Programm. Diese neuen Funktionen erweitern die Möglichkeiten .

Genaue Erklärung:

Viele Dinge zeigen eine gute Zukunft für MCP:

Die schnelle Entwicklung ist sehr wichtig. Die Texte zu MCP zeigen schon neue Test-Funktionen. Dazu gehören zum Beispiel Tasks. Tasks sind für Aufgaben mit langer Laufzeit. Es gibt auch Benachrichtigungen und eine Fortschrittsanzeige. Diese Anzeige nennt man Progress-Tracking . Die Spezifikation ist offen auf der Internetseite GitHub. So können alle Menschen bei der Entwicklung mithelfen .

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

Kurze Antwort: Jedes Programm hat einen eigenen Weg für die Einstellungen. VS Code nutzt eine Datei mit dem Namen .vscode/mcp.json. Cursor nutzt die eigenen Einstellungen im Programm. Claude Desktop nutzt eine lokale Datei für die Einstellungen .

Genaue Erklärung:

Die 3 bekanntesten Programme haben unterschiedliche Einstellungen für MCP:

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

Zusammenfassung