This is the version to keep within reach. Open it the moment you want to connect Claude Code to some tool and you're torn between CLI, API, and MCP. Everything below comes from the Printing Press article — no new commands or numbers beyond it.
The guiding rule in one sentence: before you connect a tool through MCP, check whether a command can do the job instead.
Three concepts everything revolves around
| Concept | What it is | What reaches the model |
|---|---|---|
| CLI (command line interface) | Running a program by typing a command instead of clicking through a UI | A short, ready summary — the heavy lifting happens locally |
| API (application programming interface) | The technical way one program asks another for data | A large, raw payload — often more than you need at that moment |
| MCP (Model Context Protocol) | A newer standard for connecting tools to AI models | A list of every function with descriptions — it takes up memory in every session, even when you don't use the functions |
Two concepts that keep showing up in the cost math:
- Token — the chunk of text the model operates on (roughly a piece of a word). You pay for tokens, and usage is measured in them.
- Context window — the amount of text the model "sees" at once: instructions, files, the conversation so far. The more unnecessary data lands in it, the faster it fills up and the more the session costs.
Why CLI beats API and MCP
The core of the difference is what actually reaches the context window.
- APIs were built for code, not for agents paying for every token — hence the raw, bloated responses, plus the occasional headache with login or pagination.
- MCP solved tool discovery (the agent sees the full list of functions right away), but at the cost of a constant memory load from every function's description.
- CLI is local, fast, returns ready, short text, and lets you chain commands together.
From one test cited in the article: on the same task, MCP used thirty-five times more tokens than CLI, and reliability dropped from one hundred percent with CLI to seventy-two percent with MCP as the tasks got harder. That's a single benchmark, not a universal rule — but the gap is clear.
Example from the article: pulling the ten latest posts from a platform with no official connector transferred over 130,000 tokens of data, but only about 2,000 of them reached Claude's memory — a clean summary instead of a raw pile of information.
What Printing Press is
Two things at once:
- A library of ready-made CLIs — around fifty commands, covering things like sports scores, flight search, recipes, and shopping sites.
- A factory that helps you build your own CLI — for practically any tool.
The most interesting promise: most sites don't offer a convenient API, and some are actively hardened against automated scraping. Printing Press still lets you build a CLI for them — it studies how the site works and reconstructs the commands it needs. Building one command usually takes about ten minutes.
How to set it up and build your own CLI
| Step | What you do | Detail from the article |
|---|---|---|
| Install | Give Claude Code the Printing Press site addresses and ask it to install | The ready starter set and the factory — without the factory you can't create new commands |
| Technical requirement | Install Go | A free, open language from Google, good for command-line tools; you can hand the install to Claude Code too — it takes about a minute |
| Build the command | Describe what you need in plain language | For example, "build a command that pulls articles from this site" |
| The rest happens on its own | Claude Code studies the site, checks its functions, generates the CLI, and tests it | — |
A good candidate for your first command: something you use often that has no good API.
Two limits worth remembering
- Login credentials don't go into the CLI script. Keys, access tokens, and passwords go into a separate, private config file — exactly as with an API. That means the finished command can be safely packaged into a repository and shared with the team: each person drops in their own key.
- A CLI doesn't get around the service's limits. If a service allows a set number of operations per day, that limit still applies through the CLI. The tool changes how you talk to the service, not the rules on the other end.
What this buys you day to day
Working through commands instead of raw APIs and memory-hungry MCP servers means, for someone working with Claude Code:
- fewer tokens spent on every request,
- a cleaner context window,
- more predictable behavior on harder tasks.
The value of Printing Press isn't that a single command does more than the API for the same service — it's that almost any tool can be turned into a CLI.
Where to start
The order to choose in, when you want Claude Code to talk to some tool:
- Check whether a ready-made CLI exists. If it does, take it and stop there.
- If there's no CLI but there is an API, build a CLI from the API. It's almost always possible — this is where the Printing Press factory comes in.
- If there's neither a CLI nor an API, let Printing Press study the site and reconstruct the commands. That's how a CLI gets built even for tools with no official connector.
- Leave MCP for last — for when none of the above paths work.