MCP

agent-config: unifica skills e regras de governança em várias ferramentas de IA, com endpoint MCP somente leitura auto-hospedado

O agent-config serve melhor a desenvolvedores que querem unificar a configuração de várias ferramentas de IA com um único conjunto de skills e regras de governança e auto-hospedar um endpoint MCP somente leitura; antes é preciso Node ≥ 18, e atenção: o init grava apenas em diretórios globais e o lado do Worker só oferece conteúdo de governança somente leitura.

Official source · event4u-app/agent-config

Install

npx @event4u/agent-config init

O agent-config distribui um conjunto de skills, rules, commands, guidelines e personas via npm e projeta-o na configuração nativa de cada ferramenta de IA compatível, seguindo o padrão aberto Agent Skills; o mesmo conteúdo de governança também pode ser servido a partir do seu próprio Cloudflare Worker como um endpoint MCP. Não é um agent runtime: o loop do agente, o roteamento de LLM e a orquestração de ferramentas permanecem na ferramenta hospedeira. Ele resolve um problema bem concreto — um único conjunto de skills e regras de governança, sem precisar configurá-lo de novo em cada ferramenta.

Para quem é

  • Para desenvolvedores e equipes que alternam entre várias ferramentas de IA e querem manter skills e regras de governança consistentes: a camada de conteúdo se projeta na configuração nativa de ferramentas hospedeiras como Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI e Copilot — mantém-se uma vez, usa-se em todas.
  • Para pessoas e equipes que precisam de um endpoint MCP auto-hospedado: o conteúdo de governança é servido a partir do seu próprio Cloudflare Worker, e qualquer cliente MCP — Claude Desktop, Claude Code, Cursor, Zed, Continue, agentes hospedados, entre outros — acessa via HTTP, sem repetir o conteúdo em cada cliente.
  • Não serve como agent runtime: ele não roda o loop do agente nem assume o roteamento de LLM ou a orquestração de ferramentas; se você procura um serviço que execute tarefas e distribua modelos por você, essas capacidades estão na ferramenta hospedeira.
  • Não serve para quem espera um serviço local pronto ao instalar: o servidor local stdio embutido exige um checkout local e não é de instalar e usar.
  • Requisito: Node ≥ 18; os demais requisitos de sistema não constam da evidência e permanecem sem confirmação.

Sua primeira tentativa em 3 minutos

Há um único caminho principal: o comando de instalação canônico oficial, mais uma verificação dos diretórios globais.

  1. Pré-requisito: Node ≥ 18 instalado na máquina.
  2. Execute no terminal o comando canônico oficial: npx @event4u/agent-config init.
  3. Antes de executar, tenha claros os efeitos colaterais: o init grava apenas em diretórios globais — ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, entre outros; não grava arquivos de projeto, e o project scope fica restrito a mantenedores. É uma gravação de estado local, não um envio remoto; a evidência não descreve como desfazer ou reverter: se o impacto não estiver claro, faça antes backup desses diretórios.
  4. Sinais de sucesso: ao fim do comando, os diretórios globais citados contêm o que foi gravado, e na configuração nativa das ferramentas compatíveis aparecem as skills, rules, commands, guidelines e personas projetadas. Para confirmar antes o alcance, consulte diretamente os arquivos desses diretórios globais.

O caminho de servidor fica como menção secundária: depois de implantar o seu próprio Cloudflare Worker, o conteúdo de governança fica acessível aos clientes como endpoint MCP. A evidência confirma a capacidade, mas não traz comandos de implantação nem trechos de configuração; os passos concretos seguem sem confirmação. É uma ação de configuração remota — não a trate como etapa obrigatória de uma iniciação rápida. No primeiro contato, prefira as pequenas ferramentas somente leitura (como memory_lookup e list_*): “somente leitura” significa apenas que nenhuma operação de escrita é executada; não significa ausência de outros riscos nem permite inferir que não haja acesso à rede ou leitura de dados locais.

Casos de uso

Caso 1: fazer Claude Code e Cursor compartilharem o mesmo conjunto de habilidades e regras. Manter duas configurações separadas tende a gerar divergência. Em uma máquina com Node ≥ 18, execute npx @event4u/agent-config init e deixe que ele grave a camada de conteúdo nos diretórios globais. Resultado esperado dentro da evidência: ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ e outros diretórios recebem gravações, o conteúdo segue o padrão aberto Agent Skills e os arquivos dos seus projetos ficam intactos; daí em diante, as duas ferramentas leem o mesmo conjunto de skills e rules na configuração nativa. Segundo a descrição oficial, a projeção mira cada ferramenta compatível, não apenas as duas do exemplo. Quando seguir este caminho: quando as habilidades e as regras das duas ferramentas evoluírem separadamente e divergirem, e você quiser que um único conteúdo prevaleça. Limitação: ele resolve apenas a distribuição de conteúdo e não executará nenhuma skill por você dentro das ferramentas.

Caso 2: auto-hospedar um endpoint MCP de governança somente leitura. A equipe quer que vários clientes leiam um conteúdo de governança unificado via HTTP, sem instalar nada máquina por máquina. Sirva-o no seu Cloudflare Worker como endpoint MCP: o conteúdo de governança é exposto como MCP prompts e resources — skills, commands, rules, guidelines, contexts — junto com as ferramentas somente leitura memory_lookup, chat_history_read e list_*; clientes MCP como Claude Desktop, Claude Code, Cursor, Zed, Continue e agentes hospedados podem acessar via HTTP. Resultado observável: ao conectar, o cliente vê esse conteúdo nas suas listas de prompts e resources e pode invocar as ferramentas somente leitura citadas. Espere também: o Worker não executa os ~112 scripts Python (linters, audits, task ci, work-engine hooks); esses exigem instalação local conforme o Quickstart. Os passos de implantação do Worker não constam da evidência — confirma-se apenas até a declaração oficial da capacidade.

Limites de uso

  • Natureza leitura/escrita: o lado do Worker é somente leitura — o conteúdo de governança é oferecido como prompts e resources, e as ferramentas se limitam a utilitários pequenos somente leitura como memory_lookup, chat_history_read e list_*; oficialmente não se menciona nenhuma ferramenta de escrita. O init grava localmente e apenas em diretórios globais, sem tocar repositórios de projeto. Ferramentas somente leitura só provam que não executam escritas; se há acesso à rede ou leitura de dados locais, a evidência não diz.
  • Efeitos colaterais e pontos de conferência: o init grava em ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, entre outros; o project scope fica restrito a mantenedores, de modo que uma instalação normal não altera nenhum dos seus repositórios de projeto. A evidência não descreve desfazer nem rollback automáticos, e não enumera os arquivos gravados.
  • Limites oficiais: o Worker não executa os ~112 scripts Python (linters, audits, task ci, work-engine hooks), que exigem instalação local conforme o Quickstart; o servidor local stdio embutido figura na Glama MCP Registry apenas para descoberta e exige checkout local (ver ADR-067).
  • Conferência de caminhos: para distribuir conteúdo às ferramentas, init; para ler o conteúdo de governança via MCP, o Worker; para executar os scripts Python, instalação local conforme o Quickstart e execução por lá.
  • Ainda sem confirmação: comandos de implantação e trechos de configuração do Worker, configuração de conexão de cada cliente e requisitos completos de sistema além do Node ≥ 18. A evidência não cobre nada disso — antes de agir, vale o repositório oficial.