The most powerful tool you can give Claude Code today isn't another integration, but a way of talking to other programs. I mean Printing Press — a tool that turns any site or service into a CLI. Before I explain what a CLI is, one example shows the point: Claude Code was told "pull the ten newest posts from a given social platform" and pulled them — even though that platform offers no official way to connect. The whole operation moved more than 130,000 tokens of data, but only about two thousand of that reached Claude's memory: a clean summary instead of a raw heap of information.
First, the vocabulary: CLI, API, MCP
Let me start with three terms, because the whole piece revolves around them.
A CLI (command line interface) is a way of using a program by typing a command instead of clicking buttons. It's nothing new — it's how the command-line tools of Google, GitHub or Claude itself work, for instance. For an agent — a program that carries out tasks step by step on its own — it's the most convenient form.
An API (application programming interface) is the technical way one program asks another for data. In response it usually gets a large, raw bundle of information — often far more than is needed at that moment.
MCP (Model Context Protocol) is a newer standard for connecting tools to AI models. Its advantage is that the agent sees the list of available functions right away. Its drawback is that this list, along with the descriptions, takes up room in the model's memory every session, even if you don't use a given function at all.
While we're at it, it's worth recalling two terms that will come back below. A token is a fragment of text the model operates on — roughly a piece of a word; tokens are what you pay for and what usage is measured in. The context window is the amount of text the model "sees" at once: instructions, files, the earlier conversation. The more needless data reaches it, the faster it fills and the more the session costs.
Why a CLI beats an API and MCP
The heart of the difference is what reaches the context window. When an agent goes to an API, it gets the full, raw response — and all of it lands in memory. A CLI works differently: the heavy part of the work happens locally, and a short, finished summary comes back to the model. Hence the two thousand tokens instead of a hundred and thirty thousand in the example at the start.
Let me show you a concrete comparison from one test: on the same task, MCP used thirty-five times more tokens than the CLI, and reliability dropped from one hundred percent with the CLI to seventy-two percent with MCP as the tasks grew harder. It's a single benchmark, not a universal rule — but the difference is clear.
The remaining differences fall into a simple hierarchy. APIs were designed with code in mind, not agents paying for every token — hence the raw, bloated responses and occasional trouble with logging in or splitting results across pages. MCP solved the problem of discovering tools, but at the cost of a constant memory load from the descriptions of every function. A CLI is local, fast, returns finished, short text and lets you chain commands together.
From this follows a simple order of choice when you want Claude Code to talk to a tool. First check whether a CLI exists. If not, but there's an API — you can almost always build a CLI from an API. MCP remains the last option, when there's neither one nor the other.
What Printing Press is
Printing Press is two things at once: a library of ready-made CLIs and a factory that helps you build your own. The tool is fresh — a release from a few days ago. The library already holds around fifty ready-made commands, for sports scores, flight search, recipes and shopping sites, among others. The factory, meanwhile, lets you turn practically any tool into a CLI.
Here lies the most interesting promise. Most of the sites an agent would use offer no convenient API. Some are even protected against automated data fetching. Printing Press lets you build your own CLI for them anyway — for instance, for the social platform from the start of the piece, which offers no official way to connect. The tool studied how it works on its own and reconstructed the commands needed. The whole process usually takes about ten minutes — and to my mind that's exactly where the crux lies: without a factory like this, most of us wouldn't build that CLI at all.
How to get it running and build your own CLI
Getting started is simple: you just give Claude Code the addresses of the Printing Press sites and ask it to install — the ready starter kit and the factory, without which you can't create new commands. One technical prerequisite is Go, a free, open programming language created by Google, well suited to building command-line tools. You can have Claude Code download that too — it takes about a minute.
Building your own CLI comes down to describing in plain language what you need: "build a command that pulls articles from this site," for example. Claude Code studies the site on its own, checks the available functions, then generates the finished CLI and tests it. Think of a program you use often that doesn't have a good API — that's a good candidate for your first command of your own.
Two boundaries matter here. First, login data — keys, access tokens, passwords — doesn't go into the CLI script itself, but into a separate, private configuration file, exactly as with an API. That way the finished command can be safely packed into a repository and shared with the team, with each person supplying their own key. Second, a CLI doesn't get around a service's limits. If a given service allows a certain number of operations a day, that limit holds through the CLI too — the tool changes the way you talk, not the rules on the other side.
What follows from this
The value of Printing Press isn't that a single command does more than the same service's API. It's something broader: the ability to turn almost any tool into a CLI and run all your work through commands instead of through raw APIs and memory-hungry MCP servers. For someone working with Claude Code, that means fewer tokens spent on each query, a cleaner context window and more predictable behavior on harder tasks. Before you connect another tool through MCP, it's worth asking a simple question: couldn't this be handled with a command instead.