MCP-Client vs. MCP-Server: Wer macht was?
Die kurze Antwort: Der MCP-Server sitzt vor einem Tool (deinem CRM, deiner Datenbank, einem Verzeichnis) und stellt bereit, was dieses Tool kann. Der MCP-Client lebt in einer KI-App und spricht im Auftrag des Modells mit dem Server. Einen Client installierst du fast nie selbst: Die App, die du ohnehin nutzt, bringt ihre Clients mit. Das ist die ganze Client-vs-Server-Frage in drei Sätzen.
Die Verwirrung kommt meist von einem dritten Begriff aus der Spezifikation: dem Host. Sobald du alle drei Rollen nebeneinander siehst, bleibt das Bild stabil.
MCP-Client vs. MCP-Server: die drei Rollen
MCP, das Model Context Protocol, ist ein offener Standard, der KI-Agenten mit Tools verbindet. Er verteilt die Arbeit auf drei Rollen, und jede Rolle hat genau einen Job.
Der Host ist die KI-Anwendung selbst: Claude, ein IDE-Assistent, ein Agenten-Framework, dein eigener Agent. Der Host betreibt das Modell, entscheidet, wann ein Tool-Aufruf sinnvoll ist, zeigt dem Nutzer, was passiert, und setzt Berechtigungen durch. Er ist der Teil mit Benutzeroberfläche und Meinung.
Der MCP-Client ist eine Komponente im Host. Er verwaltet eine Verbindung zu einem MCP-Server: Er öffnet die Session, holt den Tool-Katalog des Servers, leitet Tool-Aufrufe weiter und gibt Ergebnisse ans Modell zurück. Ein Host mit fünf verbundenen Servern betreibt fünf Clients, einen pro Verbindung. Du konfigurierst Server; die Clients erzeugt der Host still im Hintergrund.
Der MCP-Server kapselt ein bestimmtes System und stellt dessen Fähigkeiten im Standardformat bereit: Tools, die das Modell aufrufen kann, Ressourcen, die es lesen kann, Prompt-Vorlagen, die es nutzen kann. Der Server eines CRM könnte search_contacts und create_deal anbieten. Ein Datenbank-Server vielleicht run_query. Wie ein Server von innen aussieht, ist ein eigenes Thema und steht in [unserem Guide zu MCP-Servern](/de/blog/what-is-an-mcp-server).
Eine Analogie, kurz: Denk an ein Restaurant. Der Host ist der Gast, der entscheidet, was er bestellt. Der Client ist der Kellner, der die Bestellung in die Küche trägt und den Teller zurück an den Tisch. Der Server ist die Küche, der einzige Teil, der wirklich kocht. Niemand erwartet, dass der Gast etwas brät, und die Küche nimmt keine Bestellungen am Tisch auf.
| Rolle | Wo sie läuft | Wer sie baut | Beispiel |
|---|---|---|---|
| Host | Die KI-App, auf deinem Rechner oder in der Cloud | Der App-Anbieter, oder du, wenn du Agenten baust | Claude, ein IDE-Assistent |
| Client | Im Host, einer pro Server-Verbindung | Kommt mit dem Host, über die MCP-SDKs | Der Connector, den Claude beim Hinzufügen eines Servers anlegt |
| Server | Beim Tool, als lokaler Prozess oder Remote-Endpunkt | Der Tool-Anbieter oder die Community | Der MCP-Server eines CRM, mcp.tulimoa.com |
"Also ist Claude mein MCP-Client, oder?"
Nicht ganz, und genau das ist das Missverständnis hinter den meisten Host-vs-Client-Fragen. Claude ist ein Host mit eingebauten Clients. Wenn du Claude einen MCP-Server hinzufügst, erzeugt Claude intern einen Client für diese Verbindung. Es gibt kein separates "MCP-Client"-Programm zum Herunterladen, weshalb die Suche danach ins Leere läuft.
Die andere Hälfte der Verwirrung liegt auf der Tool-Seite. Dein CRM betreibt auch keinen Client. Es betreibt (oder sollte betreiben) den Server. Der Client lebt immer in der KI-App; der Server sitzt immer bei dem Ding, das benutzt wird.
Ein typisches Setup hat also drei Beteiligte, und du fasst nur einen davon an. Du sagst dem Host, mit welchen Servern er sich verbinden soll. Der Host verwaltet seine Clients. Der Anbieter betreibt den Server. Fertig.
Wer baut was
Wenn du eine KI-App nutzt: Du baust nichts. Du trägst Server in die Konfiguration des Hosts ein, und der Host übernimmt das Protokoll. Tulimoas [Live-Verzeichnis-Server](/de/mcp) hinzuzufügen ist eine Konfigzeile, und Lesen geht ohne Account.
Wenn du ein SaaS-Produkt anbietest: Du baust einen Server, niemals einen Client. Die Agenten deiner Kunden bringen ihre eigenen Clients mit. Stelle deine Kernaktionen als Tools mit klaren Namen und Beschreibungen bereit, und jeder MCP-Host da draußen kann sie ohne Integrationsarbeit nutzen.
Wenn du deinen eigenen Agenten baust: Dann baust du einen Host, also auch die Client-Seite. Die offiziellen SDKs übernehmen Sessions, Discovery und Transport. Praktisch heißt das: ein Client pro Server, und die kombinierte Tool-Liste wandert in deine Modell-Aufrufe.
Erwähnenswert ist der Kontrast zu reinem Function Calling, bei dem jede App ihre Funktionsdefinitionen von Hand gegen jede API schreibt. MCP verlagert diese Arbeit auf den Server, einmal, für alle Clients. Der volle Vergleich steht in [MCP vs. Function Calling](/de/blog/mcp-vs-function-calling).
Ein Client pro Server, und warum die Zahl zählt
Weil ein Host einen Client pro Server betreibt, summieren sich Verbindungen sichtbar. Zehn Server bedeuten zehn Client-Sessions und zehn Tool-Kataloge im Kontext des Modells, bevor es ein Wort deines Prompts liest.
Die Rollen lassen sich aber kombinieren. Ein einzelnes Programm kann auf der einen Seite Server und auf der anderen Client sein. Genau das ist ein MCP Gateway: ein Server in Richtung deines Agenten, viele Clients in Richtung der Tools dahinter. Was ein Gateway leistet, haben wir in [einem eigenen Beitrag](/de/blog/what-is-an-mcp-gateway) aufgeschrieben.
Die Erkenntnis, die die meiste Verwirrung auflöst: Hosts enthalten Clients, Tools stehen hinter Servern, und das Einzige, was du je konfigurierst, ist der Host.
Häufige Fragen
Ist Claude ein MCP-Client oder ein MCP-Host?
Claude ist ein Host. Er enthält MCP-Clients, einen für jeden Server, den du verbindest. Wenn jemand sagt "Claude unterstützt MCP", heißt das: Der Host bringt die Client-Seite des Protokolls schon mit.
Muss ich einen MCP-Client separat installieren?
Nein. Clients sind Komponenten in KI-Apps, keine eigenständigen Programme. Wenn deine App MCP unterstützt, ist der Client schon da; du zeigst ihm nur den Endpunkt oder Befehl eines Servers.
Kann ein Programm gleichzeitig MCP-Client und MCP-Server sein?
Ja. Ein Gateway oder Proxy macht genau das: Es präsentiert sich deinem Agenten als einzelner Server und agiert gegenüber den dahinterliegenden Servern als Client.
Wer betreibt den MCP-Server für ein Tool wie mein CRM?
Idealerweise der Anbieter, als Remote-Endpunkt, auf den du deinen Host zeigen lässt. Bietet der Anbieter keinen an, füllen oft Community-Server die Lücke, meist lokal mit deinem eigenen API-Key betrieben.