layerx-mcp : initiation au serveur MCP pour connecter l'agent LayerX de Paxeer X

Pour qui

• Pour les développeurs souhaitant intégrer des capacités d'agent dans l'écosystème Paxeer X Network : ce dépôt est le monorepo de ce réseau, comprenant la chaîne Paxeer X (paxd, Go, chaîne EVM avec l'ID 125) et le noyau LayerX (layerxd, C17, un domaine d'exécution déterministe et de comptabilité destiné aux agents autonomes), ainsi qu'un serveur MCP situé dans services/agent/crates/layerx-mcp, et des SDK Rust, Python et TypeScript.
• Pour ceux qui disposent déjà d'un environnement de développement prêt pour une compilation depuis les sources : la toolchain requise officiellement comprend Go 1.25.8 (go.mod), un compilateur C17 pour le noyau, Rust 1.91.1 (rust-toolchain.toml), Solidity 0.8.27 et Foundry, ainsi que Node.js (espaces de travail npm).
• Pas adapté à ceux qui veulent simplement installer un paquet MCP autonome sans compilation locale : les preuves ne mentionnent aucun binaire précompilé ni service hébergé. Concernant le déploiement on-chain, la garde d'actifs et autres opérations, la documentation officielle précise clairement que la réussite de l'audit en local n'autorise pas ces actions ; au-delà, les limites concrètes des autorisations ne sont pas documentées.

Premier essai en 3 minutes

• Prérequis : préparez la toolchain selon les exigences officielles (Go 1.25.8, compilateur C17, Rust 1.91.1, Node.js, etc.) et clonez le dépôt en local. Voici le chemin le plus direct indiqué dans le README officiel.
• Installation et configuration : le dépôt fournit un CLI développeur sous tools/platform/cli ; la commande layerx install mcp installe le transport MCP (il existe aussi layerx install a2a pour installer le transport A2A, qui reste une méthode secondaire). C'est la voie de configuration principale recommandée officiellement.
• Première vérification à faible risque : depuis la racine du dépôt, lancez make layerxd et make layerxctl pour compiler respectivement le démon du noyau LayerX et son CLI d'exploitation (make paxeer-build compile quant à lui build/paxd). Les artefacts de compilation constituent le premier signal de réussite.
• Signaux de réussite : les artefacts du noyau et du CLI sont générés, et après l'exécution de layerx install mcp, le serveur MCP de LayerX apparaît dans votre client MCP. Attention : les preuves ne fournissent ni liste concrète de sous-commandes du CLI ni exemple d'appel d'outils ; on peut seulement confirmer l'étape « transport installé + compilation réussie ». Pour les détails d'appel plus avancés, référez-vous à la documentation du dépôt, sans deviner les paramètres.
• Rappel : tout ceci relève d'écritures d'état local (artefacts de compilation, configuration locale), pas d'opérations d'écriture distantes ; mais il ne faut pas non plus considérer cela comme « sans risque » — les limites de confidentialité concernant les lectures/écritures locales et les accès réseau ne sont pas documentées.

Cas d'usage

• Cas 1 : installer le transport MCP de l'agent LayerX dans votre client MCP. Exécutez layerx install mcp dans le CLI de tools/platform/cli, puis vérifiez dans le client MCP que vous avez configuré si le serveur apparaît avec sa liste d'outils. Les preuves ne permettent de confirmer que « transport installé, serveur visible » ; les noms d'outils concrets et leurs paramètres ne sont pas listés dans les éléments officiels consultés, fiez-vous donc à la documentation du dépôt et aux sorties réelles.
• Cas 2 : compiler le noyau et la toolchain d'exploitation pour le développement local. Après avoir cloné le dépôt, lancez depuis la racine make layerxd et make layerxctl pour obtenir le démon du noyau LayerX et son CLI d'exploitation ; si vous souhaitez aussi compiler le nœud de la chaîne, lancez make paxeer-build pour obtenir build/paxd. Le résultat attendu est que les commandes de compilation produisent les binaires correspondants. Les actions impliquant un déploiement réel ou des actifs ne rentrent pas dans ce périmètre.

Limites d'utilisation

• La compilation et la configuration locale sont des écritures d'état local ; make public-audit (c'est-à-dire scripts/ci/public-repo-audit.sh) est une vérification obligatoire à chaque modification, mais la documentation officielle précise clairement : réussir l'audit en local ne vaut pas autorisation de déployer des contrats, de transférer des actifs en garde ni de manipuler des actifs réels — toute écriture distante de ce type nécessite un processus de confirmation officiel supplémentaire, dont les détails ne sont pas fournis dans les preuves.
• Les exigences de configuration concernant les identifiants, portefeuilles et clés API ne sont pas documentées dans les éléments consultés ; ne fournissez pas d'informations sensibles lors du premier essai. En cas de besoin réel, référez-vous à la documentation officielle.
• Informations clés non confirmées : la liste concrète des outils exposés par le serveur MCP et leurs paramètres, les ports d'exécution, la compatibilité avec les clients, ainsi que les limites de confidentialité et d'accès réseau des outils en lecture seule — aucune de ces informations n'apparaît dans les preuves ; vérifiez-les directement dans la documentation du dépôt avant usage.
• Même si des outils en lecture seule de type readOnlyHint existent, cela signifie seulement qu'ils n'effectuent pas d'opérations d'écriture, pas qu'ils n'accèdent pas au réseau ni ne lisent des données locales ; on ne peut pas en tirer une conclusion de sécurité globale.