eve now installs integrations via the CLI with `eve add`

eve now installs integrations via the CLI with eve add

Vercel has enabled installing integrations for eve agents directly from the terminal, with an official catalog, third-party sources, and shadcn's registry format.

Editor's note: the opening passage states that the new feature allows installing integrations "without going through the dashboard." This phrasing is an inference by the author: Vercel's official changelog only says that it is now possible to discover and install integrations directly via the eve CLI, without explicitly stating that this replaces or removes the need for the dashboard. The rest of the article, including commands, examples, and the direct quote, was checked and matches the source.

Vercel announced that it is now possible to discover and install integrations for eve agents directly via the CLI, without going through the dashboard. The integrations come from eve's official catalog and also from third-party sources. Since the feature is recent and the documentation is still tying up the details, I'm going by what the changelog describes here, and I'll flag where you should confirm the syntax in the official docs before running this in production.

Before you run it: what the changelog doesn't show

An honest reproducibility warning: the changelog assumes you already have the eve CLI installed, authenticated, and an eve project initialized. It doesn't show the setup steps (CLI installation, login, project init), so all the commands below assume that starting point. If you're starting from scratch, begin with the official documentation to set up the project before trying eve add. This piece covers the new feature (installing integrations), not the tool's onboarding.

The core command: eve add

The idea is straightforward: from inside your eve project, you run eve add pointing to an integration. According to the changelog, each type has its own namespace, and the published examples are these:

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

In these examples, the Agent Browser extension, a Slack channel, Vercel's MCP connection, and Braintrust instrumentation are added. It's worth noting that these namespaces (extension/, channel/, connection/, instrumentation/) are the ones that appear in the changelog; since the CLI is recent, flags or variations might show up in the docs, so check before scripting.

The point that caught my attention most in the description: integrations write files directly into your project. It's not an opaque dependency in node_modules, these are files that show up in your diff. That changes how you treat it: it's project code, not invisible config.

Another important detail from the official text: eve add generates the files, but many integrations require additional configuration (in the case of a Slack channel, for example, credentials). The changelog is explicit: "Review the generated files and add any required configuration before running your agent." In other words, the command prepares the ground, it doesn't solve everything end to end.

Discovering what's out there: the eve registry commands

Before installing blindly, the changelog lists three commands for exploring the catalog:

• eve registry list: lists the available integrations.
• eve registry search : searches by capability, like a search for browser.
• eve registry view : inspects the integration before installing it.

registry view is the step I'd make mandatory. Since the integration writes files and can add dependencies, inspecting beforehand is the bare minimum of hygiene. Those who prefer a UI can browse the official integrations directory on Vercel's site; via the CLI the loop tends to be faster for those who already live in the terminal.

Third-party sources and the shadcn format

This is the part I found most interesting in the design. The changelog shows how to register an external source with a namespace and a URL template. Pay attention to the syntax: the command registers a pair in the format namespace=url, and in a shell this usually needs to go without spaces around the =, otherwise the shell breaks it into three separate arguments. The changelog shows the example with spaces for formatting reasons, but to copy and paste I'd write it like this:

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

Depending on how your shell handles {name}, it may be prudent to put the URL in quotes: eve registry add @acme='https://registry.acme.com/r/{name}.json'. Confirm the exact format in the docs before automating, because parsing may vary between versions.

After that, you install from it with eve add @acme/analytics. The technical detail that interested me most: according to the changelog, registries use shadcn's registry format. If you already maintain a shadcn-compatible registry (many people in the React ecosystem do), it should work here without adaptation. It's reusing a pattern that has already gained traction on the front end instead of inventing a proprietary format.

The changelog also mentions the possibility of skipping the source configuration and passing the URL directly:

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

Practical for quick tests, but this is exactly where I'd raise the alarm.

Treat it as third-party code, because it is

This is the point I want to hammer home, because the CLI's convenience hides a risk surface. Integrations add dependencies and write files into your project. In practice, you're running third-party code with access to your repository. The changelog itself sums up the safe behavior:

1. Only add sources you trust.
2. Inspect with eve registry view before installing.
3. Review the project diff before running the agent.

Passing a raw URL with eve add https://... is convenient, but it's equivalent to running a remote script without reading it. If you're going to do it, do it in a disposable environment.

Is it worth it for those using Vercel in Brazil?

For those already working with eve agents, the promise is good: bringing integration installation to the terminal cuts the friction of going back and forth from the dashboard, which is where deployment already happens. Reusing the shadcn format is a DX decision that seems right to me, because it doesn't force anyone to learn yet another registry pattern. Just don't fall into the trap of treating eve add as a harmless npm install: here the files land in your diff and the agent will execute them. Since the feature is still new, start with the official documentation and confirm the syntax of each command before putting this into a pipeline.