MCP-Client

Ein MCP-Client ist die Komponente einer KI-Anwendung, die über das Model Context Protocol (MCP) die Verbindung zu genau einem MCP-Server hält. Er ruft die Fähigkeiten des Servers ab, reicht Tool-Aufrufe des Sprachmodells durch und fügt die Ergebnisse in den Modellkontext ein. Der Client lebt im Host, also in der Anwendung, in der das Modell läuft, etwa Claude Desktop, ChatGPT oder Cursor.

Was ein MCP-Client ist und wo er sitzt

Das Model Context Protocol beschreibt, wie Sprachmodelle standardisiert auf externe Werkzeuge, Daten und Vorlagen zugreifen. Dafür definiert das Protokoll drei Rollen: Host, Client und Server. Der MCP-Client ist dabei das Bindeglied. Er sitzt nicht beim Modell und nicht beim Datensystem, sondern dazwischen, innerhalb der Host-Anwendung.

Wichtig für das Verständnis: Ein Host erzeugt für jede Server-Verbindung einen eigenen MCP-Client. Verbindest du Claude Desktop mit einem Dateisystem-Server, einem Git-Server und einem Shopware-Server, laufen darin drei Clients parallel. Jeder Client spricht ausschließlich mit seinem einen Server. Diese 1:1-Beziehung ist kein Implementierungsdetail, sondern Teil der Architektur des Protokolls.

Host, Client und Server im Überblick

Warum die Trennung von Host und Client sinnvoll ist

Auf den ersten Blick wirkt die Trennung zwischen Host und Client umständlich. In der Praxis sorgt sie dafür, dass Verbindungen sauber isoliert bleiben. Jeder MCP-Client kennt nur die Fähigkeiten seines Servers und hat keinen Einblick in andere Verbindungen. Der Host entscheidet, welche Tools dem Modell überhaupt angeboten werden und wann ein Nutzer eine Aktion freigeben muss.

Für dich als Entwickler bedeutet das: Du baust in der Regel keinen Client von Grund auf. Du nutzt einen Host, der Clients bereits mitbringt, oder du setzt ein SDK ein, das die Client-Logik kapselt. Die offiziellen Tier-1-SDKs gibt es für TypeScript, Python, Go und C#. Die TypeScript- und Python-Pakete wurden jeweils über eine Milliarde Mal heruntergeladen.

Was ein MCP-Client konkret tut

Die Arbeit eines MCP-Clients lässt sich auf wenige Kernaufgaben reduzieren. Er stellt die Verbindung zum Server her, erfragt dessen Fähigkeiten, reicht Aufrufe des Modells weiter und liefert die Antworten zurück in den Modellkontext. Dazu kommen Freigaben durch den Nutzer und eine Prüfung der Tool-Beschreibungen, bevor sie das Modell überhaupt erreichen.

Fähigkeiten abrufen und Tool-Aufrufe durchreichen

Die Kommunikation läuft über JSON-RPC 2.0. Ein Client fragt mit tools/list ab, welche Werkzeuge ein Server anbietet. Die Antwort enthält Name, Beschreibung und ein JSON-Schema für die Eingabeparameter jedes Tools. Diese Informationen gibt der Host an das Modell weiter, damit es entscheiden kann, welches Tool zu einer Aufgabe passt.

Entscheidet sich das Modell für ein Tool, formuliert es einen Aufruf. Der MCP-Client verpackt ihn als tools/call-Anfrage, sendet sie an den Server und wartet auf das Ergebnis. Ein vereinfachtes Beispiel für eine solche Anfrage sieht so aus:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "product_search",
    "arguments": { "query": "Rennrad Carbon", "limit": 5 }
  }
}

Das Ergebnis des Servers fügt der Client in den Kontext des Modells ein. Erst damit kann das Modell auf Basis echter Daten antworten, statt zu raten. Dieser Kreislauf aus Anfrage, Aufruf und Rückgabe ist das Herz jeder MCP-Integration.

Die drei Primitives: Tools, Resources, Prompts

Ein MCP-Server stellt drei Arten von Fähigkeiten bereit, die das Protokoll als Primitives bezeichnet. Für den Client ist entscheidend, wer die Nutzung jeweils steuert:

• Tools sind modellgesteuert. Das Sprachmodell entscheidet selbst, ob und wann es ein Tool aufruft, etwa eine Produktsuche oder das Anlegen einer Bestellung.
• Resources sind anwendungsgesteuert. Der Host beziehungsweise Client entscheidet, welche Datenquellen, Dateien oder Datensätze dem Modell als Kontext bereitgestellt werden.
• Prompts sind nutzergesteuert. Es handelt sich um vorbereitete Vorlagen, die ein Nutzer explizit auswählt, zum Beispiel über einen Slash-Befehl in der Oberfläche.

Diese Aufteilung hilft dir, Verantwortlichkeiten sauber zu verteilen. Ein Client muss nicht alle drei Primitives unterstützen. Viele Hosts beschränken sich auf Tools, weil sie in Agenten-Szenarien den größten Hebel haben.

Nutzerfreigaben und Sicherheit

Ein MCP-Client führt Tool-Aufrufe nicht blind aus. Der Host holt bei schreibenden oder kritischen Aktionen eine Freigabe des Nutzers ein. Darüber hinaus sollte ein Client die Tool-Beschreibungen, die er per tools/list erhält, gegen sogenanntes Tool Poisoning prüfen. Dabei versteckt ein manipulierter Server Anweisungen in der Beschreibung eines Tools, um das Modell zu unerwünschten Aktionen zu bewegen. Mehr dazu im Abschnitt zur Sicherheit weiter unten.

Transporte: Wie Client und Server kommunizieren

Das Protokoll trennt die Nachrichtenebene (JSON-RPC 2.0) vom Transport. Ein MCP-Client muss daher den passenden Transport für seinen Server beherrschen. Aktuell gibt es zwei standardisierte Varianten.

stdio für lokale Prozesse

Beim stdio-Transport startet der Client den Server als lokalen Prozess und kommuniziert über die Standard-Ein- und -Ausgabe. Dieser Weg ist einfach, braucht keine Netzwerkkonfiguration und eignet sich für Werkzeuge auf dem eigenen Rechner, etwa einen Dateisystem- oder Git-Server. Claude Desktop und Cursor nutzen stdio für lokal installierte Server.

Streamable HTTP für Remote-Server

Für Server, die auf einem anderen System laufen, kommt Streamable HTTP zum Einsatz. Der Client sendet seine Anfragen per HTTP-POST. Der Server antwortet entweder direkt mit einer Antwort oder öffnet einen Stream, über den er mehrere Nachrichten nacheinander liefert. Der ältere Transport HTTP+SSE ist seit Protokollversion 2025-03-26 abgekündigt. Neue Clients sollten ihn nicht mehr voraussetzen.

Was sich mit der Spezifikation 2026-07-28 ändert

Die aktuelle Protokollversion vom 28. Juli 2026 verändert die Arbeit eines MCP-Clients spürbar. Die wichtigsten Punkte aus dem offiziellen Changelog der Spezifikation 2026-07-28:

• Das Protokoll ist zustandslos. Es gibt keinen Mcp-Session-Id-Header und keinen initialize-Handshake mehr.
• Protokollversion und Client-Capabilities werden je Anfrage im Feld _meta mitgesendet.
• Ein neuer Aufruf server/discover liefert die Fähigkeiten des Servers.
• Benachrichtigungen laufen über subscriptions/listen.
• Multi-Round-Trip-Requests: Der Server kann mit input_required antworten, der Client wiederholt die Anfrage dann mit den angeforderten Antworten.
• Die Features Roots, Sampling und Logging sind deprecated, mit einer Übergangsfrist von mindestens zwölf Monaten.

Für die Praxis heißt das: Ein MCP-Client, der auf die ältere Sitzungslogik gebaut ist, braucht ein Update. Die Tier-1-SDKs nehmen dir das weitgehend ab, sofern du sie aktuell hältst. Bei Eigenentwicklungen solltest du prüfen, ob dein Client noch einen Handshake erwartet, den moderne Server nicht mehr anbieten.

MCP-Client in der Praxis: Beispiele

Abstrakte Rollen werden greifbar, wenn du dir konkrete Produkte anschaust. Die folgenden Beispiele zeigen, wo ein MCP-Client heute bereits im Einsatz ist und was er dort leistet.

Claude Desktop, ChatGPT und Cursor als Hosts

Claude Desktop, ChatGPT und der Code-Editor Cursor sind typische MCP-Hosts. Trägst du dort einen Server in der Konfiguration ein, erzeugt die Anwendung im Hintergrund einen MCP-Client, verbindet sich, ruft die Toolliste ab und stellt die Werkzeuge dem Modell zur Verfügung. Für dich als Nutzer bleibt der Client unsichtbar. Sichtbar wird er nur, wenn der Host eine Freigabe für einen Tool-Aufruf verlangt.

Wer einen eigenen Agenten baut, übernimmt die Host-Rolle selbst. Dann erzeugst du mit einem SDK die Client-Instanzen, entscheidest über Freigaben und steuerst, welche Tools das Modell sehen darf. Wie solche Agenten aufgebaut sind, erklärt unser Glossar-Eintrag zu KI-Agenten.

Shopware 6 als MCP-Server

Ein für den E-Commerce relevantes Beispiel ist Shopware 6. Der MCP-Server ist dort Teil des Cores und unter /api/_mcp für die Admin-API sowie unter /store-api/_mcp für die Store-API erreichbar. Seit Version 6.7.14.0 ist er ohne Feature-Flag aktiv. Die Authentifizierung läuft über die Zugangsdaten einer Integration, und je Integration legt eine Allowlist fest, welche Tools überhaupt angeboten werden.

Besonders ist der Umgang mit Toolsets: Ein MCP-Client kann über das Tool shopware-toolset-enable weitere Toolsets nachladen, statt von Anfang an die komplette Werkzeugliste in den Modellkontext zu laden. Das hält den Kontext schlank und reduziert Fehlentscheidungen des Modells. Wie du einen MCP-Server an Shop, ERP und CRM anbindest, beschreibt unser Beitrag MCP-Server erklärt.

HubSpot und OAuth 2.1

Remote-Server stellen zusätzliche Anforderungen an den Client. Der Remote-MCP-Server von HubSpot, seit dem 13. April 2026 allgemein verfügbar, verlangt vom MCP-Client eine Anmeldung per OAuth 2.1 mit PKCE. Ein Client, der nur statische API-Schlüssel beherrscht, kann sich dort nicht verbinden. Bei der Auswahl eines Hosts oder SDKs lohnt deshalb ein Blick darauf, welche Auth-Verfahren unterstützt werden.

Sicherheit: Tool Poisoning und Prompt Injection

Da ein MCP-Client Beschreibungen und Ergebnisse von außen in den Modellkontext einfügt, ist er eine Angriffsfläche. Die OWASP MCP Top 10 führen Tool Poisoning als eigene Kategorie (MCP03). Dabei enthält die Beschreibung eines Tools versteckte Anweisungen, die das Modell liest und befolgt, ohne dass der Nutzer sie sieht.

Wie wirksam solche Angriffe sind, zeigt eine Auswertung der Cloud Security Alliance vom Juli 2026: Im Benchmark MCPTox lag der durchschnittliche Angriffserfolg über 20 getestete Modelle bei 36,5 Prozent, im schlechtesten Fall bei 72,8 Prozent. Ein MCP-Client sollte Tool-Beschreibungen daher vor der Weitergabe an das Modell prüfen, Änderungen an bekannten Beschreibungen erkennen und bei verdächtigen Inhalten warnen.

Hinzu kommen klassische Angriffe über Daten: Enthält ein Resource-Inhalt oder ein Tool-Ergebnis eingeschleuste Anweisungen, spricht man von Prompt Injection. Der Client kann hier nicht alles abfangen, aber er kann Ergebnisse kennzeichnen, Freigaben erzwingen und die Rechte je Server auf das Nötige beschränken. Die Allowlist in Shopware ist ein gutes Beispiel für diese Begrenzung auf Serverseite.

Geschichte und Governance des Protokolls

Anthropic hat das Model Context Protocol am 25. November 2024 veröffentlicht. Im März 2025 übernahm OpenAI das Protokoll für seine Produkte, Google folgte im April 2025. Damit war MCP innerhalb weniger Monate bei den drei großen Modellanbietern gesetzt.

Seit dem 9. Dezember 2025 ist MCP ein Projekt der Agentic AI Foundation unter dem Dach der Linux Foundation. Die Gründungsbeiträge kamen von Anthropic (MCP), Block (goose) und OpenAI (AGENTS.md). Zum Start waren mehr als 10.000 veröffentlichte MCP-Server verfügbar. Details zur Gründung findest du in der Pressemitteilung der Linux Foundation.

Für dich als Entscheider bedeutet die neutrale Governance: Ein MCP-Client, den du heute baust oder einsetzt, ist nicht an einen Anbieter gebunden. Die Spezifikation wird offen weiterentwickelt, und die SDKs folgen ihr.

Häufige Fragen zum MCP-Client

Was ist der Unterschied zwischen MCP-Host und MCP-Client? Der Host ist die Anwendung mit dem Sprachmodell, etwa Claude Desktop oder ein eigener Agent. Der Client ist eine Protokollinstanz innerhalb des Hosts, die genau eine Verbindung zu einem MCP-Server hält. Ein Host kann viele Clients betreiben.

Kann ein MCP-Client mit mehreren Servern gleichzeitig sprechen? Nein. Die Beziehung ist 1:1. Für jeden zusätzlichen Server erzeugt der Host einen weiteren Client. Die Trennung sorgt dafür, dass Verbindungen isoliert bleiben und Rechte je Server vergeben werden können.

Muss ich einen MCP-Client selbst programmieren? In den meisten Fällen nicht. Fertige Hosts wie Claude Desktop, ChatGPT oder Cursor bringen Clients mit. Für eigene Agenten nutzt du die offiziellen SDKs für TypeScript, Python, Go oder C#, die die Client-Logik inklusive Transport kapseln.

Welche Sicherheitsaufgaben hat ein MCP-Client? Er holt Nutzerfreigaben für Tool-Aufrufe ein, prüft Tool-Beschreibungen auf versteckte Anweisungen (Tool Poisoning) und sollte Rechte je Server begrenzen. Die OWASP MCP Top 10 und der MCPTox-Benchmark der Cloud Security Alliance zeigen, dass diese Prüfungen nötig sind.