DEV Community: Anders Aaen Springborg

I built a Jira CLI for my AI agents. My team thinks I should have used MCP

Anders Aaen Springborg — Tue, 09 Jun 2026 19:36:40 +0000

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?

A Beginner's Guide to Mobile Development in React Native with Expo

Anders Aaen Springborg — Wed, 23 Mar 2022 15:34:06 +0000

Intro

This is a guide getting you through setting up a React Native project. However, this guide won't go in details with React, so if you're new to React, I recommend you to check out this getting started with react guide.

Here is a link for what your code should look like, when you are done.

React Native and Expo

React Native is a framework for writing cross-platform native apps.

Expo is a set of tools and services built around React Native and native platforms that help you develop, build and deploy iOS and Android apps from the same JavaScript/TypeScript codebase. The alternative would be to build each app in xCode and Android studio, which is very cumbersome.

Installation

Prerequisites

You need to have node and npm installed, and yarn is optional, but recommended.

Then we have to install Expo, through npm:

# Install the command line tools
npm install --global expo-cli

Now, we're ready to make a project. If you installed yarn, write:

expo init first-app

or with npm

expo init first-app --npm

From here, you will be prompted with a few options for your project. I recommend choosing a managed workflow as this enables us to release the app in Expo, without an Apple developer account for iOS. I chose the template "blank (typescript)", as can be seen in the picture below. If you're new, you could also use the "tab" template. This has built-in navigation.

You now have a project. In your terminal, you can navigate to the project's directory with 'cd first-app'. Your project structure should look like this:

Now, you can run the project by writing:

yarn start

npm run start

And it will look something like this:

You can either press w, to see your app in your browser, or you can scan the QR code which redirects you to download an app called Expo go. This allows you to view the app while you develop it, which is something I would recommend.

You now have a running app in React Native. In the next section, we are going to look at how native APIs work.

Native APIs

As we choose a "managed workflow", we're building everything with Expo. This comes with some limitations. If you need a native API which isn't on the list of supported APIs (there is 100+ native APIs), you can switch to a bare workflow in which you can write your own native code.
Below is a comparison between a managed and bare workflow:

Implementing native APIs

As an example, let's make a page that shows our battery percentage and GPS location.

Let's start with a battery component. We install it with:

expo install expo-battery

First off, we'll work on showing the battery percentage. We need the API 'getPowerStateAsync'. We'll call when a component mount, and voilá - we have the phone's battery percentage:

const [battery, setBattery] = useState<number>(0);

  useEffect(() => {
    Battery.getBatteryLevelAsync().then(b => setBattery(b));
  }, []);

We can show it in our view like this:

return (
    <View style={styles.container}>
      <Text>Battery {(battery * 100).toFixed(0)}%</Text>
      <StatusBar style="auto" backgroundColor={"black"}/>
    </View>
  );

Now, let's make a component that looks at the power mode of a phone. Imagine that you have a power-hungry feature which you want to disable when in low power mode (like animation).
We can get the power state from the same API, like this:

const [lowPoweredState, setLowPoweredState] = useState<boolean | null>(null);

  useEffect(() => {
    Battery.getPowerStateAsync().then(bs => setLowPoweredState(bs.lowPowerMode));
  }, [])

We can now carry out some conditional rendering, based on the power state:

  if (lowPoweredState === null) return <Text>Getting info from your phone...</Text>;
  return (
    <Text>Battery state: {lowPoweredState ?
      "i am a static text replacement" :
      "I AM A POWER HUNGRY ANIMATION"}
   </Text>);

To stay up to date, when the phone changed from a low powered state to a normal one, we can add a listener in useEffects like this:

const batteryModeSubscriber = Battery.addLowPowerModeListener(b => setLowPoweredState(b.lowPowerMode))
return () => batteryModeSubscriber.remove();

Our app will now always render based on the power state.

Publishing our app

Normally, you think of publishing an app to App Store and Google Play store. In order to do this, you need an Apple developer account(100$ yearly subscription) or a Google Play developer account(25$ one time fee) account. You can read more about building and releasing your app here.

You're an app developer

You have now started on your first React Native app in Expo. This is the same tool which is used for creating apps like Facebook, Instagram, Coinbase, shopify, Tesla, Uber Eats and many more. You can read more on Expo here: https://docs.expo.dev/ or check out an open source app here: https://github.com/withspectrum/spectrum
and checkout an enterprise boilerplate here: https://github.com/infinitered/ignite