repository·main·Indexed 25 days ago
https://github.com/mvanhorn/cli-printing-pressA tool to generate high-performance, agent-native CLIs and MCP servers for any API or website. It produces Go-based binaries featuring local-first SQLite data layers, FTS5 search, and token-efficient flags like `--compact`. The tool can generate specifications from OpenAPI specs, HAR files, or by capturing browser traffic. It supports a 'Creativity Ladder' of sophistication ranging from basic API wrappers to advanced behavioral insights and domain analytics.
Zuplo/Steam-OpenAPI). The session involved processing 158 operations using OpenAPI 3.0 and resulted in a scorecard of 71/100 (Grade B).CLI Printing Press generates domain-aware CLIs and MCP servers from API specifications. Key capabilities include:
sync, millisecond search, and direct sql querying.cache.enabled to keep local stores current when using --data-source auto.--json flag required).--compact flag to reduce token usage by 60-80% by dropping non-essential fields.0, 2, 3, 4, 5, 7) for agent self-correction.--dry-run for safe exploration.<api>-pp-cli) for shell agents and an MCP server (<api>-pp-mcp) for IDE agents (Claude Desktop, Cursor, etc.) from a single specification.The /printing-press-amend workflow uses a specific 'plumbing' pattern to manage the lifecycle of a Pull Request (PR) against the mvanhorn/printing-press-library repository. This process follows a sequence of: fork/clone management $\rightarrow$ managed-clone setup $\rightarrow$ branch creation $\rightarrow$ commit $\rightarrow$ push $\rightarrow$ PR creation.
Note on Drift: This plumbing is a specialized version of the patterns used in /printing-press-publish. While similar, it is adapted specifically for patching existing CLI tools rather than publishing new ones. If the publishing plumbing changes, this amend plumbing may require manual auditing.
Printing Press provides both a Cobra-based CLI and an MCP server for the same specification. Choose based on your priority:
The Steinberger scorecard uses a two-tier scoring system where each tier contributes a maximum of 50 points to a total score (0-100).
Max Raw Base: 200 points (20 dimensions, 0-10 each). Focus: Core CLI stability, auth, error handling, README, and MCP (Model Context Protocol) quality.
Max Raw Base: 60 points (7 dimensions, varying max). Focus: Path validity, auth protocols, data pipeline integrity, sync correctness, type fidelity, dead code, and live API verification.
tier1Normalized = (tier1Raw * 50) / tier1Maxtier2Normalized = (tier2Raw * 50) / tier2MaxTotal = tier1Normalized + tier2NormalizedTo communicate effectively with the Printing Press, use the following terminology:
internal/generator/).verify, dogfood, scorecard).SKILL.md instructions that guide the agent during generation.cmd/cli-printing-press/).notion-pp-cli).The Printing Press CLI generation process includes several built-in quality gates and agent-optimized features:
Quality Gates:
go mod tidygo vetgo build--help validationversion checkdoctor commandAgent-Native Flags: These flags are wired across 80+ commands to support automated interaction:
--json--select--compact--csv--dry-run--agentGenerated CLIs in this project use a pattern-matching approach to provide actionable feedback when authentication fails. Instead of generic error messages, the CLI identifies specific authentication issues (even when APIs return HTTP 400 instead of 401/403) and provides the exact environment variable required and a setup command.
Key Behaviors:
STEAM_API_KEY) and a one-line setup command (e.g., export STEAM_API_KEY=<your-key>).Get a key at: <url> line.In some CLI implementations, the local SQLite store only grows via explicit sync commands. This means browsing or searching via the live API does not automatically populate the local searchable corpus.
For large-catalog APIs where a full sync is impractical, look for implementations that support 'write-through caching,' where successful live API reads are automatically upserted into the local store to build the index incrementally.
The Printing Press provides different ways to execute work flows. While the managed pipeline is the primary structure, two other entrypoints exist that share similar logic but different execution models:
printing-press run: This command drives the MakeBestCLI flow. It compresses the entire process into a single call and returns a FullRunResult. Its internal steps (research, generate, polish, coverage, dogfood, verification, workflow-verify, scorecard, fix plans, publish) map to the managed phases but do not utilize the formal phase state machine./printing-press skill: This uses a high-level Phase 0..5 layout. This is a compressed version of the work rather than a competing contract, and its artifacts should match the shape described in the managed pipeline phases.When generating a CLI via discovery methods (like Browser Sniff), the system preserves evidence of how the API was discovered. This evidence is stored in a dedicated discovery/ directory within the API run directory. This ensures reproducibility and auditability by recording what was observed, what was inferred, and the confidence levels for each endpoint.
Discovery artifacts are stored in $API_RUN_DIR/discovery/ and are prefixed by the method used (e.g., sniff-*).
archive step copies the discovery/ directory to $PRESS_MANUSCRIPTS/<api>/<run-id>/discovery/.publish package command includes the discovery directory in the package if it exists. The absence of a discovery/ directory is normal for non-discovery CLIs and is not treated as an error.The Printing Press offers two ways to generate a CLI for an API:
/printing-press skill): Runs the entire generation flow end-to-end in a single session. It produces a CLI and an MCP server and reports the result immediately.printing-press pipeline): A 9-phase pipeline that breaks the work into discrete, inspectable steps. This path allows users to stop, resume, re-run, or inspect specific phases. Each phase has its own plan file, artifacts directory, and quality gates.Both paths aim for the same quality standard.