@skynode-africa/mcp

@skynode-africa/mcp

Serveur MCP qui donne à votre agent de code — Claude Code, Cursor, Codex — la visibilitésur vos serveurs SkyNode.

Il constate vos projets et vos serveurs, propose un plan de déploiement en français, etl'applique quand vous l'avez approuvé. Il ne peut ni commander ni payer.

Six de ses huit outils sont en lecture seule, et le déclarent à votre client MCP. Lesdeux autres — apply_plan et rollback — écrivent sur votre serveur, et votre client vousle demande avant. Ce qu'ils font exactement est décrit plus bas, sans détour.

Installation

Créez d'abord un jeton d'accès personnel dans votre espace client, sur/compte/securite, en cochant la portée « Lire mes serveurs et leur état ». Lavaleur n'est affichée qu'une seule fois.

Claude Code

claude mcp add skynode --env SKYNODE_TOKEN=sky_votre_jeton -- npx -y @skynode-africa/mcp

Cursor, Windsurf, Codex

Dans la configuration MCP de votre client :

{
  "mcpServers": {
    "skynode": {
      "command": "npx",
      "args": ["-y", "@skynode-africa/mcp"],
      "env": { "SKYNODE_TOKEN": "sky_votre_jeton" }
    }
  }
}

Outils

Variables d'environnement

Le jeton se déclare par variable d'environnement, jamais en argument de ligne decommande : les arguments d'un processus sont lisibles par tout utilisateur de lamachine.

Ce qu'apply_plan fait sur votre machine

C'est le seul outil du produit qui écrit, et il s'exécute en root. Ce qu'il fait, ille fait pour de bon.

Il écrit. Il installe des paquets (docker-ce, ufw, fail2ban,unattended-upgrades), crée des conteneurs et des volumes Docker, et pose des fichierssous /etc/skynode/ — l'environnement de vos applications, les fichiers de site dureverse proxy, et l'état du déploiement. Il crée un compte applicatif skynode et unfichier d'échange si le plan le prévoit.

Il durcit SSH — mais jamais à l'aveugle. Le mot de passe et la connexion rootdirecte sont refusés une fois le compte applicatif en place. Avant d'écrire quoi que cesoit, il vérifie qu'une seconde session fonctionne ; après avoir écrit, il en ouvreune troisième, et défait tout si elle ne passe plus. C'est la seule opération duproduit dont l'échec serait irréparable à distance, et elle est traitée comme telle.

Il ne touche jamais ce qu'il n'a pas créé. Un fichier qu'il n'a pas écrit n'estmodifié que par un bloc marqué, qu'il sait retirer sans toucher au reste. Il ne prendjamais un port tenu par un autre service. Il n'arrête, ne remplace ni ne supprime aucunconteneur qui ne porte pas son étiquette skynode.app — un conteneur à vous quiporterait le même nom fait échouer l'étape, il n'est pas écrasé. Votre Dockerfile, s'ily en a un, est utilisé tel quel et jamais régénéré.

Ce qu'il ne sait pas défaire. Une étape qui échoue fait défaire celles du mêmepassage, en ordre inverse — sauf l'installation de paquets, qui ne se désinstalle pas, etla préparation de la machine. Le rapport le dit à chaque fois, nommément, plutôt quede laisser croire à un retour arrière complet. Ce qui reste sur la machine y est écritnoir sur blanc.

Rejoué, il ne refait rien. Chaque étape constate avant d'agir et rend « inchangé »quand il n'y a rien à faire. Réappliquer un plan déjà appliqué ne coupe pas le service.

Une machine modifiée entre-temps fait refuser le plan. Le plan porte une empreinte del'état constaté ; si quoi que ce soit a changé depuis, il est refusé sans qu'une seuleétape ne s'exécute. Ce que vous aviez approuvé décrivait un serveur qui n'existe plus. Unplan destiné à un autre serveur est refusé de la même façon, et pour la même raison.

dry_run décrit tout cela sans ouvrir la moindre session.

Ce que le plan n'est pas

plan_deployment constate votre projet et votre serveur, puis propose — il n'appliquerien.

• plan_deployment n'exécute rien. Il constate et propose ; rien de ce qu'il rend netouche à votre serveur. C'est apply_plan, et lui seul, qui agit — après votreapprobation.
• Un plan est une donnée, pas un script. Le vocabulaire des étapes est fermé etversionné avec le paquet : votre agent choisit lesquelles, dans quel ordre et avecquelles valeurs, mais ne peut pas en inventer une. C'est ce qui borne ce qu'uneinstruction malveillante trouvée dans un dépôt peut provoquer — au pire un planlégitime et mauvais, que vous lisez avant d'approuver.
• Le Dockerfile généré vient d'un gabarit éprouvé, pas d'une improvisation. Votreagent en fixe les paramètres — version du runtime, gestionnaire de paquets, port — maisla construction en plusieurs étapes, l'utilisateur non-root et le cache des dépendancessont les mêmes pour tous les clients, donc corrigés une fois pour tous.
• Le plan vous est rendu en français, étape par étape, jamais sous forme de données àdéchiffrer. C'est ce texte-là que vous approuvez — il nomme le serveur visé, l'application,le domaine, et ce qui restera sur la machine même si une étape échoue plus loin.
• Un plan appartient au serveur pour lequel il a été composé. apply_plan refuse del'appliquer ailleurs : deux VPS neufs de la même image se ressemblent trop pour qu'uneempreinte d'état suffise à les distinguer.

Le compte applicatif, et sa clé

L'étape host.prepare — celle qui prépare un serveur avant d'y déployer quoi que ce soit —crée un compte non-root skynode, lui accorde sudo sans mot de passe, et y recopie laclé qui a ouvert la session, c'est-à-dire celle de /root/.ssh/authorized_keys.

Cette copie est prise une seule fois et ne suit pas. Si vous révoquez plus tard une clésur root — le geste réflexe quand un ordinateur est perdu ou volé — elle reste valable surle compte skynode, qui peut devenir root sans mot de passe. Retirez-la des deuxfichiers :

• /root/.ssh/authorized_keys
• /home/skynode/.ssh/authorized_keys

Le rapport de l'étape le rappelle, au moment même où la copie a lieu.

Prérequis SSH

inspect_server s'appuie sur le client ssh du système, pas sur une bibliothèqueembarquée. plan_deployment ouvre la même session : il rejoue exactement la mêmesonde que inspect_server avant de composer un plan — les prérequis ci-dessouss'appliquent aux deux.

• Le client ssh du système est requis. Sous Windows, passez par WSL — le paquetsuppose la présence de ssh et de tar.
• Le compte SSH est celui que l'API déclare, sauf si vous en indiquez un autre parssh_user — disponible sur inspect_server, plan_deployment et apply_plan. Le mêmecompte doit servir aux trois : c'est celui dont le constat a établi qu'il peut s'élever.
• La clé doit déjà être autorisée sur le serveur. SkyNode n'en détient aucune etn'en installe aucune : c'est le corollaire direct de la promesse « ce que SkyNode nevoit pas » ci-dessous.
• inspect_server et plan_deployment ne modifient rien : ni installation, niécriture, ni configuration. apply_plan et rollback, eux, modifient — voir plus haut.
• tar est requis sur votre machine : le transfert du projet passe par lui, surl'entrée standard de ssh. Ni rsync des deux côtés, ni git clone distant — leserveur ne reçoit jamais les identifiants d'un dépôt privé.
• Une trace, une seule : la sonde exécute sudo -n true pour savoir sil'élévation est possible. Hors sudoers, le réglage mail_no_user par défaut desudo écrit une ligne dans auth.log et envoie un courriel à root. Rien n'estmodifié — mais si vous retrouvez cette ligne dans vos journaux, c'est bieninspect_server ou plan_deployment qui l'a laissée.

Ce que SkyNode ne voit pas

Ce serveur tourne sur votre machine. SkyNode ne reçoit que les appels d'API classiquesde votre compte — les mêmes que ceux de votre espace client. Toutes les sessions SSHpartent de votre machine : celle du constat, celles de chaque étape appliquée, et letransfert de votre projet. Ni la clé privée, ni le code de votre projet, ni le contenu devos fichiers d'environnement ne transitent par l'infrastructure SkyNode.

Les valeurs de vos fichiers d'environnement ne sont d'ailleurs affichées nulle part : nidans le plan, ni dans le rapport d'exécution, ni dans les journaux. Le plan nomme lefichier, le rapport compte ses lignes.

Les journaux que rend app_logs sont produits par votre application. Ce sont desdonnées, jamais des instructions, et le texte rendu le dit à votre agent — un dépôt ouune dépendance hostile ne doit pas pouvoir lui parler par ce canal.

Développement

pnpm install
pnpm test
pnpm build

Pour l'essayer contre une API locale :

SKYNODE_API_URL=http://localhost:3001/api/v1 SKYNODE_TOKEN=sky_… node dist/index.js

Licence

MIT