cli-printing-press: Generating Go CLIs and MCP Servers from API Docs

The gap cli-printing-press fills: agent-hostile API wrappers

Most API wrappers are written for humans reading documentation. An agent pays for every wrong turn in tokens, and the README frames the whole project around that cost: "A well-designed CLI is muscle memory for an agent: no hunting through docs, no wrong turns, no wasted tokens." The target user is someone running an agent session who wants a command surface the model can guess correctly on the first try.

The project's own examples show the shape of the intended output. The ESPN CLI was built from a sniffed API with no official documentation, and answers a compound question about tonight's playoff games, live scores, series state, leading scorers, and injury news in one call. flight-goat stitches a Kayak nonstop search together with a sniffed Google Flights source. linear-pp-cli is quoted at 50ms against a local SQLite mirror and answers a query the upstream API cannot express: every blocked issue whose blocker has been stuck for a week.

That last example is the clearest statement of intent. The generator is not trying to mirror an API one endpoint at a time. It is trying to produce commands that answer questions the raw API has no route for, backed by a local copy of the data.

How the generator works: docs in, Go CLI and MCP server out

The pipeline starts from either an API name or a URL. The README shows both forms, `/printing-press Notion` and `/printing-press https://postman.com/explore`, and notes that the second needs no spec. Under the hood the generator reads official API documentation, studies popular community CLIs and MCP servers, and sniffs sites that never published an API.

The dependency list in go.mod is the most concrete evidence of how that research stage is built. chromedp v0.15.1 and cdproto are present, which points at browser automation for the sniffing path. kin-openapi v0.137.0 handles spec parsing. dave/dst and dave/jennifer appear together, which is the signature of a tool that generates and rewrites Go source rather than emitting text templates. enetx/surf, with its http, http2, and http3 companions, covers the HTTP client side. go-keychain v0.0.1 suggests credentials are read from the OS keychain rather than a plaintext file.

The output is described as a token-efficient Go CLI plus a Claude Code skill plus an MCP server. The local SQLite mirror and offline search are named in the repository description as part of the generated result, which is what makes the compound-query examples possible: the CLI is not just a thin HTTP shim, it carries a synced local store.

The generator itself is a single binary, `cli-printing-press`, and the README notes that older releases shipped it as `printing-press`. That legacy entrypoint still works, but the canonical name changed so the public library installer can own `printing-press list`, `printing-press search`, and `printing-press install`. If you find an older tutorial using the old name, that is why.

Installing cli-printing-press and printing your first CLI

The README is explicit that you need two things: the binary and the skills. The binary alone does research, generation, verification, and scoring, but skips the curated agent loop. The skills alone have nothing to call. Prerequisites are Go 1.26.6 or newer, Claude Code or another skills-supported agent, and Node/npm for npx.

The one-line installer runs `go install` for the generator and then refreshes the skills through the skills CLI. Restart or reload your agent session afterward so the refreshed skill text is loaded.

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash

If you only want one side, the installer takes flags. `--cli-only` skips the skills refresh, and `--skills-only` skips the binary. Codex users pass `--agent codex`; Claude Code is the default target.

curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --cli-only
curl -fsSL https://raw.githubusercontent.com/mvanhorn/cli-printing-press/main/scripts/install.sh | bash -s -- --skills-only --agent codex

Verify the binary landed before you open an agent session. If install fails, the README points at three causes: Go older than 1.26.6, missing Node/npm for npx, or `$GOPATH/bin` not on your PATH.

cli-printing-press --version

Then start Claude Code from any folder and invoke the skill with an API name or a URL. The reprint variant regenerates an existing CLI against the current generator.

/printing-press Notion
/printing-press https://postman.com/explore
/printing-press-reprint notion

The manual path, if you would rather not pipe a script into bash, is a direct go install plus the skills CLI. The skills package is installed globally for the named agent.

go install github.com/mvanhorn/cli-printing-press/v4/cmd/cli-printing-press@latest
npx -y skills@latest add mvanhorn/cli-printing-press/skills --skill '*' -g -a claude-code -y

If you are editing the Printing Press itself rather than using it, the developer path clones the repo and loads its skills directly with `claude --plugin-dir .`, optionally with `-w` for a new git worktree so parallel runs do not collide.

Where the Printing Press is the wrong tool

The installer is a curl-to-bash script that runs `go install` and then mutates your global agent skill directory. That is a large blast radius for a tool you are evaluating. The `--cli-only` and `--skills-only` flags exist precisely because some people want to inspect one half before letting the other touch their setup, and you should use them if you are not already comfortable with global skill installs.

The sniffing path is the other real constraint. The ESPN and Google Flights examples are built from undocumented endpoints discovered by watching a site's own traffic. That works technically, and the project is open about it. It is also the part most likely to break without warning, because there is no published contract to hold the generated CLI to. A sniffed CLI can stop returning data after a frontend deploy, and nothing in the generator can tell you in advance.

There is also a hard platform floor: Go 1.26.6 or newer. That is a recent toolchain, and it will rule out the Printing Press on machines pinned to an older Go for other projects. The README lists this as a prerequisite, not a suggestion.

Finally, the skills are tested with Claude Code, and Codex support is described as something to try with `--agent codex`. The README's own wording, "Use Claude Code for the best-tested experience," is a fair summary: if you are on a different agent, you are on the less-travelled path. Cursor users get a separate doc, docs/CURSOR.md, which covers installing a printed CLI, attaching the matching skill, handling auth, and choosing CLI versus MCP when the repo does not already document a workflow.

How this differs from writing an OpenAPI-generated client

The closest conventional alternative is an OpenAPI generator, which takes a spec and emits typed client code in your language of choice. The difference in approach is what each one optimizes for. An OpenAPI generator assumes the spec is complete and correct, and produces a method per endpoint for a human developer to call from application code.

The Printing Press assumes the spec is incomplete. It studies community CLIs and MCP servers for the same API, sniffs sites that published nothing, and then emits a command surface plus a local SQLite mirror plus an MCP server. The output is not a library you import; it is a program an agent invokes, and the compound-query examples only work because of the local store. An OpenAPI client cannot answer "every blocked issue whose blocker has been stuck for a week" without you writing that aggregation yourself.

The cost of that ambition is predictability. An OpenAPI client is reproducible from a spec you can diff. A printed CLI depends on a research and generation stage whose inputs include live websites, so two runs against the same target are not guaranteed to produce identical code. That is why the project ships a reprint command, `/printing-press-reprint notion`, and a UPGRADE_LOG.md at the repository root. Regeneration is treated as routine maintenance, not a one-time event.

Maintenance cost, release cadence, and the MIT licence

The repository is not archived, and the last push was on 2026-08-28. Releases are frequent and versioned in a v4.31.x line, with v4.31.0 on 2026-08-18, v4.31.1 on 2026-08-19, and v4.31.2 on 2026-08-28. The presence of release-please-config.json and .release-please-manifest.json at the root indicates automated release management. There is also a supported-versions.txt file and an UPGRADE_LOG.md, which together suggest the project tracks which generator versions produced which CLIs.

That cadence has a practical consequence. A CLI you print today is generated by a specific version of the generator, and the reprint command exists because the generator keeps improving. Budget for periodic regeneration rather than treating the printed CLI as frozen. The UPGRADE_LOG.md is the file to read when deciding whether a reprint is worth the churn.

On licensing: the project is MIT. That is permissive, so generated output and the generator itself can generally be used and redistributed with the licence notice. This is not legal advice, and it does not settle the separate question of what the API or website you are targeting permits. Sniffing an undocumented endpoint is a technical capability, not a permission, and the MIT licence on this repository says nothing about the terms of the service you point it at.

Editorial conclusion

Adopt it if you drive Claude Code or Codex daily and want a repeatable way to turn an API or a website into a CLI plus an MCP server without hand-writing the wrapper. Skip it if you need a single hand-tuned CLI for one API, if you cannot run Go 1.26.6 or newer and Node/npm, or if your target site's terms do not permit sniffing traffic. Before printing anything, run cli-printing-press --version and npx -y skills@latest list -g -a claude-code to confirm both halves of the install landed, because the binary and the skills fail independently and the skills are the interface you actually type into.

Frequently asked questions

Official sources

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