Distribution MCP
Comment présenter un serveur MCP à un client
Aujourd’hui, au mieux : le prospect installe l’assistant de quelqu’un d’autre, s’y connecte et y ajoute votre serveur — en un clic si vous l’avez empaqueté, via un fichier de configuration modifié à la main sinon. Héberger le serveur sur internet n’y change rien ; cela ne publie qu’un endpoint. Le client a toujours besoin d’une application, d’un modèle et d’un premier écran qui soit le vôtre.
À quoi ressemble la distribution d’un serveur MCP aujourd’hui
La plupart des serveurs MCP démarrent comme un processus local. Le client les lance via stdio
— le serveur est un processus enfant qui parle JSON-RPC sur stdin et stdout. Claude Desktop, Cursor et Conduit font tous ainsi. Il n’y a rien à déployer au sens cloud. Le client
est le déploiement.
Claude Desktop a nettement simplifié sa part du problème : un serveur local empaqueté en extension
.mcpb s’installe en un clic depuis Settings → Extensions, et un serveur distant s’ajoute
comme connecteur personnalisé. La configuration écrite à la main est désormais la voie de repli pour
tout ce qui n’est pas empaqueté ainsi — un extrait pour
claude_desktop_config.json:
{
"mcpServers": {
"your-product": {
"command": "npx",
"args": ["-y", "@you/mcp-server"]
}
}
}
Vous le collez dans un fil Slack ou un PDF. Le prospect installe Node, installe Claude Desktop (macOS, Windows, et une bêta Linux pour Ubuntu et Debian), trouve le fichier de configuration à un chemin différent selon la plateforme, colle sans casser le JSON, quitte complètement l’application — fermer la fenêtre ne suffit pas — puis la relance. Empaqueter le serveur en extension supprime l’essentiel de tout cela, et si vous le pouvez, faites-le. Ce qu’aucune voie ne supprime, c’est le reste : il se connecte à Anthropic, choisit un modèle qu’il paie, et cherche votre serveur dans une liste d’outils, à l’intérieur de l’application de quelqu’un d’autre.
Si le serveur est distant, la recette change mais pas la forme. Vous publiez une URL Streamable HTTP — Render, Fly.io, FastMCP Cloud, Smithery, un VPS — et le prospect colle that dans un client qui parle MCP distant. L’hébergement répond à « une autre machine peut-elle atteindre ce processus ? ». Il ne répond pas à « un prospect non technique a-t-il une application, un modèle et une raison de l’ouvrir ? ».
Pourquoi « envoie-leur simplement la config » échoue
Le prospect n’est pas développeur
Modifier un fichier JSON dans un dossier Application Support, installer npx, et déboguer ENOENT parce que Windows voulait npx.cmd, c’est un mardi ordinaire pour la personne qui a construit le serveur. Ce n’est pas un premier rendez-vous raisonnable avec un acheteur. Les formats d’extension en un clic ont supprimé l’essentiel de cette peine, et c’est une vraie amélioration — mais un clic reste une étape que vous demandez à un acheteur, dans une application qu’il a d’abord dû installer et où il a dû se connecter, et les étapes qui restent ne dépendent pas de vous.
Votre produit apparaît dans le client d’un concurrent
Quand cela fonctionne, le prospect n’a pas ouvert votre produit. Il a ouvert Claude, ou ChatGPT, ou Cursor. Vos outils sont une ligne sous la marque d’un autre, dans la fenêtre d’un autre, à côté de tout ce qu’il avait déjà connecté. Vous avez dépensé le budget de la démo dans le tunnel d’accueil d’une autre entreprise. Il se souviendra de l’assistant qu’il paie déjà, pas du connecteur que vous lui avez demandé de coller.
Vous ne contrôlez ni le modèle ni le premier écran
Claude Desktop parle à Claude. Vous ne pouvez pas orienter la démo vers un modèle moins cher, vers une instance Ollama locale pour une salle isolée, ni vers le modèle qui appelle bien vos outils. Vous ne pouvez fixer ni le prompt système, ni l’état vide, ni le nom dans la barre de titre. La première chose qu’il voit est le produit d’Anthropic. C’est une mauvaise position si les outils sont le produit.
Les options, comparées
Trois façons de mettre des outils MCP devant un prospect. Héberger le serveur est une colonne à l’intérieur des deux premières lignes, pas une quatrième option — une URL a toujours besoin d’un client.
| Approche | Charge d’installation pour le prospect | La marque de qui | Le modèle de qui | Qui détient la conversation |
|---|---|---|---|---|
| Chat hébergé ou widget | Ouvrir une URL. Friction minimale. | La vôtre, si vous avez construit le frontend. | Celui que vous avez branché côté serveur. | Vous, en général. Vous êtes dans le chemin de la conversation : c’est pourquoi un accord de sous-traitance arrive avant le PoC. |
| Claude Desktop + extension ou connecteur | Installer Claude et se connecter, puis un clic pour une extension .mcpb empaquetée — ou modifier le JSON à la main pour le reste. |
Celle d’Anthropic. | Claude uniquement. | Anthropic. Les conversations vivent sur leurs serveurs, pas sur le disque du prospect, et un connecteur distant personnalisé est atteint depuis le cloud d’Anthropic, pas depuis la machine du prospect. |
| Client desktop qu’il installe | Installer l’application et ajouter votre connecteur dans les Réglages (ou un fichier JSON, selon le client). | Celle du client, sauf si vous le remarquez à vos couleurs. | Les fournisseurs pris en charge par ce client. | Sur sa machine, si le client est local-first et ne fait pas de proxy. Le fournisseur du modèle voit toujours les prompts que vous lui envoyez. |
Choisissez le chat hébergé quand le prospect n’installera jamais de logiciel et que vous acceptez d’être dans le chemin des données. Choisissez Claude Desktop quand il y vit déjà et qu’il suffit de prouver que les outils existent. Choisissez un client desktop quand la démo est le produit : vos outils, un modèle que vous avez choisi, sur une machine que vous n’avez pas à superviser.
Livrer votre propre client à la place
Conduit est un client IA desktop open source. Il parle MCP en stdio local et en streamable HTTP distant, sur Windows, macOS et Linux. Le prospect télécharge un installateur, ajoute une clé de fournisseur (ou le pointe vers Ollama) et ajoute votre serveur sur la page Connecteurs — commande et arguments, ou une URL. Si votre serveur distant est publié dans le registre MCP officiel, il le trouve par son nom et l’ajoute en un clic. Le connecteur s’exécute sur sa machine, pas sur la nôtre.
Si votre serveur est distant et publié dans le registre MCP officiel, , le prospect ne tape rien du tout : il cherche votre produit par son nom sur la page Connecteurs et l’ajoute en un clic. Conduit filtre le registre sur les serveurs qui publient un accès distant en streamable HTTP, et refuse les entrées uniquement SSE en indiquant pourquoi, plutôt que d’échouer plus tard. Si le serveur exige une authentification, il parle OAuth 2.1 : le prospect se connecte dans son navigateur, et le jeton est conservé dans le trousseau de son système, jamais dans l’interface et jamais chez vous.
C’est déjà une autre démo que celle de Claude Desktop. Il n’est pas enfermé dans une famille de modèles. Il peut travailler entièrement en local. Un outil demande d’abord, sauf si son serveur le marque en lecture seule. Les conversations restent dans SQLite sur son disque. Les requêtes au modèle partent de sa machine vers le fournisseur qu’il a configuré. Il n’y a aucun serveur Conduit au milieu, et c’est pourquoi utiliser Conduit comme client ne fait pas de you vous, à lui seul, un sous-traitant de cette conversation.
Deux limites, dites clairement. Premièrement, il installe toujours Conduit , sauf si vous changez le nom dans Réglages → Marque sur cette copie, ou si vous compilez un OEM packagé depuis les sources. Deuxièmement, si votre serveur n’est pas dans le registre, il saisit lui-même le connecteur, et dans tous les cas le build n’arrive pas déjà pointé dessus — cette couche d’empaquetage n’est pas aujourd’hui un installateur téléchargeable. La page marque blanche est le programme pour ceux qui ont besoin des deux. Cette page décrit le problème de distribution que ce programme existe pour résoudre.
Ce qui est livré aujourd’hui
Le même statut que le tableau marque blanche, réduit à ce dont une démo a réellement besoin.
| Capacité | Statut |
|---|---|
| Client desktop sur Windows, macOS et Linux | Livré |
| MCP en stdio local et streamable HTTP distant, avec consentement | Livré |
| Ajouter un connecteur dans les Réglages — sans fichier JSON | Livré |
| 17 fournisseurs, dont Ollama et LM Studio | Livré |
| Stockage local d’abord, votre propre clé, sans proxy | Livré |
| Marque à l’exécution — Réglages → Marque | Livré |
| Installateurs non signés sur GitHub | Livré |
Installateur OEM packagé depuis brand.md | Accès anticipé depuis les sources |
| Build déjà branché sur vos connecteurs | En développement |
| Builds signés et notariés au niveau du système | En développement |
Les installateurs ne sont pas signés au niveau du système, donc Windows SmartScreen et macOS Gatekeeper avertissent au premier lancement. Dites-le au prospect avant qu’il ne clique, ou compilez depuis les sources avec lui. Les détails sont dans la documentation d’installation.
Questions
Puis-je distribuer un serveur MCP sans demander aux utilisateurs de modifier du JSON ?
Oui. Dans Conduit, les serveurs MCP s’ajoutent sur la page Connecteurs : une commande et des arguments pour un serveur stdio local, ou une URL pour un serveur distant en streamable HTTP. Mieux : si votre serveur distant est publié dans le registre MCP officiel, le prospect le cherche par son nom et l’ajoute en un clic, sans taper la moindre URL, et se connecte via OAuth si nécessaire. Ce qui n’existe toujours pas, c’est un build qui arrive avec votre connecteur déjà branché : c’est la couche d’empaquetage, et elle est en développement.
Existe-t-il une alternative à Claude Desktop qui prend en charge MCP sur Windows ?
Plusieurs clients desktop parlent MCP sur Windows. Claude Desktop est le client de référence et ne parle qu’aux modèles d’Anthropic. Conduit est une alternative open source qui fonctionne sur Windows, macOS et Linux, se connecte à 17 fournisseurs dont Ollama et LM Studio en local, et parle MCP en stdio local et en streamable HTTP distant. Les installateurs ne sont pas encore signés au niveau du système, donc SmartScreen avertira au premier lancement.
Puis-je livrer un client MCP sous ma propre marque ?
En partie. Conduit peut aujourd’hui être renommé, doté d’un autre logo et recoloré dans Réglages → Marque sur une installation standard. Les installateurs OEM packagés sont en accès anticipé depuis les sources pour les partenaires de conception. Livrer un build déjà connecté à vos serveurs MCP est en développement — vous ne pouvez pas télécharger depuis GitHub un installateur à votre marque et déjà branché.
Ai-je besoin d’un accord de sous-traitance pour présenter un serveur MCP ?
Cela dépend d’où vont la conversation et les appels d’outils. Une démo de chat hébergé qui stocke les prompts sur vos serveurs fait généralement de vous un sous-traitant de cette conversation. Un client desktop local-first garde la conversation sur la machine du prospect et envoie les requêtes au modèle depuis cette machine vers le fournisseur ; Conduit n’est pas dans ce chemin. Si votre serveur MCP est lui-même un service hébergé qui reçoit des arguments d’outils, ce chemin est distinct et peut encore exiger un accord. Ceci n’est pas un conseil juridique.
Héberger mon serveur MCP revient-il à le mettre devant un client ?
Non. L’hébergement publie une URL Streamable HTTP que d’autres clients MCP peuvent appeler. Le mettre devant un client, c’est le problème du client : il lui faut encore une application qui parle MCP, un modèle et un premier écran. Une URL publique sans client est un connecteur sans personne à connecter.
Si la démo ne fonctionne que sous forme de build à votre marque et déjà branché, lisez le statut de la marque blanche and ouvrez un fil de partenariat de conception.