CLI Printing Press: Generating Agent-First CLIs by Sniffing APIs and Competing Tools

The Problem: Agents Waste Tokens on Poorly Designed CLIs

AI agents interact with CLIs through text, and every unclear flag or missing command costs tokens and time. The README frames this as the core problem: a well-designed CLI is muscle memory for an agent, so no hunting through docs, no wrong turns, and no wasted tokens. CLI Printing Press aims to solve this by generating CLIs that are token-efficient and agent-native. The target user is a developer building tools for AI agents, or an agent itself that needs to query an API quickly. The project also targets APIs that have no official documentation, like Google Flights or Domino's, by sniffing the web for endpoints. This is a niche but real need: many useful data sources have no public API, and agents cannot easily consume them without a custom wrapper.

How It Works: Docs, Competing Tools, and Sniffing

The generator reads official API docs, studies popular community CLIs and MCP servers, and sniffs the web for undocumented APIs. It then applies a 'power-user playbook' that includes local SQLite storage, compound commands, and agent-native flags. The output is a Go CLI, a Claude Code skill, and an MCP server. The README gives three examples of printed CLIs. ESPN is sniffed because it has no official API, and it returns a compound query like tonight's NBA playoff games with live score, series state, leading scorer's stat line, and injury news from the last 24 hours. flight-goat stitches Kayak nonstop search with sniffed Google Flights data, allowing a query like non-stop flights over 8 hours from Seattle for 4 people, cheapest first. linear-pp-cli queries a local SQLite mirror in 50ms, answering compound queries the API cannot answer directly. The mechanism is not a simple wrapper generator; it fuses multiple sources and adds offline search through SQLite.

Installation and First Use: Binary Plus Skills

You need two components: the generator binary and the Printing Press skills. The skills are slash commands that drive the binary. Install both with a single curl command: `curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash`. This runs `go install` for the binary and refreshes skills through `npx -y skills@latest add --skill '*'`. You can pass `--cli-only` or `--skills-only` to install only one side. For Codex, add `--agent codex`. After installation, start Claude Code and run `/printing-press <app-name>` to generate a CLI, or point it at a website URL. The README also shows a manual install path with `go install github.com/mvanhorn/cli-printing-press/v4/cmd/cli-printing-press@latest` and adding skills via `npx`. The prerequisites are Go 1.26.10 or newer, Claude Code or another skills-supported agent, and Node/npm for npx. The legacy binary name `printing-press` still works, but the canonical command is now `cli-printing-press`.

The Output: Go CLI, Claude Code Skill, MCP Server

Each printed CLI comes with three artifacts. The Go CLI is the primary interface, designed for token efficiency and agent-native flags. The Claude Code skill is the matching skill an agent attaches to use the printed CLI. The MCP server exposes the same functionality to any MCP-compatible client. For the generator itself, the README emphasizes that the binary alone works for research, generation, verification, and scoring, but it skips the curated agent loop. The skills alone have nothing to call. This two-part architecture means you must install both for the intended workflow. The compound commands are a key feature: they combine multiple API calls into a single query, reducing round trips. The local SQLite mirror enables offline search and fast queries, as shown by linear-pp-cli's 50ms response time. This is a significant departure from typical API wrappers, which make live HTTP calls for every query.

Limitations and Risks: Sniffed Endpoints and Agent Dependence

The most obvious limitation is the reliance on sniffed endpoints. The README admits that some APIs, like Google Flights and Domino's, have no published documentation. Sniffing means the generator discovers endpoints by inspecting web traffic or other means, which is fragile. These endpoints can change without notice, breaking the generated CLI. Another limitation is the dependence on a specific agent environment. The skills are tested with Claude Code; Codex is supported through --agent codex, but Claude Code is the best-tested path. If your team uses a different agent, you may have no working skill. Also, the project requires Go 1.26.10 or newer, which is a very recent version. If your environment does not have it, the installer fails. Finally, the generated CLI is only as good as the source material; if the official docs are incomplete, the CLI will be incomplete.

Alternative: Building a CLI with Standard Tools

A direct alternative is to build a CLI manually using standard Go libraries like cobra for command structure and a SQLite driver for local storage. The difference in approach is control. With CLI Printing Press, you get a generated CLI that may include sniffed endpoints and compound commands, but you have no control over the generation logic. With a manual build, you decide every flag, every command, and every data source. The trade-off is time: manual building requires reading API docs, writing handlers, and testing. The README's examples show that the press can stitch multiple sources and add offline search, which would take significant effort to replicate manually. However, a manual CLI is more maintainable because you understand every line of code. The choice depends on whether you value speed of generation over long-term control. For a stable, documented API, a manual CLI might be simpler. For a sniffed or undocumented API, the press is the only practical option.

Maintenance and Upgrade Cost

The project is under active development, with releases v4.34.2 (2026-10-25), v4.35.0 (2026-10-31) and v4.35.1 (2026-11-02). The README mentions a reprint command, `/printing-press-reprint notion`, which regenerates an existing CLI under the latest machine. This suggests a maintenance model where you can update generated CLIs as the generator improves. The legacy binary name `printing-press` still works, but the canonical command is now `cli-printing-press`, so existing scripts may need updating. The skills are refreshed via the installer, which is a low-cost upgrade path. The license is MIT, which allows commercial use and modification, but you should check the license file for any caveats. The repository lists no homepage, but the README points to printingpress.dev for the catalog of printed CLIs; project documentation lives in the README and the docs folder. The maintenance cost is moderate: you need to keep the binary and skills updated, and you must verify that sniffed endpoints still work after any upstream change. The reprint command is a concrete tool for this, but it does not guarantee compatibility.

Editorial conclusion

Adopt CLI Printing Press if you build tools for AI agents and need fast, token-efficient CLIs for APIs that lack official specs or require compound queries. Skip it if you cannot tolerate the risk of sniffed endpoints breaking without notice, or if your team is not ready to run a Go toolchain and manage agent skills. Before adopting, verify the generated CLI's source code for any API you depend on, and confirm that the sniffed endpoints match your expected data. Also check the license and the maintenance history, since sniffed sources can change; the last push was on 2026-11-02. Start with a single low-stakes API, run the installer, and inspect the printed CLI's SQLite schema before building workflows around it.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes