layerx-mcp: Einstieg in den MCP-Server für den Paxeer X LayerX Agent

Für wen ist das geeignet?

• Für Entwickler, die Agent-Fähigkeiten im Paxeer X Network-Ökosystem anbinden möchten: Dieses Repository ist das Monorepo des Netzwerks und enthält die Paxeer X Chain (paxd, Go, EVM Chain-ID 125) sowie den LayerX-Kern (layerxd, C17, eine deterministische Ausführungs- und Abrechnungsdomäne für autonome Agenten). Dazu kommt ein MCP-Server unter services/agent/crates/layerx-mcp sowie SDKs für Rust, Python und TypeScript.
• Für alle, die eine Entwicklungsumgebung für den Build aus dem Quellcode vorbereiten: Die offiziell genannten Anforderungen an die Toolchain umfassen Go 1.25.8 (go.mod), einen C17-Compiler für den Kern, Rust 1.91.1 (rust-toolchain.toml), Solidity 0.8.27 mit Foundry sowie Node.js (npm workspaces).
• Nicht geeignet für Nutzer, die nur ein eigenständiges MCP-Paket installieren wollen, ohne lokal zu bauen: Es gibt keinerlei Hinweise auf vorkompilierte Binaries oder einen gehosteten Dienst. Für On-Chain-Deployments, Verwahrung von Assets und ähnliche Vorgänge stellt die offizielle Dokumentation klar, dass ein lokal bestandener Audit diese Handlungen nicht autorisiert; darüber hinaus sind die konkreten Berechtigungsgrenzen nicht dokumentiert.

Erster Versuch in 3 Minuten

• Voraussetzung: Die Toolchain gemäß den offiziellen Anforderungen bereitlegen (Go 1.25.8, C17-Compiler, Rust 1.91.1, Node.js usw.) und das Repository lokal klonen. Der folgende Weg ist der direkteste laut offiziellem README.
• Installation und Konfiguration: Das Repository stellt eine Entwickler-CLI unter tools/platform/cli bereit; mit layerx install mcp wird der MCP-Transport installiert (mit layerx install a2a lässt sich alternativ der A2A-Transport installieren, was die nachgeordnete Variante ist). Dieser Schritt ist der offiziell empfohlene Hauptweg zur Konfiguration.
• Erste risikoarme Verifikation: Aus dem Repository-Root make layerxd und make layerxctl ausführen, um den LayerX-Kern-Daemon bzw. seine Bedien-CLI zu bauen (make paxeer-build erzeugt build/paxd). Die Build-Ausgabe ist das erste Erfolgssignal.
• Erfolgssignal: Die Build-Artefakte von Kern und CLI liegen vor, und nach Abschluss von layerx install mcp erscheint der LayerX-MCP-Server im MCP-Client. Hinweis: Die Quellen nennen weder eine konkrete Liste der CLI-Unterbefehle noch Beispiele für Tool-Aufrufe; bestätigt ist der Schritt „Transport installiert + Build erfolgreich“. Für weitergehende Aufrufdetails gilt: die Dokumentation im Repository ist maßgeblich, keine Parameter raten.
• Hinweis: Bei all dem handelt es sich um lokale Zustandsänderungen (Build-Artefakte, lokale Konfiguration), nicht um Remote-Schreibvorgänge; als „risikofrei“ kann man das aber ebenfalls nicht behandeln – die Grenzen hinsichtlich lokaler Lese-/Schreibzugriffe und Netzwerkzugriffen sind in den Quellen nicht dokumentiert.

Anwendungsfälle

• Fall 1: Den MCP-Transport des LayerX-Agenten in Ihren MCP-Client einbinden. Führen Sie in der CLI unter tools/platform/cli den Befehl layerx install mcp aus und prüfen Sie anschließend in Ihrem konfigurierten MCP-Client, ob der Server samt Tool-Liste erscheint. Die Quellen bestätigen nur bis zu dem Punkt „Transport installiert, Server vorhanden“; konkrete Tool-Namen und Parameter listet die offizielle Dokumentation in den erfassten Quellen nicht auf – maßgeblich sind die tatsächlichen Ausgaben der Repository-Dokumentation.
• Fall 2: Kern und Betriebstoolchain für die lokale Entwicklung bauen. Nach dem Klonen des Repositorys aus dem Root-Verzeichnis make layerxd und make layerxctl ausführen; das ergibt den LayerX-Kern-Daemon und die Bedien-CLI. Wer zusätzlich den Chain-Knoten bauen möchte, führt make paxeer-build aus und erhält build/paxd. Zu erwarten ist, dass die Build-Befehle die jeweiligen Binaries erzeugen. Aktionen mit echtem Deployment oder echten Assets fallen nicht in diesen Rahmen.

Grenzen der Nutzung

• Build und lokale Konfiguration sind lokale Zustandsänderungen; make public-audit (also scripts/ci/public-repo-audit.sh) ist eine Prüfung, die bei jeder Änderung bestanden werden muss. Die offizielle Dokumentation stellt jedoch klar: Ein lokal bestandener Audit bedeutet keine Berechtigung, Contracts zu deployen, Verwahrung zu übertragen oder echte Assets zu verarbeiten – für solche Remote-Schreibvorgänge ist ein zusätzlicher offizieller Bestätigungsprozess nötig, dessen Details die Quellen nicht nennen.
• Anforderungen an Zugangsdaten, Wallets oder API-Keys sind in den erfassten Quellen nicht dokumentiert; geben Sie beim ersten Versuch keine sensiblen Informationen vorab an. Wenn sie tatsächlich benötigt werden, ist die offizielle Dokumentation maßgeblich.
• Noch unbestätigte Kernpunkte: Die konkrete Liste der vom MCP-Server bereitgestellten Tools und deren Parameter, der Laufzeit-Port, der Umfang der Client-Kompatibilität sowie die Datenschutz- und Netzwerk-Grenzen der rein lesenden Tools – all das fehlt in den Quellen. Prüfen Sie es vor der Nutzung direkt in der Repository-Dokumentation.
• Auch wenn nur-lesende Tools vom Typ readOnlyHint existieren: Sie bedeuten lediglich, dass keine Schreibvorgänge ausgeführt werden – nicht, dass keine Netzwerkzugriffe stattfinden oder keine lokalen Daten gelesen werden. Daraus lässt sich keine Gesamtaussage zur Sicherheit ableiten.