The A2A project has shipped an official command-line client, and it fills a gap the protocol had since the start. In Introducing the A2A CLI, the pitch is one sentence: “The A2A CLI closes both gaps: a single, standardized way for anything that can run a command — you, a script, or any model or coding harness that calls tools — to reach an A2A agent.” The first gap is that A2A is bidirectional and every client was expected to be an agent. The second is that there was no plain way for a person at a terminal or a CI job to fetch an agent card, send a message, and follow a task. The CLI does all three: a2a card get reads a card, a2a send posts a message, with a streaming flag, and a2a server runs one, either as an echo agent or wrapping a program. It is built on the A2A Go SDK, speaks A2A Protocol v1.0, installs from Homebrew, WinGet, or Go, and is open source under Apache 2.0.
There are no numbers to discount, and the design choice worth the post is the --exec mode. “How –exec works: the CLI passes the incoming message on stdin and turns whatever the program prints on stdout into the response.” Then: “That’s the whole contract — any language that can read stdin and write stdout qualifies.” A Python script that has never heard of A2A becomes an agent with a card, a task lifecycle, and streaming, because the CLI holds the protocol and the script holds the logic. The output is built for pipelines, “protocol-native JSON output and predictable exit codes,” with exit zero meaning the task completed. And it is transport-complete: JSON-RPC, REST, and gRPC out of the box, with custom transports as plugins. For a protocol whose adoption question has been who can call an agent that is not itself an agent, this is the answer.
The catalog does not hold the A2A project as a provider, but it holds the protocol’s footprint, and I ran the CLI against it. The A2A tag covers 441 providers and 194 APIs, with a composite of 36.3 and a rising trend, and the cohort is the most agent-shaped on the site: 71.4% of its members publish an agent card against 0.1% of the rest of the catalog, 82.3% run an MCP server against 10.7%, and the mean Agent Readiness score is 39.2 against 10.0. The tag page ranks APIs.io itself second at 90.6, agent-native, with the agent card dimension lit. So I pointed the new client at our own card. The CLI’s echo server parsed, answered, and returned a completed task. Our card did not: “card parsing failed: expected exactly one OAuth flow, got 2.” The card declares protocol version 0.3 and an OAuth2 scheme carrying both an authorization-code and a client-credentials flow, and the 1.0 client wants one flow per scheme.
That is the honest reading of this release from where the catalog sits. The CLI makes a card the single thing an agent, a script, or a person needs to find, and it enforces the 1.0 shape of that card strictly enough to reject one that the catalog had been counting as present. A lit dimension and a readable card are not the same fact. The fix on our side is small, two security schemes with one flow each and a version bump, and it is filed. One more thing for anyone trying the CLI today: it loads a .env file from the working directory on startup, and when it cannot parse one, its error message prints the whole file. Run it from a clean directory. The CLI is a real step for A2A. The first thing it did for us was show that our own door was built to the previous draft.