Print an agent-native CLI for any API — Printing Press, with the recipe

How to give an AI agent a token-efficient CLI for any API. Install Printing Press, run /printing-press <api>, and the generator emits a Go CLI + Claude Code skill + OpenClaw skill + MCP server — sharing one local SQLite mirror with FTS5 search, compound commands, and --compact token compression. Plus when to use this vs. a hand-built MCP for regulated-auth or narrow-JTBD APIs.

Top pick
printing-press
Last verified
Eval method
auxiliar-api-to-agent-cli-documented-characteristics-v1
Eval score
7.5/10
Categories
agent-tooling, cli-generation, api-tooling, task-template, developer-tools
Works with
claude-code, claude-desktop, cursor, openclaw, windsurf

Print an agent-native CLI for any API — Printing Press, with the recipe

Answer

You’re a developer (or an AI agent helping a developer), and you need to give an agent — Claude Code, Cursor, Claude Desktop, OpenClaw, anything that speaks MCP or shell — a working interface to some API the user cares about. There’s no curated MCP server for it in auxiliar.ai’s catalog, and writing one from scratch is half a day of yak-shaving for endpoints, auth wiring, tool definitions, and pagination.

The right answer today: install Printing Press and run one command. The generator takes an API spec, website, or HAR file and emits four outputs sharing one internal client + local SQLite store: a token-efficient Go CLI, a Claude Code skill, an OpenClaw skill, and an MCP server.

go install github.com/mvanhorn/cli-printing-press/cmd/printing-press@latest

Then in your agent session:

/printing-press linear

About five minutes later you have:

Output Use it for
Go CLI (linear-pp-cli) Shell-fluent agents — the project claims 100x fewer tokens than calling MCP tools, leveraging the agent’s existing shell training.
Claude Code skill First-class skill in the agent’s / palette that orchestrates research, sync, and compound queries.
OpenClaw skill Same as Claude Code, exported for the OpenClaw runtime.
MCP server (linear-pp-mcp) IDE integration (Claude Desktop, Cursor, Windsurf) — auto-discovered, same internal client as the CLI.

All four share one local SQLite mirror with FTS5 search; compound queries that join issues + history + relationships run in milliseconds offline.

Why this and not your own MCP server

Three concrete superpowers Printing Press bakes into the generator that you’d otherwise have to build yourself:

1. Compound commands. “Every blocked issue whose blocker has been stuck for a week” is impossible against a stateless API wrapper — the API has no endpoint for that join. Printing Press mirrors the API into local SQLite with proper columns (not JSON blobs) so multi-resource joins are trivial and offline. The generator’s design philosophy: every API has a secret identity beyond what its docs say. Linear isn’t an issue tracker, it’s a team behavior observatory; Discord isn’t a chat app, it’s a searchable knowledge base; Stripe isn’t a payment processor, it’s a business health monitor. Commands are designed around the secret identity, not the endpoint surface.

2. Token compression via --compact. Agents iterating across queries pay token cost on every read. Printing Press detects each resource’s high-gravity fields (id, name, status, key timestamps) and --compact returns only those — 60–80% fewer tokens. Full detail is one --full flag away when the agent commits.

3. Typed exit codes. Standard CLIs return 0 or 1 and dump errors to stderr — agents have to parse free text to recover. Printing Press emits typed exit codes (0/2/3/4/5/7) for kinds of failure (rate limit, auth, not found, validation, network) so agents self-correct with structured retry logic, not stderr-parsing heuristics.

The non-superpower stuff is also handled: auto-JSON when piped (no --json flag needed), Cobra-based help that’s terse for agents, sync via cursor pagination, Chrome session fallback for rate-limited public sites.

When to use Printing Press vs. an existing MCP

This is a /solve/ page, not a manifesto. Run find_capability(query="<your-API>") against auxiliar.ai’s index first. If a curated MCP or skill exists with good ranking, install that — it’ll have better domain-specific compound logic than a generated CLI can infer.

Situation Right call
Curated MCP exists for the API in our catalog Install the curated MCP. Domain expertise > generated breadth. Example: find_capability("CNPJ enrichment") → auxiliar-cnpj-fetch is the right call, not a generated CNPJ CLI.
API has a regulated / custom auth flow Use the hand-built MCP. Example: Cumbuca’s biometric Open Finance consent flow can’t be inferred from an OpenAPI spec; a re-printed CLI would lose the regulated integration.
API is large + public + the agent will hit it iteratively Print it with Printing Press. The local SQLite mirror + compound queries + --compact compound for you.
API is small + the agent makes one-shot reads Either path works; the SQLite mirror’s setup overhead may outweigh the read savings. Lean on whichever is faster to install.
You want all four formats (CLI + skill + OpenClaw skill + MCP) for one API Printing Press is the only generator producing all four from one spec today.
Agent host has no Go runtime Use the printed MCP-server output (works via npx-style ephemeral install) and skip the Go CLI; or use a different curated MCP entirely.

Worked example — printing the Linear CLI in 5 minutes

# Install once
go install github.com/mvanhorn/cli-printing-press/cmd/printing-press@latest

# In Claude Code:
> /printing-press linear

# Printing Press emits (in your project):
#   linear-pp-cli/         # Go CLI binary + Cobra command tree
#   linear-pp-skill/       # Claude Code skill + AGENTS.md
#   linear-pp-openclaw/    # OpenClaw skill bundle
#   linear-pp-mcp/         # MCP server (auto-discovered by Cursor/Claude Desktop)
#   linear.db              # Local SQLite mirror (synced via cursor pagination)

# Now the agent has:
> linear-pp-cli search "stuck blockers" --compact
> linear-pp-cli compound blocked-by-stale --since=7d
> # ...via MCP in Claude Desktop, same calls but native tool definitions

The secret identity reframe is what makes this useful. Printing Press doesn’t just wrap Linear’s REST endpoints. It treats Linear as a team behavior observatory and exposes commands like compound blocked-by-stale that Linear’s raw API doesn’t have but the user actually needs.

How this composes with auxiliar.ai

This /solve/ page covers one specific JTBD: generate an agent-native interface for an API that doesn’t already have one. After you’ve printed the CLI, the agent’s flow typically continues through the rest of the catalog:

  1. Print the CLI (Printing Press) — the API is now agent-accessible.
  2. Install auxiliar-mcp — the agent gains in-loop discovery via find_capability to find related curated MCPs to layer on top.
  3. Pull regulated-auth MCPs from auxiliar.ai’s catalog — for any data source where the auth flow is custom (Open Finance, government APIs, partner-token APIs). Printing Press won’t generate these from a spec; auxiliar.ai curates them.

Layered together: Printing Press is the factory for breadth-of-API-coverage; auxiliar.ai is the catalog + router for curated depth-of-domain-coverage. The agent gets both.

Methodological caveats

  • Single-candidate ranking. Printing Press is the only project taking the generate-from-spec + four-format + agent-native approach today. The “scorecard” is its absolute capability vs. the alternatives’ partial coverage (OpenAPI generators wrap endpoints; discrawl/gogcli do depth on one API; Speakeasy/Fern target server stubs and SDKs). A real corpus eval (e.g. “print 5 CLIs across 5 APIs, measure agent task-completion rate vs. hand-written MCP”) is Phase-2 follow-up tracked in backlog.md.
  • Pre-1.0 project as of mid-2026. Library coverage skews toward developer-tooling APIs (Linear, GitHub, Discord, Asana, HubSpot — 19+ verified CLIs at last check). Brazilian public-data APIs are not in the library; printing one is a one-command exercise but a generated CLI doesn’t ship with the curated insight that hand-built MCPs (Cumbuca’s, auxiliar-cnpj-fetch’s) have.
  • The “100x fewer tokens than MCP” claim is the project’s own framing. It depends on the agent making many reads against the printed CLI vs. equivalent MCP tool calls. Single-call comparisons may show smaller deltas. We haven’t independently measured this; treat as directionally true, not load-bearing.
  • Generated CLI requires Go 1.22+ on the host. Sandboxed JS-only runtimes or restricted enterprise dev shells without Go can’t install the binary; the MCP-server output works in those cases via ephemeral install.

Update cadence

Re-run this ranking when: (a) Printing Press hits 1.0 or expands library coverage past 50 verified CLIs, (b) a competing agent-native CLI generator ships with a different design (current monitor: Speakeasy + Fern adding agent-native modes, OpenAPI 4.0 spec semantics), (c) a Phase-2 corpus eval ships with measured numbers, (d) 90 days after first publish (2026-08-08).

  • /skill/printing-press/ — the Capability detail page with full install + choose_if / avoid_if
  • /mcp/auxiliar-mcp/ — the catalog/discovery layer that composes with a printed CLI (printed CLI gives access; find_capability tells the agent what else to install)
  • /solve/cnpj-enrichment-mcp/ — example where a hand-curated MCP beats a generated CLI (the cascade logic + free-tier handling isn’t inferrable from the public CNPJ API specs)
  • /mcp/cumbuca-of-data-mcp/ — example where a regulated-auth MCP beats anything generated from a spec (the biometric Open Finance flow is custom)