I recently put together a tiny open-source tool: a non-interactive, JSON-first Jira CLI tailored for AI agents. I called it the "kubectl of Jira." The idea is simple: it’s a stateless binary that outputs clean JSON so agents can pipe data straight into jq, grep, or wc without choking on interactive menus or ugly ASCII tables.
I shared it in our team chat, expecting a few code comments. Instead, I accidentally started a argument: In the age of LLMs, why are we still building CLIs? Why aren't we just using MCP servers?
Here is why my team thinks I'm living in the past, and why I still think the CLI wins.
The Argument for MCP (What my team says)
My colleagues made some good points.
If you look at the MCP ecosystem, Jira servers already exist.
They argued that MCP is fundamentally built for LLMs. It exposes clean, structured tool schemas natively. Instead of an agent trying to parse text or guess flags by running --help (which eats up tokens), an MCP server tells the model exactly what parameters it expects right out of the box. Plus, hitting a running MCP service over HTTP or standard I/O is computationally lighter than spawning a brand new OS process for every single command.
If you're building something with a session that is tied to your chat session, or your agent do not have a shell available, they are probably right. MCP is elegant.
Why I Still Prefer a CLI
Despite their pushback, I’m sticking with the CLI approach for three practical reasons:
- The MCP "Schema Tax" burns tokens
The true catch of MCP lies in its heavy JSON schema overhead. Whenever your agent initializes, the daemon dumps a verbose payload containing the names, descriptions, and strict parameters for every single tool directly into your context window. Unless you resort to clunky workarounds—like building a search_tool(query: string) to fetch capabilities dynamically—a server exposing 40 or 50 tools will burn thousands of tokens on raw protocol syntax before the agent even reads your prompt.
With a CLI, the LLM usually already knows the basic syntax from its training data. The agent runs a quick command, gets a tiny JSON blob back, and keeps 95% of its context window free for actual thinking.
- The Unix ecosystem is the ultimate tool schema
With MCP, if your agent wants to search for a ticket, filter it by status, and count the results, you have to explicitly code an endpoint that supports that exact sequence.
With a CLI, the agent just falls back on standard bash utilities it already knows by heart:
jira search jql "assignee = currentUser()" | jq -r '.[].key' | wc -l
I don't have to write custom API endpoints for edge-case queries. The terminal is the toolkit.
- Debugging via shell history
When an MCP agent breaks, debugging sucks. You have to hunt through daemon logs, look at JSON-RPC transport streams, and figure out what the state was when it died.
When a CLI agent breaks, it’s beautiful. I open my terminal, press the up arrow to look at the shell history, copy the exact command string the agent tried to run, and replay it myself.
To keep things secure, I added "Kubernetes-style" local context management (jira context set --project PROJ). It saves the default project to a local file on disk, giving the agent a hard, inspectable blast radius.
The Tool: @888aaen/jira-cli
If you want to try how it feels by yourself, you can it install the cli with
npm install -g @888aaen/jira-cli
npx skills@latest add AndersSpringborg/jira-agent-cli
and use it your own agent harness.
(The second command installs a skill file for your agent harness so it knows how to drive the binary out of the box).
The repo is here AndersSpringborg/jira-agent-cli
Where do you stand?
We are split on this internally. One side thinks CLIs are a temporary stopgap until MCP context management gets smarter. The other side thinks running daemons for basic API tasks is over-engineering.
- Are you building CLIs or standing up MCP servers for your internal workflows?
- How are you dealing with token bloating from massive MCP tool lists?
- Is anyone using a hybrid setup—like CLIs for local hacking and MCP for production?
SOCIAL SHARE CARD GENERATOR