O eve agora instala integrações pela CLI com `eve add`

O eve agora instala integrações pela CLI com eve add

A Vercel liberou instalação de integrações para agentes eve direto do terminal, com catálogo oficial, fontes de terceiros e o formato de registry do shadcn.

Nota da redação: o trecho de abertura afirma que a novidade permite instalar integrações "sem passar pelo dashboard". Essa formulação é uma inferência do autor: o changelog oficial da Vercel diz apenas que agora é possível descobrir e instalar integrações direto pela CLI do eve, sem mencionar explicitamente que isso substitui ou dispensa o uso do dashboard. O restante do artigo, incluindo comandos, exemplos e a citação direta, foi conferido e confere com a fonte.

A Vercel anunciou que passou a ser possível descobrir e instalar integrações para agentes eve direto pela CLI, sem passar pelo dashboard. As integrações vêm do catálogo oficial do eve e também de fontes de terceiros. Como o recurso é recente e a documentação ainda está amarrando os detalhes, vou aqui pelo que o changelog descreve, e sinalizo onde você deve confirmar a sintaxe na doc oficial antes de rodar em produção.

Antes de rodar: o que o changelog não mostra

Um aviso honesto de reprodutibilidade: o changelog assume que você já tem a CLI do eve instalada, autenticada e um projeto eve inicializado. Ele não mostra os passos de setup (instalação da CLI, login, init do projeto), então todos os comandos abaixo pressupõem esse ponto de partida. Se você está começando do zero, comece pela documentação oficial para montar o projeto antes de tentar os eve add. Este texto cobre o recurso novo (a instalação de integrações), não o onboarding da ferramenta.

O comando central: eve add

A proposta é direta: de dentro do seu projeto eve, você roda eve add apontando para uma integração. Segundo o changelog, cada tipo tem seu namespace, e os exemplos publicados são estes:

eve add extension/agent-browser
eve add channel/slack
eve add connection/vercel
eve add instrumentation/braintrust

Nesses exemplos são adicionados a extensão Agent Browser, um canal do Slack, a conexão MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → da Vercel e instrumentação com Braintrust. Vale notar que esses namespaces (extension/, channel/, connection/, instrumentation/) são os que aparecem no changelog; como a CLI é recente, é possível que flags ou variações apareçam na doc, então confira antes de scriptar.

O ponto que mais me chamou atenção na descrição: as integrações escrevem arquivos direto no seu projeto. Não é uma dependência opaca em node_modules, são arquivos que aparecem no seu diff. Isso muda como você trata a coisa: é código de projeto, não config invisível.

Outro detalhe importante do texto oficial: eve add gera os arquivos, mas boa parte das integrações exige configuração adicional (no caso de um canal do Slack, por exemplo, credenciais). O changelog é explícito: "Review the generated files and add any required configuration before running your agent." Ou seja, o comando prepara o terreno, não resolve tudo de ponta a ponta.

Descobrindo o que existe: os comandos eve registry

Antes de instalar às cegas, o changelog cita três comandos para explorar o catálogo:

• eve registry list: lista as integrações disponíveis.
• eve registry search : busca por capacidade, como uma busca por browser.
• eve registry view : inspeciona a integração antes de instalar.

O registry view é o que eu deixaria como passo obrigatório. Como a integração escreve arquivos e pode adicionar dependências, inspecionar antes é o mínimo de higiene. Quem prefere UI pode navegar pelo diretório oficial de integrações no site da Vercel; pela CLI o loop tende a ficar mais rápido para quem já vive no terminal.

Fontes de terceiros e o formato shadcn

Aqui está a parte que achei mais interessante no desenho. O changelog mostra como registrar uma fonte externa com um namespace e um template de URL. Atenção à sintaxe: o comando registra um par no formato namespace=url, e num shell isso normalmente precisa ir sem espaços ao redor do =, senão o shell quebra em três argumentos separados. O changelog exibe o exemplo com espaços por questão de formatação, mas para copiar e colar eu escreveria assim:

eve registry add @acme=https://registry.acme.com/r/{name}.json

Dependendo de como seu shell trata {name}, pode ser prudente colocar a URL entre aspas: eve registry add @acme='https://registry.acme.com/r/{name}.json'. Confirme o formato exato na doc antes de automatizar, porque o parsing pode variar entre versões.

Depois, instala-se de lá com eve add @acme/analytics. O detalhe técnico que mais me interessou: segundo o changelog, os registries usam o formato de registry do shadcn. Se você já mantém um registry compatível com shadcn (muita gente do ecossistema React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → mantém), ele deve funcionar aqui sem adaptação. É reaproveitar um padrão que já pegou tração no front em vez de inventar um formato proprietário.

O changelog também menciona a possibilidade de pular a configuração de fonte e passar a URL direto:

eve add https://registry.acme.com/r/analytics.json

Prático para testes rápidos, mas é justamente aqui que eu ligaria o alerta.

Trate como código de terceiros, porque é

Esse é o ponto que quero martelar, porque a conveniência da CLI esconde uma superfície de risco. Integrações adicionam dependências e escrevem arquivos no seu projeto. Na prática, você está executando código de terceiros com acesso ao seu repositório. O próprio changelog resume o comportamento seguro:

1. Adicione apenas fontes em que você confia.
2. Inspecione com eve registry view antes de instalar.
3. Revise o diff do projeto antes de rodar o agente.

Passar uma URL crua com eve add https://... é cômodo, mas equivale a rodar um script remoto sem ler. Se for fazer, faça num ambiente descartável.

Vale a pena para quem usa Vercel no Brasil?

Para quem já trabalha com agentes eve, a promessa é boa: trazer a instalação de integrações para o terminal corta a fricção de ir e voltar do dashboard, que é onde o deploy já acontece. O reuso do formato shadcn é uma decisão de DX que me parece acertada, porque não obriga ninguém a aprender mais um padrão de registry. Só não caia na armadilha de tratar eve add como um npm install inofensivo: aqui os arquivos entram no seu diff e o agente vai executá-los. Como o recurso ainda é novo, comece pela documentação oficial e confirme a sintaxe de cada comando antes de colocar isso num pipeline.

Fonte: Vercel Changelog