when every tool becomes a CLI (and why that matters for agents)

by Ray Svitla

someone just made every website your CLI. 7,800 GitHub stars in 24 hours. the repo is called opencli, and it does something so obvious in retrospect that you wonder why we’ve been building API wrappers for a decade instead.

it turns any website, any Electron app, any local binary into a standardized command-line interface. Figma? CLI. Notion? CLI. Linear, Slack, Xcode — all CLIs. not “write a scraper for each one” but “make the abstraction universal.”

the tagline: “built for AI agents to discover, learn, and execute tools seamlessly via unified AGENTS.md integration.”

the problem opencli solves (that nobody admits exists)

agents can call APIs. that’s table stakes. but most tools you actually use don’t have APIs. they have web interfaces, desktop apps, proprietary protocols. when your agent needs to interact with Figma, you have two options:

1. browser automation — fragile, slow, breaks when the UI changes
2. official API — if it exists, which it often doesn’t, and if it does, it’s rate-limited and incomplete

opencli says: there’s a third option. make everything CLI-native. not “build wrappers” but “fix the abstraction layer.”

when your agent can drive Figma via opencli figma create-component --name header --variant dark, it doesn’t need to simulate mouse clicks or parse DOM structures. it just calls a tool.

why CLI > API for agent workflows

APIs are designed for humans writing code. CLIs are designed for scripts. agents are closer to scripts than humans.

API workflows require:

• authentication dance (OAuth, tokens, refresh cycles)
• rate limit management
• versioning hell (v1, v2, breaking changes)
• incomplete coverage (APIs expose 60% of UI functionality if you’re lucky)

CLI workflows require:

• one command
• stdout/stderr for feedback
• composability (pipe outputs, chain commands)
• full feature parity with the UI (because the CLI wraps the same backend)

when you build for agents, CLI is the primitive. APIs are the workaround.

AGENTS.md as universal integration spec

opencli doesn’t just make tools CLI-compatible. it makes them AGENTS.md-discoverable.

AGENTS.md is the emerging standard for “here’s what this repo/workspace/tool knows how to do.” it’s markdown, human-readable, agent-parseable. when your agent enters a new environment, it reads AGENTS.md to learn what’s possible.

opencli extends this: every tool you add becomes a skill in your AGENTS.md. your agent doesn’t need documentation. it reads the skill library, sees what’s available, calls the tools.

the pattern:

1. agent reads AGENTS.md
2. finds `opencli` skill with tool catalog
3. calls `opencli <tool> <action> <args>`
4. gets structured output
5. continues workflow

no training. no API keys. no “integration project.” just: tools exist, agent uses them.

what changes when tooling becomes universal

right now, most agent demos are narrow. “here’s Claude writing code.” “here’s Codex refactoring a function.” the scope is constrained because the tooling surface is constrained.

opencli says: what if the tooling surface was infinite?

when your agent can:

• design in Figma
• manage tasks in Linear
• query databases in Retool
• update docs in Notion
• deploy via Vercel
• monitor in Datadog

…all via standardized CLI, all from one AGENTS.md skill catalog, the constraint shifts. it’s not “can my agent do X?” but “can I describe X clearly enough for my agent to execute?”

the bottleneck moves from tooling to intent.

the 7,800-star signal

opencli hit trending #1 on GitHub all-languages. 7,800 stars in 24 hours. 56 comments, mostly “why didn’t this exist already?”

that’s not hype. that’s recognition.

developers have been writing API wrappers for years. browser automation libraries. headless Chrome scripts. every tool gets its own integration layer. opencli says: stop. make the abstraction universal. CLI is the primitive. everything else is implementation.

when a repo goes from 0 to 8K stars overnight, it’s not because the code is novel. it’s because the insight is obvious once stated. “every tool should be CLI-native” sounds trivial until you realize we’ve spent a decade doing the opposite.

what opencli doesn’t solve (yet)

opencli is infrastructure. it makes tools discoverable and callable. it doesn’t solve:

1. semantic understanding — your agent still needs to know what “create component” means in Figma context
2. error handling — when a command fails, the agent needs recovery strategies
3. state management — multi-step workflows require tracking what’s been done

these aren’t opencli problems. these are harness problems. opencli gives you the primitive (universal CLI). harnesses like deer-flow, ruflo, agent-deck give you orchestration, memory, multi-agent coordination.

the stack:

• opencli → tool discoverability
• AGENTS.md → capability declaration
• harness (deer-flow, etc) → workflow execution
• agent (Claude, Codex, local LLM) → reasoning engine

opencli is the bottom layer. it makes “what tools exist?” a solved problem. the rest is coordination.

the shift nobody’s talking about

most agent discourse focuses on models. “is Opus 4.6 better than GPT-5.3?” “can local models match cloud?”

opencli shifts the frame: what if the tooling layer matters more than the model layer?

when every tool is CLI-native and agent-discoverable, the constraint isn’t “how smart is my agent?” but “how well can I describe what I want?” a dumb agent with infinite tooling beats a smart agent with narrow tooling.

this is the “tool abundance” thesis. we’ve been optimizing models for scarcity (limited API access, rate limits, integration hell). opencli optimizes for abundance. every tool, every app, every workflow — all discoverable, all callable, all composable.

when tooling is infinite, intelligence becomes less scarce.

what happens next

opencli trending means adoption. adoption means pull requests. PRs mean more tools get CLI wrappers. more tools mean more agent capabilities. more capabilities mean more use cases. more use cases mean more demand for universal tooling.

flywheel effect.

three months from now, if opencli sustains momentum:

• every major SaaS tool will have an opencli integration
• AGENTS.md will be standard across repos
• harnesses will compete on orchestration, not integration
• agent demos will show multi-tool workflows as default, not exception

six months from now:

• CLI-first becomes table stakes for new tools
• browser automation becomes legacy pattern
• API wrappers get deprecated in favor of CLI wrappers
• tooling abundance becomes assumed, not aspirational

the question isn’t “will opencli win?” but “how fast does the ecosystem converge on CLI-native as default?”

closing loop

opencli is obvious in retrospect. every tool should’ve been CLI-native from the start. we built for humans clicking UIs, then bolted on APIs as afterthought, then wrote browser automation to fill gaps.

agents inverted the priority. CLI-first makes sense when your primary user is a script.

7,800 stars in 24 hours says: we’ve been doing it backwards. fix the primitive, not the workaround.

when every tool becomes a CLI, agents stop being demos and start being infrastructure.

Ray Svitla stay evolving 🐌