MCP server or CLI: which should you use for Enrich Layer? Both are thin wrappers over the same API: they return the same fields, draw down the same credit balance, and respect the same rate limits, so neither one reaches data the other cannot.
The difference between them is the caller. A language model calls the MCP server, and a shell calls the CLI. So pick by how you're making the call: either from an agent, from your terminal, or from your own application code.
What each one is
The MCP server speaks the Model Context Protocol, the standard that lets a language model discover and call tools on its own. You run it with one command, npx -y @enrichlayer/mcp-server, and point Claude, Cursor, or VS Code at it. The model then has 25 enrichment tools it can call mid-conversation. When an agent decides it needs a work email or a company's headcount, it invokes the tool by name and adds the result straight into its next step. You never write the call yourself.
The CLI is enrichlayer-cli, installed globally with npm install -g enrichlayer-cli and invoked as el. Every command maps to an API endpoint and returns structured JSON to your terminal. It's built for the places a shell already lives: ad-hoc lookups, scripts, cron jobs, and CI pipelines. Output pipes cleanly into jq, into a file, or into the next command in a chain, which is what makes it scriptable.
Both authenticate with the same API key. Neither adds anything to your bill beyond the underlying request.
The use-case matrix
| Use case | Reach for | Why |
|---|---|---|
| Agentic and LLM workflows (Claude, Cursor, in-agent) | MCP | The model discovers tools by schema and invokes them mid-task |
| Interactive terminal or one-off lookup | CLI | One command, JSON back, readable on the spot |
| Shell scripting and automation | CLI | Pipes, exit codes, and files compose through the shell |
| CI pipelines | CLI | Deterministic, scriptable, non-zero exit on failure |
| Bulk enrichment | CLI | Batch mode: pass a file of records, get structured results back |
| Embedded in your product code | The SDK | The Node and Python SDKs are built for in-process calls |
Strengths and tradeoffs
Because both sit on the same API, the differences are about ergonomics, not data.
Authentication. Both use one API key against one account, so they share a single credit balance and a single rate limit. Provisioning one does not change the other. The MCP server reads the key from ENRICH_LAYER_API_KEY; the CLI reads the same key from your environment.
Output. The MCP server returns JSON into the model's context, where the LLM reads it as part of its turn and decides what to do next. The CLI writes JSON to stdout, where you pipe it, redirect it, or read it directly. The fields are the same. In one case the destination is a context window; in the other it is a file descriptor.
Composability. The CLI composes through the shell: pipes, redirects, exit codes, and files. A non-zero exit code fails the CI step instead of letting it pass while enriching nothing. The MCP server composes inside the agent's tool-calling loop, where the model can feed a company lookup into an employee search without you writing the glue between them.
Discoverability. MCP tools carry their own schemas, so an agent reads what each tool expects and picks one without external documentation. You never wire up a specific call in advance: when a task needs a work email, the model finds enrich_work_email in the tool list and invokes it on its own. For a human, the CLI is the discoverable one: el --help and tab completion beat reading a tool manifest.
Runtime footprint. The CLI is a short-lived process. It runs, prints, and exits, which makes it easy to drop into a container or a cron line. The MCP server is a long-lived process your client keeps open for the session. Neither changes per-request latency, since that is the API's work, but the server keeps a process resident for the whole session while the CLI leaves nothing running between calls.
Each interface also has a hard limit. The CLI has no notion of a conversation, so it cannot decide on its own when enrichment is needed; that decision stays with you or your script. The MCP server only speaks to an MCP client, so you cannot pipe its output into awk.
The same lookup, two ways
The contrast is clearest in who drives the call.
With the CLI, you run the command:
# one-off lookup, structured output
el profile https://linkedin.com/in/sarahchen --json
# scripted: enrich a list of domains, append results to a file
cat domains.txt | xargs -I{} el company lookup --domain {} --json >> enriched.jsonl
With MCP, the model runs it because you asked a question:
You: What company does Sarah Chen work at, and how big is it?
Claude: (calls enrich_person_profile, then enrich_employee_count)
Sarah Chen is a Staff Engineer at Acme, which has ~480 employees.
In the first case you chose the command and the arguments. In the second the model chose the tools and the arguments, and you supplied only the intent.
How to choose
Ask these three questions:
- Is a language model deciding when and what to enrich? Use MCP. Letting the agent reach for data on its own is the entire reason the server exists.
- Are you at a terminal, or writing a script, cron job, or CI step? Use the CLI. It's readable when you want to eyeball a result and scriptable, with real exit codes, when you want to automate.
- Are you enriching from inside your own application code? Use the SDK, or call the REST API directly. MCP and the CLI are interfaces for agents and shells; your service should talk to the API in-process.
The pattern underneath all three is to match the interface to the caller: the model reaches for data through MCP, the shell through the CLI, and your application through the SDK. They share one account and one credit balance, so a team can run all three at once, with an agent on MCP inside the IDE, a nightly CI job on the CLI, and a production service on the SDK.
Both interfaces install in a single command. Point your MCP client at npx -y @enrichlayer/mcp-server, or run npm install -g enrichlayer-cli, and start with whichever matches how you are working today. If you do not have a key yet, create an account first.
