The Clay CLI Is an Anti-Pattern: Why GTM Tools Don't Need a CLI

The Clay CLI is an anti-pattern. So is every other CLI a GTM tool ships for agents. A CLI on a GTM tool is not a feature. It's an admission that the vendor built something so complex it can't sit behind an API or an MCP server.

I posted a version of that opinion on Reddit and got good pushback. This is the long version, including the counterarguments, which deserve a real answer. pipe0 ships an MCP server and an API and no CLI, so I have a stake here. Read accordingly.

What the Clay CLI does

Clay released a public API and a CLI on July 9, 2026, on every plan during its open beta. The API is a real step forward.

The CLI is the part I'd skip. You log in with clay login, which stores a session on your machine, and then drive your workspace from the terminal: search Clay's people and company data, read tables, and run workflows, webhooks, and functions. The agent plugin for Claude Code, Codex, and Cursor bundles the CLI with the API, skill files, and Clay's MCP server.

That last part is the odd one. Clay already runs a hosted MCP server that every client connects to over the network. The agent can reach Clay without installing anything. The CLI is extra surface on top of that.

Look at that list again. Apart from reading a file you point it at, every one of those commands is a network call to Clay's servers. None of them needs your shell or anything else a program on your machine gets access to. That's what makes it an anti-pattern: all the risk of a local program, none of the reasons for one.

Deepline, Landbase, Treg, and ZoomInfo are in the same place. Deepline, Treg, and ZoomInfo also offer a remote MCP server and an API, so their CLIs are optional. Landbase leads with its CLI and an install script you pipe into your shell. If the remote options exist, the CLI is extra surface. If they don't, the CLI is the only way in.

What a CLI actually installs

A CLI is a program on your machine. It runs with your user's permissions, so it can read your files, your shell environment, your .env files, and whatever tokens your other tools left lying around.

That is fine as long as the vendor never ships a bad release. In August 2025 someone published malicious versions of Nx, a widely used JavaScript build tool. The install script collected GitHub tokens, SSH keys, and cloud credentials, and even asked the AI coding CLIs already on the machine to help search for more. 2,349 credentials ended up in public repositories. Nx is not a GTM tool, and the people behind it weren't careless. That's the point: every vendor is one compromised release away from this, and with a CLI you're trusting all of them.

Agents make it worse. The Landbase docs suggest asking Claude Code to auto-approve landbase-cli* so it stops prompting for every command. Reasonable for convenience. It also means an agent can run any future version of that program without asking you.

Why vendors build CLIs anyway

The honest reason is instructions. Some tools need megabytes of handbook text before an agent can use them: skill files, playbooks, long command references. Installing that once is cheaper than sending it over the network in every session.

I'd turn that around. If your tool needs a handbook that size, the tool is too complicated. Finding a work email should not require a manual. Make the tool smaller until its description fits in a few lines, and the need for a CLI goes away with the handbook.

Cloud agents won't use your CLI

Grok Bot, ChatGPT, and Claude running in the cloud don't live on your laptop. One reply on Reddit pointed out that you can use the Clay CLI from Grok Bot, and that's true. I wrote "won't", not "can't", on purpose.

A cloud agent can install a CLI into its sandbox. Sandboxes are short-lived, so it has to install it again, keep it updated, and log in again, in an environment you can't see. It works the way a lot of things work: badly, and only if someone babysits it.

A remote MCP server is a URL. The agent connects once and the vendor updates the server without anyone reinstalling anything.

The token argument

The best case for CLIs used to be tokens. Early MCP clients loaded every tool definition into the conversation up front, so a server with fifty tools cost you context before you asked anything. Another commenter said MCP is "very chatty" and a CLI is more token efficient.

That was true for a while. Progressive reveal and on-demand tool discovery fixed it: clients now load a tool's definition when the agent needs it. I don't know of a technical reason an agent should reason more between MCP calls than between shell commands. You can split hairs over small differences either way, but a well-built MCP server and a CLI cost about the same.

The batch argument

The newest case for CLIs comes from ZoomInfo, which ships one too. Henry Schuck, ZoomInfo's CEO, posted the output of an enrichment run on LinkedIn as the answer to "why use the CLI versus an MCP". The agent's summary read: "each batch is a subprocess, so the whole pass cost no conversation tokens and ran in ~2.5 hours. The agent-loop equivalent would have been ~100M tokens."

The numbers are probably right. The conclusion isn't. The savings didn't come from the CLI. They came from the agent not looping through every record in its context window.

What that run needed was an idempotent batch API. The agent writes a small script that calls it in batches and writes the output to a file or a table. That script runs for hours just as efficiently as a CLI subprocess, costs the same zero conversation tokens, and nobody has to install and maintain a binary on their machine.

Agent runtimes are also moving to calling MCP tools from code. Anthropic described the pattern in code execution with MCP: the agent writes code that calls the tools, and the intermediate results never pass through its context. That gives a plain MCP server the same benefit. Both approaches are equally invisible to the user. Only one of them installs a program.

When a CLI is fine

One commenter put it fairly: a CLI can just be a faster interface for people who already live in the terminal. Agreed. A thin CLI over a public API, for a person writing scripts, is a convenience, and nobody gets hurt.

My objection is to the CLI as the main way agents reach a GTM tool. CLIs exist for software that needs system primitives: the file system, processes, the local network. A tool that finds phone numbers and writes rows to a CRM needs none of those.

So here's my position, and I'm sticking to it: no GTM company needs to publish a CLI. Ship a remote MCP server and an API, keep the instructions short, and let the agent connect from wherever it runs.