MCP

layerx-mcp: introdução ao MCP server para integrar o agent Paxeer X LayerX

Se você quer integrar localmente, a partir do código-fonte, o MCP server do agent LayerX da Paxeer X, prepare primeiro o toolchain de Go/C17/Rust e instale via a CLI oficial — caso contrário, a etapa de build travará.

Official source · GitHub - Sidiora-Labs/paxeer-monorepo

Install

layerx install mcp

Para quem é adequado

  • Para desenvolvedores que querem integrar capacidades de agent no ecossistema Paxeer X Network: este repositório é o monorepo dessa rede, contendo a chain Paxeer X (paxd, Go, EVM chain ID 125) e o kernel LayerX (layerxd, C17, um domínio de execução e contabilidade determinística voltado a agents autônomos), além de um MCP server localizado em services/agent/crates/layerx-mcp e SDKs em Rust, Python e TypeScript.
  • Para quem já está preparado para montar um ambiente de desenvolvimento com build a partir do código-fonte: os requisitos de toolchain listados oficialmente incluem Go 1.25.8 (go.mod), um compilador C17 exigido pelo kernel, Rust 1.91.1 (rust-toolchain.toml), Solidity 0.8.27 e Foundry, além de Node.js (npm workspaces).
  • Não é adequado para usuários que apenas queiram instalar um pacote MCP independente, sem build local: as evidências não fornecem nenhum binário pré-compilado nem instruções de serviço hospedado. Quanto a operações como deploy on-chain e custódia de ativos, os responsáveis deixam claro que passar a auditoria localmente não autoriza essas ações; além disso, os limites exatos de permissão não são esclarecidos nas evidências.

Primeira tentativa em 3 minutos

  • Pré-requisitos: prepare o toolchain conforme exigido oficialmente (Go 1.25.8, compilador C17, Rust 1.91.1, Node.js etc.) e clone o repositório localmente. O caminho mais direto a seguir é o descrito no README oficial.
  • Instalação e configuração: o repositório oferece uma CLI de desenvolvedor em tools/platform/cli; basta executar layerx install mcp para instalar o transporte MCP (há também layerx install a2a para o transporte A2A, uma via secundária). Esta é a via de configuração recomendada oficialmente.
  • Primeira verificação de baixo risco: a partir da raiz do repositório, execute make layerxd e make layerxctl para construir, respectivamente, o daemon do kernel LayerX e sua CLI de operação (make paxeer-build constrói o build/paxd). O resultado do build é o primeiro sinal de sucesso.
  • Sinais de sucesso: geração dos artefatos de build do kernel e da CLI e, após concluir layerx install mcp, o aparecimento do MCP server da LayerX no seu cliente MCP. Atenção: as evidências não fornecem a lista específica de subcomandos da CLI nem exemplos de chamadas de ferramentas; o que se pode confirmar vai até a etapa "transporte instalado + build concluído". Para detalhes mais avançados de chamadas, consulte a documentação do repositório e não tente adivinhar parâmetros.
  • Lembrete: todas as etapas acima são gravações de estado local (artefatos de compilação, configuração local), não operações de escrita remotas; mas também não devem ser tratadas como "zero risco" — os limites de privacidade quanto a leitura/escrita local e acesso à rede não são esclarecidos nas evidências.

Casos de uso

  • Caso 1: instalar o transporte MCP do agent LayerX no seu cliente MCP. Execute layerx install mcp na CLI de tools/platform/cli; ao concluir, verifique no cliente MCP que você configurou se o server aparece, junto com sua lista de ferramentas. As evidências só permitem confirmar até "transporte instalado, server apareceu"; os nomes específicos das ferramentas e seus parâmetros não foram listados oficialmente nas evidências coletadas — use a documentação do repositório e a saída real como referência.
  • Caso 2: construir o kernel e o toolchain de operação para desenvolvimento local. Após clonar o repositório, execute make layerxd e make layerxctl a partir da raiz para obter o daemon do kernel LayerX e a CLI de operação; se você também quiser construir o nó da chain, execute make paxeer-build para obter o build/paxd. O resultado esperado é que os comandos de build produzam os binários correspondentes. Ações que envolvam deploy real ou ativos ficam fora desse escopo.

Limites de uso

  • O build e a configuração local são gravações de estado local; o make public-audit (ou seja, scripts/ci/public-repo-audit.sh) é uma verificação obrigatória a cada alteração, mas oficialmente: passar a auditoria localmente não equivale a autorização para fazer deploy de contratos, transferir custódia ou manipular ativos reais — qualquer operação de escrita remota desse tipo exige um fluxo adicional de confirmação oficial, cujos detalhes não constam nas evidências.
  • Requisitos de configuração como credenciais, wallets e API keys não são descritos nas evidências coletadas; não forneça informações sensíveis antecipadamente na primeira tentativa. Se for realmente necessário, siga a documentação oficial.
  • Informações-chave ainda não confirmadas: a lista específica de ferramentas expostas pelo MCP server e seus parâmetros, a porta de execução, a faixa de compatibilidade com clientes, e os limites de privacidade e acesso à rede das ferramentas somente leitura — nada disso aparece nas evidências; antes de usar, verifique diretamente na documentação do repositório.
  • Mesmo que ferramentas somente leitura do tipo readOnlyHint existam, isso significa apenas que elas não executam operações de escrita, não que não acessem a rede ou leiam dados locais; não se deve tirar daí uma conclusão geral de segurança.