Agentic Discovery Moves Into CLI Tools as ARD Spec Gains Backers

The terminal is becoming a discovery layer

Over the past year, AI agents have come to lean heavily on command-line tools. In 2026 the industry has also been arguing over a related question: how an agent finds out which tools exist in the first place. Two developments run side by side. Vendors and open-source projects keep releasing CLIs designed for agents to operate. At the same time, Google and a group of large technology partners have published Agentic Resource Discovery (ARD), an open specification for publishing, finding and verifying agent capabilities across the web2122. Together they point to an architecture where discovery, execution and instructions are separate layers.

The agentic terminal is now a well-documented design. InfoQ describes a common structure across vendors: the tool captures intent, assembles context, plans, executes tools within guardrails, and then shows results or opens pull requests12. It also notes that a ReAct-style agent such as Gemini CLI works well on tasks that involve a lot of discovery, because it loops through thinking, calling a tool and observing the result. Claude Code's plan-and-execute style instead offers the user a checklist to approve first12.

Why CLIs won the execution argument

Practitioners largely agree on why CLIs became the default for execution, and the main reason is token cost. One practitioner estimated that a workflow built on MCP tool schemas used about 145,000 tokens for a 50-device task, with schema injection alone accounting for about 28,0002. Another developer said that replacing an MCP server with a CLI for a simple file conversion cut token use by about 40%3. The reasoning is straightforward. Models already learned tools like git, grep and jq from their training data, so a CLI costs almost nothing to load at startup, and the agent only pulls details through --help when it needs them1.

The enthusiasm has grown into something close to a movement. Developers Digest argues that leading agent tools, including OpenClaw, Claude Code and Codex CLI, chose the command line over new protocols. It reports that OpenClaw has 247,000 GitHub stars and does not use any MCP servers6. Firecrawl's 2026 list of agent-ready CLIs singles out Google's Workspace CLI. Its entire command surface is generated from Google's Discovery Service, so it picks up new API features automatically16. Vendors are also starting to market CLIs as agent products: CockroachDB described its ccloud tool as an "Agent-Ready" database CLI9.

The practical advice for building these tools has become fairly uniform. Recommended features include a --json flag, meaningful exit codes, idempotent commands, and a consistent noun-verb grammar, which together turn exploring a tool into a predictable tree search rather than guesswork18. One enterprise-focused writer argues that the work can be as small as a short AGENTS.md entry that tells the agent a CLI exists and to run --help before trying a new subcommand15.

Discovery is CLI's weak point

The sources mostly agree on what CLIs do badly: they don't announce themselves. Even CLI advocates admit that an agent has to know a tool exists before --help is any use, while MCP's tools/list endpoint gives agents a structured catalog26. MindStudio is the bluntest critic. It calls CLI discovery "manual / hardcoded" and says CLIs are not a practical replacement for MCP in production agent loops5. A second MindStudio analysis says agents cannot query a CLI to learn what it can do, so capabilities have to be defined and managed separately7.

This is the point where the sources split, and the split is partly about deployment context. MindStudio's view that CLI is for development and MCP is for production5 conflicts with the many practitioners who run CLI-first agents in real enterprise work215. Commenters on Reddit offer a middle position: CLI works best for predictable, sequential work, and MCP becomes worth it once an agent is juggling ten or more integrations or needs delegated authentication10.

The more useful reading is that the two camps are converging. A detailed decision framework published this month concludes that a CLI with a well-written skill file beats a bloated MCP server, and that a well-designed MCP server beats a naive CLI wrapper. In its view, design quality matters more than protocol1. It also describes a growing set of tools, including mcpshim, CLIHub and MCPorter, that turn MCP servers into CLIs. These keep MCP's registry and authentication while running calls through the shell1. Microsoft's developer community shows the same idea from the other direction. Its account of mcp-cli describes discovery as a step-by-step dialogue: which servers exist, what parameters a tool takes, then execute. It reports that for 60 tools this cut context use from about 47,000 tokens to about 4008.

The stack that results looks like this: MCP or a registry for discovery and auth, CLIs for execution, and skills as the interface the model reads. One analyst notes that Claude Code already ships in this form1. Developers Digest, despite its anti-MCP stance, reaches nearly the same conclusion: use MCP for auth and discovery, and CLIs for the actual work6.

CLI-Anything builds discovery into the harness

The academic contribution here is CLI-Anything, a June 2026 paper on agent-native computer use. It argues that agents should not have to imitate human perception of graphical interfaces and should instead work through stateful command-line harnesses that wrap existing applications17. The paper treats discoverability as a core requirement of the design: an agent should be able to find, install, read and run an interface from structured metadata17. Its system pairs harnesses with 61 companion skill files and distributes them through CLI-Hub. The catalog lists 65 harness entries and 18 public third-party CLIs17.

The authors acknowledge that CLI-Hub is still partly built for humans. The next version, they say, should offer structured capability search, install plans and a stable schema that agents can query during a task17. Their stated goal is that discovery happens at runtime: the agent asks for a capability, gets candidate interfaces, installs one, loads its skill and carries on17. That is very close to what ARD aims to do across the whole web.

ARD: the missing layer, still unproven

Google announced ARD on June 17, 2026. It defines catalogs hosted on an organization's own domain and federated registries that index those catalogs and answer plain-language intent queries21. Domain ownership is the basis for identity and trust, and publishers can attach verifiable trust metadata before an agent connects2126. Launch partners listed by Google include Cisco, Databricks, GitHub, GoDaddy, Hugging Face, Microsoft, NVIDIA, Salesforce, ServiceNow and Snowflake22. InfoQ reports early implementations in GitHub's Agent Finder in Copilot and Hugging Face's Discover Tool23.

The sources agree that ARD does not replace execution protocols. It hands the agent off to MCP, A2A, OpenAPI or the resource's own interface once a match is found2428. Microsoft's Jennifer Marsman says there will be many discovery services rather than one global catalog, and that ARD does not replace authentication, authorization or governance23.

The sources differ on the details, and those differences matter to anyone implementing the spec. Some explainers describe ARD as coming from a Linux Foundation working group in late May25. Others date it to the June announcement24. One count of supporters includes Amazon27, while Google's own partner list does not22. The biggest difference is technical. A review in October found that ARD v0.91, dated August 26, moved the well-known path to /.well-known/ard.json and now calls ai-catalog.json its predecessor. According to that review, nearly every explainer published between June and August describes the old path28. The spec is still labeled "Proposal," and there is no v1.028.

Adoption is the clearest warning sign. A probe of 39 major domains the day after launch found no discoverable catalogs25. A broader scan cited in October found manifests from only 9 publishers among 37,751 reachable domains, and none of them were fully conformant28. Critics also argue that ARD covers only the registry layer. In their view, training data, web search and environment files such as AGENTS.md often decide which tool an agent picks before it ever checks a registry27.

The takeaway

The overall direction is clear even though the timing is not. CLIs have largely won the argument about how agents should execute tasks, mainly on token cost and the models' existing familiarity with shell tools12. Discovery was CLI's weak spot, and that gap is now being filled from two directions: local skill files and harness catalogs such as CLI-Hub17, and web-scale registries such as ARD21.

For builders, the practical advice is to make CLIs easy for agents to discover through good --help output, skill files and JSON output1815, and to treat ARD as plumbing that may matter later rather than a channel that works today28. The stack described in this coverage, with registries for finding tools, CLIs for running them and skills for explaining them, looks durable. Whether ARD becomes the standard registry depends on adoption figures that are still close to zero.