> Markdown twin of https://conduitllm.com/de/mcp-distribution.html > Einen MCP-Server zu hosten ist keine Kundendemo. Vergleich von gehostetem Chat, Claude Desktop mit Extension und einem eigenen Desktop-Client. --- MCP-Distribution # Einen MCP-Server einem Kunden vorführen Der beste Fall heute: Der Interessent installiert den Assistenten eines anderen, meldet sich an und fügt deinen Server dort hinzu — ein Klick, wenn du ihn paketiert hast, eine von Hand bearbeitete Konfigurationsdatei, wenn nicht. Den Server im Internet zu hosten ändert das nicht; es veröffentlicht nur einen Endpunkt. Der Kunde braucht weiterhin einen Client, ein Modell und einen ersten Bildschirm, der dir gehört. ## Wie die Verteilung eines MCP-Servers heute aussieht Die meisten MCP-Server starten als lokaler Prozess. Der Client startet sie über `stdio` — der Server ist ein Kindprozess, der JSON-RPC über stdin und stdout spricht. Claude Desktop, Cursor und Conduit machen das alle so. Es gibt nichts zu deployen im Cloud-Sinne. Der Client *ist* das Deployment. Claude Desktop hat seine Seite davon deutlich vereinfacht: Ein als `.mcpb`-Desktop-Extension paketierter lokaler Server installiert sich mit einem Klick unter Settings → Extensions, und ein entfernter Server lässt sich als Custom Connector hinzufügen. Die handgeschriebene Konfiguration ist heute der Rückfallweg für alles, was nicht so paketiert ist — ein Snippet für `claude_desktop_config.json`: claude_desktop_config.json ``` { "mcpServers": { "your-product": { "command": "npx", "args": ["-y", "@you/mcp-server"] } } } ``` Du fügst das in einen Slack-Thread oder ein PDF ein. Der Interessent installiert Node, installiert Claude Desktop (macOS, Windows und eine Linux-Beta für Ubuntu und Debian), findet die Konfigurationsdatei an einem je nach Plattform anderen Pfad, fügt ein, ohne das JSON zu zerstören, beendet die App vollständig — das Fenster zu schließen reicht nicht — und startet sie neu. Den Server als Extension zu paketieren nimmt das meiste davon weg, und wenn du das kannst, solltest du es tun. Was kein Weg wegnimmt, ist der Rest: Er meldet sich bei Anthropic an, wählt ein Modell, für das er bezahlt, und sucht deinen Server in einer Werkzeugliste in der App eines anderen. Ist der Server stattdessen remote, ändert sich das Rezept, aber nicht die Form. Du veröffentlichst eine Streamable-HTTP-URL — Render, Fly.io, FastMCP Cloud, Smithery, ein VPS — und der Kunde fügt *that* in einen Client ein, der Remote-MCP spricht. Hosting beantwortet die Frage „kann eine andere Maschine diesen Prozess erreichen?“ Es beantwortet nicht „hat ein nicht-technischer Interessent eine App, ein Modell und einen Grund, sie zu öffnen?“ ## Warum „schick ihnen einfach die Config“ scheitert ### Der Interessent ist kein Entwickler Eine JSON-Datei in einem Application-Support-Ordner zu bearbeiten, `npx` zu installieren und `ENOENT` zu debuggen, weil Windows `npx.cmd` wollte — das ist ein normaler Dienstag für die Person, die den Server gebaut hat. Es ist kein vernünftiger erster Termin mit einem Käufer. Ein-Klick-Extension-Formate haben den größten Teil dieser Mühe beseitigt, und das ist eine echte Verbesserung — aber ein Klick bleibt ein Schritt, den du einem Käufer in einer App zumutest, die er erst installieren und in der er sich erst anmelden musste, und die verbleibenden Schritte kontrollierst du nicht. ### Dein Produkt erscheint im Client eines Wettbewerbers Wenn es funktioniert, hat der Interessent nicht dein Produkt geöffnet. Er hat Claude geöffnet, oder ChatGPT, oder Cursor. Deine Werkzeuge sind ein Listeneintrag unter fremder Marke, in einem fremden Fenster, neben allem anderen, was er bereits verbunden hat. Du hast dein Demo-Budget in den Onboarding-Funnel einer anderen Firma gesteckt. Erinnern wird er sich an den Assistenten, für den er ohnehin bezahlt — nicht an den Connector, den er einfügen sollte. ### Du kontrollierst weder das Modell noch den ersten Bildschirm Claude Desktop spricht mit Claude. Du kannst die Demo nicht auf ein günstigeres Modell richten, nicht auf eine lokale Ollama-Instanz für einen abgeschotteten Raum und nicht auf das Modell, das deine Werkzeuge zufällig gut aufruft. Du kannst weder den System-Prompt noch den Leerzustand noch den Namen in der Titelleiste setzen. Das Erste, was er sieht, ist das Produkt von Anthropic. Das ist eine schlechte Ausgangslage, wenn die Werkzeuge *das Produkt* sind. ## Die Optionen im Vergleich Drei Wege, einem Interessenten MCP-Werkzeuge vorzusetzen. Den Server zu hosten ist eine Spalte innerhalb der ersten beiden Zeilen, keine vierte Option — eine URL braucht immer noch einen Client. | Ansatz | Einrichtungsaufwand für den Interessenten | Wessen Marke | Wessen Modell | Wer hält den Chat | | --- | --- | --- | --- | --- | | Gehosteter Chat oder Widget | Eine URL öffnen. Geringste Reibung. | Deine, wenn du das Frontend gebaut hast. | Das, was du serverseitig verdrahtet hast. | Meistens du. Du liegst im Chat-Pfad — deshalb kommt der AV-Vertrag vor dem PoC. | | Claude Desktop + Extension oder Connector | Claude installieren und anmelden, dann ein Klick für eine paketierte `.mcpb`-Extension — oder JSON von Hand für alles Unpaketierte. | Die von Anthropic. | Nur Claude. | Anthropic. Die Unterhaltungen liegen auf deren Servern, nicht auf der Festplatte des Interessenten, und ein entfernter Custom Connector wird aus der Cloud von Anthropic erreicht, nicht vom Rechner des Interessenten. | | Desktop-Client, den er installiert | Die App installieren und deinen Connector in den Einstellungen hinzufügen (oder in einer JSON-Datei, je nach Client). | Die des Clients, sofern du ihn nicht umbrandest. | Die Anbieter, die dieser Client unterstützt. | Auf seinem Rechner, wenn der Client local-first ist und nicht proxyt. Der Modellanbieter sieht weiterhin die Prompts, die du ihm schickst. | Nimm den gehosteten Chat, wenn der Interessent nie Software installieren wird und du bereit bist, im Datenpfad zu sitzen. Nimm Claude Desktop, wenn er ohnehin dort lebt und du nur belegen musst, dass die Werkzeuge existieren. Nimm einen Desktop-Client, wenn die Demo das Produkt ist: deine Werkzeuge, ein Modell deiner Wahl, auf einem Rechner, den du nicht betreuen musst. ## Stattdessen deinen eigenen Client ausliefern [Conduit](https://conduitllm.com/de/) ist ein quelloffener Desktop-KI-Client. Er spricht MCP über lokales stdio und entferntes streamable HTTP, unter Windows, macOS und Linux. Der Interessent lädt einen Installer herunter, hinterlegt einen Anbieter-Schlüssel (oder richtet ihn auf Ollama) und fügt deinen Server auf der [Connectors-Seite](https://conduitllm.com/de/docs.html#tools) hinzu — Befehl plus Argumente oder eine URL. Ist dein Remote-Server in der offiziellen MCP-Registry veröffentlicht, findet er ihn per Namen und fügt ihn mit einem Klick hinzu. Der Connector läuft auf seinem Rechner, nicht auf unserem. Wenn dein Server remote ist und in der [offiziellen MCP-Registry](https://registry.modelcontextprotocol.io), veröffentlicht ist, tippt der Interessent überhaupt nichts: Er sucht dein Produkt auf der Connectors-Seite nach Namen und fügt es mit einem Klick hinzu. Conduit filtert die Registry auf Server, die ein streamable-HTTP-Remote veröffentlichen, und lehnt reine SSE-Einträge mit Begründung ab, statt später zu scheitern. Braucht der Server eine Authentifizierung, spricht er OAuth 2.1 — der Interessent meldet sich im Browser an, und das Token liegt in seinem OS-Schlüsselspeicher, nie in der Oberfläche und nie bei dir. Das ist bereits eine andere Demo als Claude Desktop. Er ist nicht auf eine Modellfamilie festgelegt. Er kann vollständig lokal arbeiten. Ein Werkzeug fragt vorher, es sei denn, sein Server markiert es als read-only. Unterhaltungen bleiben in SQLite auf seiner Festplatte. Modellanfragen gehen von seinem Rechner an den Anbieter, den er konfiguriert hat. Es gibt keinen Conduit-Server dazwischen — und genau deshalb macht der Einsatz von Conduit als Client *you* allein noch nicht zum Auftragsverarbeiter des Chats. Zwei Grenzen, klar benannt. Erstens installiert er weiterhin *Conduit*, sofern du den Namen nicht unter Einstellungen → Branding in dieser Kopie änderst oder einen paketierten OEM-Build aus dem Quellcode erzeugst. Zweitens tippt er den Connector weiterhin selbst ein, sofern dein Server nicht in der Registry steht — und in beiden Fällen kommt der Build nicht bereits darauf ausgerichtet an. Diese Paketierungsschicht ist heute kein herunterladbarer Installer. Die [White-Label-Seite](https://conduitllm.com/de/whitelabel.html) ist das Programm für alle, die beides brauchen. Diese Seite beschreibt das Distributionsproblem, das dieses Programm zu Ende bringen soll. ## Was heute ausgeliefert wird Derselbe Status wie in der White-Label-Tabelle, gekürzt auf das, was eine Demo wirklich braucht. | Fähigkeit | Status | | --- | --- | | Desktop-Client für Windows, macOS und Linux | Ausgeliefert | | MCP über lokales stdio und entferntes streamable HTTP, mit Zustimmung | Ausgeliefert | | Connector in den Einstellungen hinzufügen — keine JSON-Datei | Ausgeliefert | | 17 Anbieter, darunter Ollama und LM Studio | Ausgeliefert | | Local-first-Speicherung, eigener Schlüssel, kein Proxy | Ausgeliefert | | Runtime-Branding — Einstellungen → Branding | Ausgeliefert | | Unsignierte Installer auf GitHub | Ausgeliefert | | Paketierter OEM-Installer aus `brand.md` | Early Access aus dem Quellcode | | Build, der bereits mit deinen Connectors verdrahtet ist | In Entwicklung | | Vom Betriebssystem signierte und notarisierte Builds | In Entwicklung | **Du kannst einem Interessenten keinen gebrandeten, vorverdrahteten Installer von GitHub geben.** Du kannst ihm einen Standard-Conduit-Build geben, den Connector gemeinsam in den Einstellungen eintragen und das Fenster für den Termin umbenennen. Wenn die Demo als *dein* Produkt mit bereits verbundenen Servern starten muss, ist das der Weg über eine Design-Partnerschaft, kein Download-Button. Die Installer sind nicht vom Betriebssystem signiert, daher warnen Windows SmartScreen und macOS Gatekeeper beim ersten Start. Sag das dem Interessenten, bevor er klickt, oder baut gemeinsam aus dem Quellcode. Einzelheiten stehen in der [Installationsdokumentation](https://conduitllm.com/de/docs.html#install). ## Fragen **Kann ich einen MCP-Server verteilen, ohne dass Nutzer JSON bearbeiten müssen?** Ja. In Conduit werden MCP-Server auf der Connectors-Seite hinzugefügt — Befehl und Argumente für einen lokalen stdio-Server, oder eine URL für einen entfernten streamable-HTTP-Server. Noch besser: Ist dein Remote-Server in der offiziellen MCP-Registry veröffentlicht, sucht der Interessent ihn per Namen und fügt ihn mit einem Klick hinzu, ohne eine URL zu tippen, und meldet sich per OAuth an, falls nötig. Was es weiterhin nicht gibt, ist ein Build, der bereits mit deinem Connector verdrahtet ankommt — das ist die Paketierungsschicht, und sie ist in Entwicklung. **Gibt es eine Claude-Desktop-Alternative, die MCP unter Windows unterstützt?** Mehrere Desktop-Clients sprechen MCP unter Windows. Claude Desktop ist der Referenz-Client und spricht ausschließlich mit den Modellen von Anthropic. Conduit ist eine quelloffene Alternative, die unter Windows, macOS und Linux läuft, sich mit 17 Anbietern einschließlich lokalem Ollama und LM Studio verbindet und MCP über lokales stdio und entferntes streamable HTTP spricht. Die Installer sind noch nicht vom Betriebssystem signiert, daher warnt SmartScreen beim ersten Start. **Kann ich einen MCP-Client unter meiner eigenen Marke ausliefern?** Teilweise. Conduit lässt sich heute in einer Standardinstallation unter Einstellungen → Branding umbenennen, mit eigenem Logo und eigenen Farben versehen. Paketierte OEM-Installer sind Early Access aus dem Quellcode für Design-Partner. Ein Build, der bereits mit deinen MCP-Servern verbunden ist, ist in Entwicklung — einen vorverdrahteten, gebrandeten Installer kannst du nicht von GitHub herunterladen. **Brauche ich einen Auftragsverarbeitungsvertrag, um einen MCP-Server vorzuführen?** Das hängt davon ab, wohin die Unterhaltung und die Tool-Aufrufe gehen. Eine gehostete Chat-Demo, die Prompts auf deinen Servern speichert, macht dich in der Regel zum Auftragsverarbeiter dieses Chats. Ein local-first Desktop-Client belässt die Unterhaltung auf dem Rechner des Interessenten und schickt Modellanfragen von dort an den Anbieter; Conduit liegt nicht in diesem Pfad. Ist dein MCP-Server selbst ein gehosteter Dienst, der Tool-Argumente entgegennimmt, ist das ein eigener Pfad und kann weiterhin einen AV-Vertrag erfordern. Dies ist keine Rechtsberatung. **Ist das Hosten meines MCP-Servers dasselbe wie ihn vor einen Kunden zu bringen?** Nein. Hosting veröffentlicht eine Streamable-HTTP-URL, die andere MCP-Clients aufrufen können. Sie vor einen Kunden zu bringen, ist das Client-Problem: Er braucht weiterhin eine App, die MCP spricht, ein Modell und einen ersten Bildschirm. Eine öffentliche URL ohne Client ist ein Connector, der niemanden zum Verbinden hat. [Conduit herunterladen](https://github.com/runningpixels/conduit/releases) Wenn die Demo nur als gebrandeter, vorverdrahteter Build funktioniert, [lies den White-Label-Status](https://conduitllm.com/de/whitelabel.html) and [starte einen Design-Partner-Thread](https://github.com/runningpixels/conduit/discussions).