MCP-Clients 2026: Claude Desktop, Cursor, Zed, Cline, VS Code und Custom im Vergleich

MCP-Clients sind die Host-Anwendungen, die über das Model Context Protocol (MCP) mit MCP-Servern sprechen und deren Funktionen einem LLM verfügbar machen. Zu den wichtigsten Clients 2026 zählen Claude Desktop, Cursor, Zed, Cline, VS Code sowie eigene Clients via SDK. Sie unterscheiden sich vor allem darin, welche MCP-Funktionen (Tools, Resources, Prompts, Elicitation) und welche OAuth-Verfahren sie tatsächlich umsetzen.

• Tools sind der gemeinsame Nenner: Praktisch jeder ernstzunehmende Client unterstützt MCP-Tools. Bei Resources, Prompts, Elicitation und der OAuth-Registrierung driften die Implementierungen auseinander, genau hier entscheidet sich die Client-Wahl.
• VS Code deckt die Spezifikation am breitesten ab: Laut der gemeinschaftlich gepflegten Client-Liste auf modelcontextprotocol.io (Stand Mai 2026, inzwischen entfernt) unterstützt VS Code mit GitHub Copilot 12 von 14 gelisteten Funktionen. Claude Desktop, der Desktop-Host von Anthropic, kommt auf Tools, Resources, Prompts, Roots (deprecated), MCP Apps und OAuth; Cursor, Zed und Cline sind auf Coding-Workflows zugeschnitten.
• Custom heißt volle Kontrolle: Wer eigene Governance, mandantenfähige Berechtigungen und durchgängige Audit-Trails braucht, baut über die offiziellen SDKs (Python, TypeScript) einen eigenen Client.

Was MCP-Clients leisten: die Bausteine

MCP wurde am 25. November 2024 von Anthropic (Autoren David Soria Parra und Justin Spahr-Summers) als offener Standard veröffentlicht, über den KI-Anwendungen externe Systeme wie Dateisysteme, Datenbanken, Geschäftssysteme und Dev-Tools anbinden. Am 9. Dezember 2025 spendete Anthropic MCP an die neu gegründete Agentic AI Foundation (AAIF) unter der Linux Foundation, mitgetragen von Block und OpenAI sowie mit Platin-Unterstützung von AWS, Bloomberg, Cloudflare, Google und Microsoft. Damit ist MCP 2026 der fundamentale Agent-to-Tool-Standard. Für die Kommunikation zwischen Agenten gibt es das von Google initiierte A2A-Protokoll, das seit Juni 2025 ebenfalls bei der Linux Foundation liegt, unter anderem mit Microsoft und AWS als Gründungsmitgliedern. Es ergänzt MCP, ersetzt es aber nicht.

Ein MCP-Client ist immer Teil einer Host-Anwendung. Diese kann mehrere Clients gleichzeitig betreiben, jeweils mit eigener Verbindung zu einem MCP-Server. Die Bausteine, die ein Client verarbeiten kann, lassen sich so einordnen:

• Tools: Vom Modell aufrufbare Aktionen (z. B. „Datei lesen“, „CRM-Datensatz anlegen“, „Websuche“). Der wichtigste und am breitesten unterstützte Baustein.
• Resources: Vom Server bereitgestellte Kontextdaten (Dokumente, Schemata, Datei-Inhalte), die der Client dem Modell oder dem Nutzer zur Auswahl anbietet.
• Prompts: Vorgefertigte, vom Server angebotene Prompt-Vorlagen bzw. Slash-Commands, die der Nutzer im Client auslösen kann.
• Elicitation: Der Server fragt über den Client gezielt Angaben beim Nutzer ab, etwa eine Bestätigung oder einen fehlenden Parameter. Eingeführt mit der Spec-Revision 2025-06-18.
• Sampling: Der Server fordert über den Client eine LLM-Antwort an, er nutzt also das Modell des Hosts, ohne selbst einen API-Key zu besitzen. Kosten- und sicherheitssensibel und seit der Spec-Revision 2026-07-28 als deprecated markiert.

Transport und Konfiguration

Technisch setzt MCP auf JSON-RPC 2.0 über mehrere Transporte. Lokal kommuniziert der Client per stdio mit einem als Subprozess gestarteten Server; remote ursprünglich über Server-Sent Events und seit der Spec-Revision 2025-03-26 (März 2025) über Streamable HTTP. Dieselbe Revision ergänzte OAuth 2.1 und Tool-Annotations. Das ebenfalls eingeführte JSON-RPC-Batching wurde mit der Revision 2025-06-18 wieder gestrichen. Die November-2025-Spec (2025-11-25) brachte experimentelle Tasks für asynchrone Operationen, URL-Mode-Elicitation und Client ID Metadata Documents. Mit der aktuellen Revision 2026-07-28 wurde MCP stateless: Sessions und der initialize-Handshake entfallen, Server müssen sich per server/discover ausweisen und sollen ihre Identität in jeder Antwort mitsenden, Tasks wanderten in eine offizielle Extension. MCP Apps (SEP-1865, Anfang 2026) standardisierte zudem, wie MCP-Server interaktive UI an Hosts wie Claude und ChatGPT ausliefern.

Konfiguriert werden Clients überwiegend über eine JSON-Datei, die Server-Einträge auflistet. Konzeptionell sieht ein lokaler stdio-Server-Eintrag so aus:

```json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/projekt/daten"]
}
}
}
```

Für Remote-Server über Streamable HTTP wird statt command ein url-Eintrag plus OAuth-2.1-Konfiguration hinterlegt. Die Dateipfade und das genaue Schlüssel-Schema unterscheiden sich je Client, das Grundmuster ist jedoch identisch.

Client-Vergleich: Support und Einsatzzweck

Die folgende Tabelle ordnet die wichtigsten Clients ein. Die Spalte „MCP-Support“ nennt die Bausteine laut Hersteller-Dokumentation und laut der gemeinschaftlich gepflegten Client-Liste auf modelcontextprotocol.io (Stand Mai 2026, inzwischen entfernt), die Spalte „Wann einsetzen“ den primären Einsatzzweck. Sampling und Roots sind seit der Spec-Revision 2026-07-28 abgekündigt und als „deprecated“ gekennzeichnet. Bei OAuth steht in Klammern das Registrierungsverfahren: CIMD (Client ID Metadata Documents) oder das mit derselben Revision abgekündigte DCR (Dynamic Client Registration). Die Clients entwickeln sich schnell, prüfe vor einer Entscheidung deshalb die aktuelle Dokumentation.

Quer dazu sind n8n, Mastra, LangGraph und PydanticAI relevant: n8n und Mastra sind MCP-nativ, LangGraph unterstützt Streamable HTTP für Remote-MCP-Server. Diese sind streng genommen Orchestrierungs-/Automationsplattformen, agieren aber faktisch als MCP-Clients und sind für produktive DACH-Stacks oft die eigentliche Integrationsschicht. Die offiziellen SDKs für Python und TypeScript kamen laut Anthropic im Dezember 2025 zusammen auf über 97 Mio. Downloads pro Monat.

Sampling: seit Juli 2026 abgekündigt

Lange galt Sampling als schärfster Trennstrich zwischen den Clients: Tools beantworten die Frage „Was kann der Agent tun?“, Sampling die Frage „Darf der Server eigenständig das Modell des Hosts nutzen?“. Unter den verglichenen Standard-Clients setzt es laut der genannten Client-Liste nur VS Code um. Mit der Spec-Revision 2026-07-28 ist Sampling zusammen mit Roots und Logging als deprecated markiert (SEP-2577). Es funktioniert während der mindestens zwölfmonatigen Übergangsfrist weiter, neue Clients und Server sollen es aber nicht mehr einbauen. Server, die eigenes Reasoning brauchen, binden die LLM-API direkt an. Für die Client-Wahl zählen deshalb andere Kriterien: Resources und Prompts, Elicitation für Rückfragen an den Nutzer, OAuth mit Client ID Metadata Documents statt der abgekündigten Dynamic Client Registration und die Unterstützung der zustandslosen Revision 2026-07-28. Ob ein Client diese Revision schon umsetzt, steht in seiner Dokumentation. Bei Coding-Werkzeugen wie Cursor, Zed oder Cline steht ohnehin der Tool-Zugriff im Vordergrund: Dateien lesen, Tests starten, Repos durchsuchen.

Praxisbeispiel: Client-Wahl für eine Agentur

Eine DACH-Agentur will einen SEO-Recherche-Workflow bauen, der einen internen CMS-MCP-Server und einen Keyword-MCP-Server anbindet. Drei realistische Wege:

1. Schnelle Exploration: In Claude Desktop beide Server einbinden: lokale stdio-Server per JSON-Konfig, Remote-Server als Custom Connector. Tools, Resources und Prompts laufen sofort; ideal für den Proof-of-Concept innerhalb eines Tages, ohne Code.
2. Entwickler-Integration: In Cursor oder VS Code denselben CMS-Server einbinden, um den Server-Code mit Tool-Zugriff direkt in der IDE zu entwickeln und zu debuggen.
3. Produktivbetrieb: Ein Custom Client via TypeScript-SDK als Teil der eigenen Anwendung. Hier werden OAuth-2.1-Scopes pro Mandant und ein durchgängiger Audit-Trail mit einer Correlation-ID umgesetzt, also Anforderungen, die Standard-Clients nicht abdecken. Braucht ein Server eigenes Reasoning, bindet er die LLM-API direkt an, statt auf das abgekündigte Sampling zu setzen.

Token- und Kostenwirkung sind dabei direkt steuerbar: Wer Tool-Aufrufe pro Task begrenzt und typisierte, komprimierte Server-Antworten erzwingt, hält den Verbrauch kalkulierbar. Laut Anthropic verbrauchen Agenten rund 4-mal so viele Token wie ein einfacher Chat, Multi-Agent-Systeme rund 15-mal so viele. Das spricht dafür, autonome Tool-Ketten bewusst zu deckeln.

Sicherheit und Governance

MCP arbeitet mit einem optimistischen Trust-Modell, das syntaktische Korrektheit mit semantischer Sicherheit gleichsetzt. Dokumentierte Angriffe 2025 sind Tool Poisoning (Invariant Labs, 1. April 2025), Look-alike-Server-Squatting und CyberArks Full-Schema Poisoning, bei dem jeder Teil eines Tool-Schemas zur Injektionsstelle wird. Die Konsequenz für die Client-Wahl: Welcher Client zum Einsatz kommt, ist eine Governance-Entscheidung. Pflicht sind Sandboxing, scope-limitierte OAuth-2.1-Tokens, Least-Privilege und das Verbot, dass ein Agent eigenständig MCP-Server aus nicht vertrauenswürdigen Registries installiert. In Deutschland und Österreich kommen AVV-Ketten nach Art. 28 DSGVO je Server-Betreiber hinzu, in der Schweiz Verträge zur Auftragsbearbeitung nach Art. 9 DSG, je nach Branche außerdem Aufbewahrungs- und WORM-Anforderungen.

Für Agenturen und B2B-Entscheider

Die pragmatische Empfehlung für 2026: Standard-Clients für das, was sie können. Claude Desktop für breite Assistenz und schnelle Server-Tests, Cursor, VS Code, Zed und Cline für Entwickler-Produktivität, wobei VS Code die Spezifikation am breitesten abdeckt. Sobald ein LLM in ein eigenes Produkt eingebettet wird oder mandantenfähige Berechtigungen, lückenlose Audit-Trails und souveränes Hosting gefragt sind, führt der Weg zum Custom Client via SDK. Blck Alpaca aus Wien unterstützt DACH-Unternehmen dabei, die passende Client-Strategie zu wählen, eigene MCP-Server zu bauen und MCP-Workflows DSGVO-konform und auditierbar in Betrieb zu nehmen.