Si vous avez passé un peu de temps autour des coding agents au cours de la dernière année, vous avez probablement croisé trois lettres qui reviennent sans cesse : MCP. Les gens parlent de « MCP servers », de « MCP tools » et de « connecter Claude via MCP » comme si tout le monde savait déjà ce que cela signifie. La plupart d’entre nous l’ont appris par osmose, n’ont jamais eu la réponse claire, et ont acquiescé discrètement. Voici donc la réponse claire. Qu’est-ce que MCP? MCP, le Model Context Protocol, est une norme ouverte qui permet à un AI agent d’appeler des tools externes et de lire des données externes via une interface commune — au lieu que chaque application invente sa propre intégration sur mesure. C’est toute l’idée. Et pour les Bitcoiners, cela compte parce que MCP est exactement la plomberie qui vous permet de pointer votre propre agent vers votre propre mineur et de le contrôler localement, sans confier les clés à un tableau de bord infonuagique.
Ceci est l’explicatif définitionnel. Si vous voulez le guide pratique pour contrôler du matériel avec un agent, c’est un article distinct. Ici, nous répondons à la question qu’un pleb tape réellement dans une barre de recherche — « what is MCP » — en langage simple, puis nous montrons pourquoi le Model Context Protocol est l’exemple Bitcoin concret qui nous importe : le contrôle DCENT_axe.
Le problème que MCP résout
Un modèle de langage à lui seul est une boîte de texte très intelligente. Il peut raisonner, résumer et écrire du code, mais il ne peut rien faire dans le monde réel — il ne peut pas lire vos fichiers, appeler une API, interroger une base de données, ni redémarrer un hashboard. Pour rendre un modèle utile, il faut lui donner des mains. Le terme de l’industrie pour ces mains est le « tool calling » : le modèle émet une requête structurée (« appeler get_miner_status avec ces arguments »), un morceau de logiciel exécute réellement cette requête, et le résultat est renvoyé au modèle.
Le problème, c’est que, jusqu’à récemment, chaque intégration de tool était un cas unique. Si vous vouliez que Claude lise votre Notion, quelqu’un écrivait un pont Claude-vers-Notion. Si vous vouliez qu’un autre agent lise le même Notion, quelqu’un réécrivait ce pont depuis zéro. Multipliez cela par chaque modèle, chaque application et chaque source de données, et vous obtenez le classique chaos d’intégration N-fois-M — une explosion combinatoire de code-colle que personne ne veut maintenir.
MCP réduit ce chaos à un seul contrat réutilisable. Construisez un MCP server pour un tool, et n’importe quel agent compatible MCP peut l’utiliser. Intégrez un MCP client dans un agent, et il peut parler à n’importe quel MCP server. C’est le même tour que le Web a joué avec HTTP et le même tour que USB a joué avec le port sur le côté de votre ordinateur portable : s’entendre une fois sur une interface, et l’écosystème arrête de ressouder des connecteurs.
Model Context Protocol expliqué : comment cela fonctionne réellement
MCP est un protocole client-server. Il y a deux rôles, et la nomenclature déroute d’abord les gens, alors il vaut la peine d’être précis :
- MCP host / client — l’application dans laquelle vit l’agent (un coding agent, un client de clavardage, un IDE). Il parle MCP et décide à quels servers se connecter.
- MCP server — un petit programme qui expose des capacités à l’agent. C’est ce qui sait lire un fichier, interroger une API, ou parler à un appareil.
Le server annonce trois types de capacités, et comprendre la différence, c’est déjà comprendre l’essentiel de MCP :
| Primitive | Ce que c’est | Exemple dans le monde du minage |
|---|---|---|
| Tools | Fonctions que l’agent peut appeler pour faire quelque chose (avec des effets de bord) | set_power_profile, restart_hashboard |
| Resources | Données en lecture seule que l’agent peut tirer dans son context | Taux de hachage en direct, températures des puces, journaux d’erreurs |
| Prompts | Modèles de prompt réutilisables que le server offre à l’utilisateur/agent | Parcours « Diagnostiquer un hashboard mort » |
Quand l’agent démarre, il demande à chaque MCP server connecté : « que peux-tu faire? » Le server répond par une description lisible par machine de ses tools, resources et prompts — noms, descriptions, et la forme exacte des arguments que chacun attend. L’agent connaît maintenant le menu. Quand vous lui demandez de faire quelque chose, le modèle décide quel tool convient, remplit les arguments et envoie l’appel. Le server l’exécute et renvoie un résultat structuré. Le modèle lit ce résultat et continue. Cette boucle — découvrir, appeler, lire, continuer — est toute la danse.
Sous le capot, MCP utilise des messages JSON-RPC et peut tourner sur un pipe local (le server s’exécute comme un processus sur votre propre machine) ou sur un transport réseau. Le point crucial pour les lecteurs soucieux de souveraineté : un MCP server local tourne sur votre matériel. L’agent lui parle sur votre propre machine ou votre propre LAN. Rien dans le protocole n’oblige la télémétrie de votre mineur à passer par le nuage de quelqu’un d’autre.
Où s’inscrivent Claude MCP et le « agent tool calling »
Vous entendrez souvent « Claude MCP » parce que les clients de Claude ont été parmi les premiers adoptants de la norme, et qu’un coding agent comme Claude Code est un MCP host naturel — il est déjà dans votre terminal, lit déjà vos fichiers, exécute déjà des commandes. Mais MCP n’est délibérément lié ni à un modèle ni à un fournisseur. C’est une spécification ouverte. D’autres agents et clients l’implémentent aussi, ce qui est tout l’enjeu : écrivez le server une fois, et quel que soit l’agent que le pleb préfère l’an prochain, il pourra encore l’utiliser.
Le « agent tool calling » est la capacité générique; MCP est la façon standardisée d’exposer ces tools pour qu’ils soient portables. Pensez au tool calling comme à la capacité et à MCP comme à la norme de connecteur qui vous évite de réécrire cette capacité pour chaque application. Les épaules sur lesquelles cela repose sont réelles : la communauté plus large de l’outillage ouvert et des agents a passé des années à construire de la colle de function-calling sur mesure avant qu’une norme partagée n’émerge, et MCP est la consolidation de ces leçons, pas un éclair venu de nulle part.
Pourquoi cela compte pour les Bitcoiners : l’exemple concret DCENT_axe
C’est ici que l’abstraction justifie son existence. Un mineur Bitcoin — qu’il s’agisse d’un bitaxe sur votre bureau ou d’un Antminer industriel dans le garage — n’est qu’un appareil avec une interface de contrôle. Il rapporte un statut, accepte une configuration et exécute des tâches. C’est précisément le genre de chose qu’un MCP server peut encapsuler. Exposez « lire le taux de hachage » comme resource et « changer le profil de puissance » comme tool, et soudain votre agent peut gérer la machine de la même façon qu’il gère votre code.
C’est l’idée MCP de DCENT_axe : un exemple concret, natif Bitcoin, du Model Context Protocol. Vous lancez un agent local, vous le pointez vers un MCP server qui parle à votre mineur, et vous contrôlez votre propre matériel avec votre propre agent — localement, selon vos conditions. Demandez-lui en langage simple de vérifier votre flotte, de baisser une unité quand les prix du réseau grimpent, ou de tirer la dernière heure de codes d’erreur, et l’agent traduit cela en appels de tools MCP contre votre appareil. Aucun tableau de bord tiers entre vous et votre machine. Aucune télémétrie expédiée vers un SaaS que vous ne contrôlez pas.
C’est le même fil de décentralisation qui traverse tout ce que nous construisons : possédez vos données, possédez votre calcul, possédez votre code, et maintenant possédez aussi la boucle de contrôle. Un MCP server que vous faites tourner vous-même, c’est une couche de plus décentralisée. Pour le flux pratique plus approfondi — brancher un agent à un mineur étape par étape — voir le guide dédié sur le contrôle de votre mineur avec un coding agent, et le portrait plus large dans le guide du pleb sur l’IA auto-hébergée.
MCP local-first : gardez-le sur votre propre fer
La raison pour laquelle cela s’inscrit si proprement dans la pile souveraine, c’est que MCP n’exige pas le nuage. Vous pouvez faire tourner l’agent host sur un modèle local, faire tourner le MCP server sur la même boîte ou sur votre nœud, et garder le tout en air-gap si vous le souhaitez. C’est la différence entre louer votre automatisation et la posséder. Si vous préférez que votre agent ne rappelle jamais la maison, l’approche décrite dans faire tourner des coding agents entièrement hors ligne s’accorde naturellement avec un MCP server local, et faire tourner un agent sur votre nœud Bitcoin montre le même instinct d’auto-hébergement appliqué à un nœud.
MCP se compose aussi avec les autres primitives de l’économie des agents. Un tool MCP peut se placer derrière un paywall Lightning, de sorte qu’un agent paie par appel en sats — nous avons couvert exactement ce modèle dans notre article sur un tool MCP qui paie par appel via L402. C’est MCP comme connecteur et Lightning comme compteur : tools ouverts, monnaie saine, sans intermédiaire.
Un modèle mental rapide pour s’en souvenir
- Tool calling, c’est donner des mains au modèle.
- MCP, c’est la prise murale standard dans laquelle ces mains se branchent, pour que vous câbliez chaque appareil une seule fois.
- Un MCP server, c’est l’adaptateur pour une chose précise — vos fichiers, une API, ou votre mineur.
- Local-first, cela signifie que la prise et l’adaptateur vivent sur votre matériel, pas chez un fournisseur.
Foire aux questions
Que signifie MCP?
MCP signifie Model Context Protocol. C’est une norme ouverte pour connecter des AI agents à des tools et des données externes via une interface commune, afin que le même tool fonctionne d’un agent à l’autre au lieu d’exiger une intégration personnalisée à chaque fois.
Qu’est-ce qu’un MCP server?
Un MCP server est un petit programme qui expose des capacités — tools (actions), resources (données en lecture seule) et prompts (modèles) — à un agent compatible MCP. Vous pouvez en faire tourner un localement sur votre propre machine, ce qui est la façon de laisser un agent lire ou contrôler quelque chose comme votre mineur sans passer par un nuage tiers.
MCP est-il réservé à Claude?
Non. On dit « Claude MCP » parce que les clients Claude ont été des adoptants précoces, mais MCP est une spécification ouverte et neutre quant au fournisseur. D’autres agents et clients l’implémentent aussi, ce qui est tout l’enjeu — vous écrivez un server une fois et n’importe quel agent compatible MCP peut l’utiliser.
Comment MCP se rapporte-t-il au contrôle d’un mineur Bitcoin?
Un mineur est un appareil avec une interface de contrôle, ce qu’un MCP server peut précisément encapsuler. Exposez « lire le taux de hachage » comme resource et « changer le profil de puissance » comme tool, et votre agent peut gérer le matériel en langage simple — localement, sur votre propre machine, sans tableau de bord SaaS au milieu. C’est l’exemple MCP de DCENT_axe.
L’essentiel
MCP n’est pas du battage, et ce n’est pas compliqué une fois le jargon dépouillé : c’est la façon convenue de donner des mains aux AI agents, sous une forme portable d’un agent à l’autre et — crucial pour nous — exécutable sur votre propre matériel. Pour les Bitcoiners, cela transforme « AI agent » d’une nouveauté infonuagique en un outil de souveraineté : votre agent, votre mineur, votre boucle de contrôle, sans intermédiaire.
Nous construisons précisément vers cet avenir au niveau du firmware. DCENT_OS est le premier firmware open-source visant le matériel Antminer industriel — écrit en Rust, visant des frais de dev obligatoires de 0 %, actuellement en bêta active sur l’Antminer S9 avec S19/S21 à venir, GPL-3.0, avec une bêta publique ouverte depuis le 9 juillet 2026. Il est bâti sur les épaules de Braiins OS+, VNish et LuxOS, et c’est le lieu naturel pour qu’un contrôle de mineur ouvert et adapté aux agents s’installe. Si posséder votre boucle de contrôle vous parle, rejoignez la bêta depuis la page DCENT_OS, prenez le web flasher à le flasher de D-Central, et explorez le reste de notre travail sur l’IA locale et la souveraineté dans la section IA de D-Central. Une couche de plus décentralisée — votre code, votre calcul, votre machine.
