Install

layerx install mcp

Who this is for

Developers who want to integrate agent capabilities into the Paxeer X Network ecosystem: this repository is the network's monorepo, containing the Paxeer X chain (paxd, Go, EVM chain ID 125) and the LayerX kernel (layerxd, C17, a deterministic execution and accounting domain for autonomous agents), along with an MCP server at services/agent/crates/layerx-mcp and Rust, Python, and TypeScript SDKs.
Developers who are prepared to set up a build-from-source environment: the officially listed toolchain requirements include Go 1.25.8 (go.mod), a C17 compiler for the kernel, Rust 1.91.1 (rust-toolchain.toml), Solidity 0.8.27 and Foundry, and Node.js (npm workspaces).
Not suitable for users who just want to install a standalone MCP package without building locally: the evidence provides no prebuilt binaries or hosted-service documentation. For on-chain deployment, asset custody, and similar operations, the official docs explicitly state that passing the audit locally does not authorize them; beyond that, no evidence describes the specific permission boundaries.

Prerequisites: prepare the toolchain per official requirements (Go 1.25.8, a C17 compiler, Rust 1.91.1, Node.js, etc.) and clone the repository locally. The following is the most direct path given in the official README.
Install and configure: the repository provides a developer CLI under tools/platform/cli; running layerx install mcp installs the MCP transport (there is also layerx install a2a for the A2A transport, a secondary option). This is the officially recommended main configuration path.
First low-risk verification: from the repository root, run make layerxd and make layerxctl to build the LayerX kernel daemon and its operations CLI respectively (make paxeer-build builds build/paxd). The build output is your first success signal.
Success signals: kernel and CLI build artifacts are produced, and after layerx install mcp completes, the LayerX MCP server appears in your MCP client. Note: the evidence does not provide a specific list of CLI subcommands or tool-call examples; what can be confirmed is the "transport installed + build succeeded" step. For deeper call details, rely on the repository's documentation—do not guess parameters.
Reminder: all of the above are local state writes (build artifacts, local configuration), not remote write operations; but don't treat this as "zero risk" either—the privacy boundaries around local reads/writes and network access are not documented in the evidence.

Use case 1: install the LayerX agent's MCP transport into your MCP client. Run layerx install mcp from the CLI under tools/platform/cli, then check whether the server and its tool list appear in your configured MCP client. The evidence only supports confirming "transport installed, server appears"; the official evidence collected does not list specific tool names and parameters—rely on the repository documentation's actual output.
Use case 2: build the kernel and operations toolchain for local development. After cloning the repository, run make layerxd and make layerxctl from the root to get the LayerX kernel daemon and operations CLI; if you also want to build the chain node, run make paxeer-build to get build/paxd. The expected result is that the build commands successfully produce the corresponding binaries. Actions involving real deployment or assets are outside this scope.

Building and local configuration are local state writes; make public-audit (i.e., scripts/ci/public-repo-audit.sh) is a check that must pass for every change, but the official docs are clear: passing the audit locally does not authorize deploying contracts, transferring custody, or handling real assets—any such remote write operation requires an additional official confirmation process, the details of which the evidence does not provide.
Requirements for credentials, wallets, API keys, and similar configuration are not described in the evidence collected; do not provide sensitive information preemptively on your first attempt. If truly needed, follow the official documentation.
Key information not yet confirmed: the specific tool list and parameters exposed by the MCP server, the running port, the range of compatible clients, and the privacy and network-access boundaries of read-only tools—none of these appear in the evidence. Check the repository documentation directly before use.
Even if readOnlyHint-style read-only tools exist, that only means they do not perform write operations; it does not mean they won't access the network or read local data. Do not draw overall security conclusions based on this alone.