Printing Press: 6 Things the New CLI Factory Does That MCP Servers Can't
Printing Press gives Claude Code access to 50+ sites with no public API while using 35x fewer tokens than MCP. Here's what it does that MCP simply can't.
A New Tool Just Dropped That Gives Claude Code 50+ CLIs and Uses 35x Fewer Tokens Than MCP
Printing Press launched this week. It’s a CLI factory and library that gives Claude Code access to over 50 pre-built command-line interfaces — ESPN, Craigslist, Amazon, LinkedIn, TikTok Shop, Airbnb, eBay, and more — while using 35x fewer tokens than the equivalent MCP server on the same task. The School CLI demo alone tells you something real: Claude fetched 132,000 tokens of data from School, but only 2,000 tokens entered the context window. That’s not a rounding error. That’s a 66x compression ratio on a site with no public API.
If you’ve been stacking MCP servers into your Claude Code setup and wondering why your sessions burn through tokens before you’ve done anything useful, this is probably why.
The tool lives at printingpress.dev. It has two parts: a library of pre-built CLIs you can pull in immediately, and a factory that uses Claude Code to reverse-engineer any website and generate a working Go CLI for it. You need Go installed first — it’s free, open source, made by Google, and takes about a minute to set up.
Here are the six things Printing Press does that MCP servers simply can’t.
It Gives You 50+ Working CLIs for Sites That Have No Public API
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
This is the core problem Printing Press is solving, and it’s a real one. ESPN has no public API. Craigslist has no public API. All Recipes has anti-scrape protection. Domino’s has no public API. School has no public API. These are sites your agents might legitimately need to interact with, and right now your options are: build something brittle yourself, find an MCP that may or may not exist, or give up.
Printing Press ships with a catalog that covers a lot of ground: Amazon, Craigslist, eBay, TikTok Shop, Shopify, Airbnb, LinkedIn (via Contact Goat), Hacker News, Linear, and more. The starter pack — ESPN, Flight Goat, Movie Goat, Recipe Goat — gets you running in a few minutes. You install the starter pack, install the factory, and Claude Code can immediately start using natural language to invoke these tools.
The ESPN CLI demo is a good illustration of what “working” actually means here. Ask Claude Code what NBA games are on tonight, it invokes the ESPN CLI, and you get back: two games, Knicks vs. Sixers at 7 Eastern, Spurs vs. Timberwolves at 9:30. Clean, correct, fast. No JSON blob. No pagination errors. No authentication dance.
It Compresses Context by Routing Data Through the CLI, Not Through Claude
The School example deserves more attention than a passing mention. When Claude Code used the School CLI to pull 10 recent posts, here’s what actually happened: 260 tokens went out to School, 132,000 tokens came back from School, and 2,000 tokens entered the Claude context window. The other 130,000 tokens were processed and filtered by the CLI before they ever touched the session.
This matters because context pollution is one of the most underappreciated costs in agentic workflows. Every token that enters your context window is a token you’re paying for and a token that’s competing with your actual task. Raw API responses dump everything into context — pagination metadata, nested JSON structures, fields you don’t need, fields you didn’t ask for. The CLI pre-formats the output before it reaches Claude, so what Claude sees is clean, structured, minimal.
If you’re already thinking carefully about token management in Claude Code sessions, this is one of the highest-leverage changes you can make. You’re not just saving tokens on the CLI call itself — you’re protecting every subsequent call in the session from carrying dead weight.
It Benchmarks 35x More Token-Efficient Than MCP, With Better Reliability
The numbers here are specific enough to be worth taking seriously. On the same task, MCP used 35x more tokens than the CLI equivalent. And as task complexity increases, MCP reliability drops from 100% to 72%. The CLI held at 100%.
Why does MCP use so many tokens? Because when you load an MCP server, you’re loading all of its tools and their descriptions into context — even the ones you’re not using. Open a new Claude Code session right now and run /context. If you have MCP servers loaded, you’ll see exactly how many tokens they’re consuming before you’ve done a single thing. That overhead is constant. It’s there whether you invoke the server or not.
Coding agents automate the 5%. Remy runs the 95%.
The bottleneck was never typing the code. It was knowing what to build.
CLIs don’t work that way. They use lazy discovery — the agent only loads what it needs when it needs it. The output is pre-formatted to roughly 200 tokens of clean text rather than a raw JSON payload. There’s no server to keep running. Auth tokens are held by the CLI itself, so you solve that problem once and it stays solved.
The reliability gap is the part that should concern you more than the token cost. A 28% failure rate on harder tasks isn’t a minor inconvenience — it’s the difference between an agent workflow that works and one that requires constant babysitting. If you’re building multi-agent workflows with Claude Code, that reliability delta compounds across every agent in the chain.
The Factory Builds a CLI for Any Website in About 10 Minutes
This is the part that’s genuinely hard to believe until you watch it happen. You point the factory at a website, describe what you want to be able to do, and Claude Code does the rest: researches the site, catalogs every available feature, generates a Go CLI, and then runs what the tool calls “dog food runtime verification and scoring” — it actually tests the CLI it just built before handing it back to you.
The School CLI took about 10 minutes. School has no public API. Claude had to reverse-engineer the endpoints, figure out authentication, understand the data structure, and generate working Go code. The result was a CLI that could fetch posts by category, filter for wins, and return structured results — all from a natural language request.
The Hacker News demo shows the factory process more explicitly. You tell Claude Code you want to pull articles from Hacker News and get daily insights. It responds with a phased plan: research the site, catalog features, generate the Go CLI, verify quality. Hacker News doesn’t require authentication, so that particular demo is straightforward. But the factory handles OAuth, API keys, and authentication cookies the same way you’d handle them with a regular API — you store them securely, and the CLI knows to pull from that storage when it needs them.
One thing worth flagging: the factory’s time estimates are unreliable. It told the demo that building the Hacker News CLI would take 30 to 60 minutes. It took significantly less. Don’t let the estimate discourage you.
CLIs Can Be Packaged, Versioned, and Shared Across Teams
This is the feature that moves Printing Press from a personal productivity tool to something with real organizational value. Once you’ve built a CLI, you can package it into a GitHub repo and share it with your team. Each team member clones the repo and substitutes their own API keys. The CLI logic is shared; the credentials are individual.
The Tally CLI example from the demo makes this concrete. Build the CLI, build a skill around it, push it to a private repo, invite contributors. Anyone on the team can now use the Tally CLI through Claude Code with their own authentication. You’re not emailing around scripts or maintaining separate copies — you have a versioned, shareable tool that works the same way for everyone.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
This is also how the public catalog grows. If you build a CLI for a site that isn’t in the library yet, you can publish it back to the GitHub library at printingpress.dev and other people can pull it in. The catalog is already at 50+; it’ll keep expanding as people build and share.
For teams already thinking about how to distribute AI tooling, this is a meaningful piece of infrastructure. Platforms like MindStudio handle the orchestration layer — 200+ models, 1,000+ integrations, visual workflow building — but the CLI layer is where you define what your agents can actually reach. Getting that layer right, and making it shareable, is the work Printing Press is doing.
It Was Inspired by Someone Who Built a Better CLI Than Google’s Own
This is a small detail that tells you something about the philosophy behind the tool. Printing Press was partly inspired by Peter Steinberger — creator of OpenClaw — who needed to build his own Google CLI because the official GWS CLI wasn’t good enough for his use case. He built GOG CLI, and people started saying it was better than Google’s official tool.
That’s the premise Printing Press is operating from: official CLIs are often built for human developers, not for agents. They’re verbose. They return more than you need. They’re not optimized for the token-per-task economics of agentic workflows. So the answer isn’t to wait for every company to ship an agent-native CLI — it’s to build your own, or use a library of ones that someone already built with agents in mind.
The architecture reflects this. Lazy discovery means the agent doesn’t load tool descriptions it doesn’t need. Pre-formatted output means Claude gets 200 tokens of clean text instead of a raw JSON payload. A local SQLite mirror means no round trips and no rate limits on reads. These aren’t accidental features — they’re the result of designing specifically for how agents actually consume information.
This design philosophy is showing up in other places too. Tools like Remy take a similar approach to abstraction: you write a spec — annotated markdown — and it compiles into a complete TypeScript backend, database, auth, and deployment. The source of truth shifts up the stack; the generated artifacts are derived output. Printing Press is doing something analogous for the tool layer: you describe what you want to reach, and the factory generates the interface.
The Tier List Has Changed
Here’s the opinion: the mental model most Claude Code users are operating with is wrong. The default assumption has been that MCPs are the modern, flexible answer and APIs are the raw fallback. CLIs were something you used when nothing else existed.
The benchmark flips that. CLIs are tier one. If a CLI exists for what you need, use it. If one doesn’t exist but there’s an API, build a CLI from the API — you’ll almost certainly end up with something more efficient. If there’s no API and no CLI, then MCP is your last resort, not your first instinct.
Printing Press makes tier one accessible for 50+ sites right now, and makes it buildable for anything else in about 10 minutes. That’s a meaningful change to what you can do with Claude Code without burning through your session limit before you’ve accomplished anything.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
If you’re already managing token costs carefully in Claude Code, or building parallel agent workflows with Git worktrees, the CLI layer is the next place to look. The gains are real and the setup cost is low.
The catalog is at printingpress.dev. The factory is included. Go is free. The School CLI took 10 minutes.
