layerx-mcp: introducción al MCP server para conectar el agente LayerX de Paxeer X

Para quién es

• Para desarrolladores que quieran incorporar capacidades de agente en el ecosistema de Paxeer X Network: este repositorio es el monorepo de esa red, que incluye la cadena Paxeer X (paxd, Go, EVM chain ID 125) y el núcleo LayerX (layerxd, C17, un dominio de ejecución determinista y contabilidad orientado a agentes autónomos), e incluye además un MCP server en services/agent/crates/layerx-mcp, junto con SDK para Rust, Python y TypeScript.
• Para quien ya tenga preparado un entorno de desarrollo para compilar desde el código fuente: los requisitos de toolchain que figuran oficialmente son Go 1.25.8 (go.mod), un compilador de C17 para el núcleo, Rust 1.91.1 (rust-toolchain.toml), Solidity 0.8.27 con Foundry, y Node.js (npm workspaces).
• No es para usuarios que solo quieran instalar un paquete MCP independiente sin compilar localmente: la evidencia no aporta ningún binario precompilado ni referencia a servicios gestionados. En cuanto al despliegue on-chain, la custodia de activos y otras operaciones, el material oficial aclara explícitamente que pasar la auditoría localmente no autoriza esas acciones; aparte de eso, la evidencia no precisa los límites concretos de permisos.

Primer intento en 3 minutos

• Requisitos previos: prepara el toolchain según lo indicado oficialmente (Go 1.25.8, compilador de C17, Rust 1.91.1, Node.js, etc.) y clona el repositorio en local. Lo siguiente es la vía más directa que ofrece el README oficial.
• Instalación y configuración: el repositorio incluye una CLI de desarrollador en tools/platform/cli, y con layerx install mcp ya puedes instalar el transporte MCP (existe también layerx install a2a para el transporte A2A, que es una vía secundaria). Este paso es la vía de configuración recomendada oficialmente.
• Primera verificación de bajo riesgo: desde la raíz del repositorio, ejecuta make layerxd y make layerxctl para compilar respectivamente el daemon del núcleo LayerX y su CLI de operaciones (make paxeer-build compila build/paxd). Que la compilación genere los artefactos es la primera señal de éxito.
• Señales de éxito: se generan los artefactos del núcleo y de la CLI, y tras completar layerx install mcp aparece el MCP server de LayerX en tu cliente MCP. Ojo: la evidencia no muestra la lista concreta de subcomandos de la CLI ni ejemplos de invocación de herramientas; lo confirmable llega hasta el punto de "transporte instalado + compilación correcta". Para detalles más avanzados de uso, guíate por la documentación del propio repositorio; no inventes parámetros.
• Aviso: todo lo anterior es escritura en estado local (artefactos de compilación, configuración local), no operaciones de escritura remotas; pero tampoco debe tratarse como "cero riesgo": la evidencia no aclara los límites de privacidad en cuanto a lecturas/escrituras locales o acceso a la red.

Casos de uso

• Caso 1: instalar el transporte MCP del agente LayerX en tu cliente MCP. En la CLI de tools/platform/cli, ejecuta layerx install mcp; al terminar, comprueba en el cliente MCP que hayas configurado si aparece ese server y su lista de herramientas. La evidencia solo permite confirmar que "el transporte está instalado y el server aparece"; los nombres concretos de herramientas y sus parámetros no figuran en la evidencia recopilada oficialmente, así que ajústate a la documentación del repositorio y a la salida real.
• Caso 2: compilar el núcleo y el toolchain de operaciones para desarrollo local. Tras clonar el repositorio, ejecuta desde la raíz make layerxd y make layerxctl para obtener el daemon del núcleo LayerX y su CLI de operaciones; si además quieres compilar el nodo de la cadena, ejecuta make paxeer-build para obtener build/paxd. El resultado esperable es que los comandos de compilación produzcan los binarios correspondientes. Quedan fuera de este alcance las acciones que impliquen despliegue real o manejo de activos.

Límites de uso

• Compilar y configurar en local son escrituras en estado local; make public-audit (es decir, scripts/ci/public-repo-audit.sh) es la comprobación que debe pasar en cada cambio, pero lo oficial es claro: pasar la auditoría localmente no equivale a autorización para desplegar contratos, transferir custodia ni manejar activos reales—cualquier operación de escritura remota de ese tipo requiere un proceso de confirmación oficial adicional, cuyos detalles no constan en la evidencia.
• Los requisitos de configuración de credenciales, wallets o API keys no se detallan en la evidencia recopilada; no facilites información sensible por adelantado en el primer intento. Si de verdad es necesario, atente a la documentación oficial.
• Información clave aún sin confirmar: la lista concreta de herramientas y parámetros que expone el MCP server, los puertos de ejecución, el alcance de compatibilidad con clientes, y los límites de privacidad y conexión a la red de las herramientas de solo lectura; nada de ello aparece en la evidencia. Antes de usarlo, verifica directamente la documentación del repositorio.
• Que existan herramientas de solo lectura del tipo readOnlyHint solo indica que no ejecutan operaciones de escritura; no implica que no accedan a la red ni que no lean datos locales. No saques de ahí una conclusión global de seguridad.