CLI is ALL you need

CLI is ALL you need

Starting from Obsidian CLI

Not long ago, the veteran knowledge management software Obsidian officially announced its command-line tool Obsidian CLI, which is now available in the v1.12 preview release. Obsidian CLI provides functionality completely equivalent to the Obsidian GUI version: from basic note retrieval, editing, and task management, to advanced developer features such as plugin management, screenshots, JS code execution, Chrome DevTools Protocol (CDP), console message handling, and DOM element retrieval, all are supported in Obsidian CLI.

Some common Obsidian CLI commands are as follows:

# Open daily note
obsidian daily

# Add task to daily note
obsidian daily:append content="- [ ] Buy groceries"

# Search notes
obsidian search query="meeting notes"

# List daily tasks
obsidian tasks daily

# Create new note from template
obsidian create name="Trip to Paris" template=Travel

# List all tags with counts
obsidian tags counts

# Take screenshot
obsidian dev:screenshot path=screenshot.png

# Execute JavaScript code
obsidian eval code="app.vault.getFiles().length"

Why Now?

Obsidian has a massive plugin and theme ecosystem, but for a long time did not release an official CLI tool. Three years ago, the community created notesmd-cli (originally named obsidian-cli, renamed after the official CLI was released), a command-line tool that can operate on the Obsidian database without opening the Obsidian application.

From the notesmd-cli Star trend chart, we can clearly see that the project’s Star growth had been relatively stable since its inception, but after entering 2026, the project’s Star count experienced explosive growth.

The driving force behind this growth is obvious: the viral popularity of OpenClaw🦞. This lobster sparked the biggest wave in the AI community since 2026. As one of the default configured tools for OpenClaw, notesmd-cli naturally rode the wave of OpenClaw’s success.

Obsidian’s official release of CLI at this time undoubtedly indicates they saw the immense potential behind the notesmd-cli project. Obsidian’s knowledge management and task tracking system perfectly fits the needs of AI assistants like OpenClaw. Compared to simple MEMORY.md and memory/ folders, using Obsidian as an AI assistant’s memory bank is definitely a leap forward in productivity tools. The extensibility provided by over 2,000 plugins in the Obsidian community offers even more possibilities on top of this foundation.

Why CLI?

So, why CLI?

Because CLI is the natural language of AI Agents. Current mainstream LLMs all have complete tool-calling capabilities, and command-line invocation is one of the most fundamental and important tools for LLMs. When an AI Agent has command-line calling capabilities, it has the power to do anything:

• Use cat to read files
• Use grep to search for keywords
• Use sed to modify files
• Use curl to access web pages or call APIs
• Use git to manage code
• Use ssh for remote access
• ……

In fact, this is how humans used computers in the early days. No complex graphical interfaces needed, no fancy interaction methods required - a terminal and a keyboard could make a programmer feel like the world was in their hands.

Similarly, when an OpenClaw bot gains access to hundreds of CLI tools, it truly transforms from a chatbot into an omnipotent AI assistant.

Admittedly, current multimodal LLMs already possess powerful image and video understanding capabilities, and can use these abilities to control browsers and other desktop programs. However, this Computer Use approach consumes more tokens and also has greater uncertainty. The correctness of operations cannot be guaranteed; and correctly obtaining operation results is equally difficult (requiring another screenshot and parsing). In contrast, command-line invocation doesn’t rely on the LLM’s multimodal capabilities at all - text input, text output, everything seems incredibly natural.

Why Not MCP?

The Model Context Protocol (MCP) is a protocol proposed by Anthropic in November 2024, aimed at providing a standardized way for LLMs to call external tools. Through MCP, LLMs can call external tools without needing to know the specific implementation details of the tools.

MCP is good, but MCP also has quite a few problems, compared with CLI:

• MCP is a feature specifically for Agents, with no direct use value for human users. A large number of existing software need specialized packaging to enter the MCP ecosystem. CLI, on the other hand, was born with computer systems and is the most fundamental way humans interact with computers.
• MCP descriptions directly occupy Context. If hundreds of MCPs are enabled simultaneously, it means consuming tens of thousands of tokens during the system prompt phase, which directly increases API call costs and slows down response times. Moreover, these MCPs are not always useful for the current task, and conflicts may exist between MCPs, all of which can affect Agent execution precision. Some advanced users perform fine-grained control over MCPs used for each project, but this also brings additional workload and mental burden. In contrast, CLI provides self-explanatory documentation through the --help option, requiring far fewer fixed tokens than MCP.
• There is currently no convenient mechanism for re-inserting MCP descriptions (writing as skills is a possible solution), which leads to imprecise Agent calls to MCP after Context grows. CLI-related information, on the other hand, can be inserted at the end of the current conversation at any time (for example, simply saying “please use the xxx command”), ensuring the Agent always has relevant information.

Let’s think again, what can MCP do that CLI cannot?

The answer is clear: everything that can be done through MCP can also be done through CLI. Because MCP and CLI are essentially just two different user interfaces.

CLI naturally possesses an important feature that MCP lacks: CLI invocations are essentially running Shell scripts, so they can easily form chained or decision-tree processes to achieve complex processing; whereas MCP currently can only make single calls to get single results. To achieve condition-based flow control, it must rely on the LLM’s autonomous design, and the process requires multiple MCP calls, increasing complexity and uncertainty.

CLI Design in the Agent Era

But why has MCP received more attention than CLI in the AI era? On one hand, it’s human instinct to chase the new: MCP is a new product of the AI era, while CLI is an “antique” that has existed for decades; on the other hand, it’s because CLI has long lacked a rigorous specification system. What we have are just scattered conventions:

• Single-character short commands like -x
• Long commands like --execute
• Help options like -h|--help
• Space-separated arguments
• ……

Compared to MCP’s strict specifications, CLI’s freedom and looseness has become an obstacle preventing its widespread use by Agents.

The key issue is not that CLI itself is inferior to MCP, but that traditional CLI design must change in the Agent era. Here I propose three core principles for CLI design in the Agent era:

Clear and Reasonable Hierarchical Structure

A good CLI tool’s help information should be a clearly structured, well-organized document. We know that the core of current Agent applications lies in context engineering. Reasonable hierarchical design can help Agents load the tool context needed for the current task on-demand after a few --help calls, thereby achieving better Context utilization efficiency.

Intuitive Command Style

• Use the same verbs for the same type of resources;
• Follow the same parameter order for the same type of verbs;
• Maintain consistent semantics for global options (such as --verbose, --dry-run, --output, etc.);
• Option naming should follow conventions as much as possible, don’t invent new vocabulary.

By following these principles, Agents can execute command calls with high accuracy without viewing help documentation (thus saving Context).

A simple design approach: think about how you would describe this command in natural language (English)? A command system that closely aligns with natural language can naturally enable Agents to achieve “what they think is what they see, what they see is what they get.”

Stable and Readable Structured Output

In the Agent era, CLI tools are oriented toward AI Agents instead of humans, so their output must also follow Agent-oriented design principles and must have a stable structure:

• Can be formats like --json, --yaml, or in some cases, a stable text structure format (such as compilers, etc.);
• Have clear exit codes and parsable error fields.

Structured output allows Agents to easily perform information extraction (with tools like jq) and process orchestration, thus fully leveraging the powerful capabilities of CLI.

Besides these three core principles, there are some details worth noting:

• Write operations should support idempotency or --dry-run options as much as possible, so Agents can preview and debug;
• For multi-agent and subagent architectures, CLI concurrency control needs to be considered. A simple file lock can avoid many write conflict issues.
• Complex features should ideally have observability, so Agents can better troubleshoot when problems occur during calls.

Conclusion

The release of Obsidian’s official CLI tool is an important signal in the wave of AI assistants sparked by OpenClaw. When the MCP hype gradually settles down and we look back, the CLI that has accompanied us for decades has been there all along.