clfly

clfly comes from noticing that PostgREST got something profoundly right: if you describe your data schema precisely, the API can be derived rather than written. I wanted the same move for command-line tools. In clfly, a CLI is a filesystem tree of small functions, each declaring its arguments as a schema (any Standard Schema validator — Zod works out of the box). From that one tree, the framework projects every interface: argv parsing with generated --help, an MCP server so agents can call your commands as tools, an HTTP/RPC surface, and an OpenAPI document. The tagline I keep coming back to is “human accessible, AI ready” — and the design principle underneath it is that mcp serve is to agents what --help is to humans: the same self-description, rendered for a different reader.

The framing that organizes all of it is addressability. A command’s path in the tree is its canonical address; argv, MCP, HTTP, and a command palette are just different syntaxes for dereferencing it. That’s also what makes migration cheap: re-front an existing CLI as a clfly tree of schemas wrapping shell-outs — strangler-fig style — and you get an agent-callable tool surface for free, without rewriting anything. The framework is self-hosting (clfly scaffolds clfly-compatible CLIs via its own command tree), and the spec is deliberately implementation-neutral so the pattern isn’t tied to TypeScript.

commands/users/list.ts  →  mycli users list  →  MCP tool users_list

Roadmap

• M1 — router, parsing, validation, help/version
• M2 — build manifest, bash/zsh/fish completions, --json
• M3 — mcp serve (in progress)
• M4 — OpenAPI export + HTTP serve
• M5 — docs / palette ecosystem packages