MCP, CLI, and TUI — Why I'm Shipping All Three for Oracle WebCenter Content

Sometime in January a thread went round the AI dev community arguing that CLIs are the new MCP!.. and that we'd all been spending a year building structured tool servers when the agents would have happily just read CLI `--help` and get on with it.

At the time I shrugged it off. - I'd spent most of 2025 building the WebCenter Content MCP Connector following Anthropic guides and had put in a lot of time, effort, tweaking enhancing researching how to further enhance the MCP server.

Check out the revamped WebCenter MCP V2

And then the benchmarks landed.

MindStudio measured a 32x token gap between CLI-driven and MCP-driven agents on the same task, and a reliability drop from 100% on the CLI path to 72% on the MCP path once the workflows ran more than three or four steps deep.

Scalekit's numbers landed:
4–32x cost difference, 28% better task-completion-per-token on the CLI side.

And so this is why I built `./wcc`

I already had a MCP direct to REST API but thought lets expand out with one Rust binary, three protocol surfaces: CLI, TUI, and another MCP server using the CLI instead - all sitting on a shared service-layer crate that I had built that already knew how to talk to WebCenter Content.

The point isn't to pick a side in the MCP-vs-CLI debate but to test, confirm and ship my own to compare the numbers for myself against WCC LLM calls.

... .. Also I'd been itching to have an excuse to play with Ratatui and create an old school TUI for us humans ;) Far better than a browser or OCM CLI.. if you remember those days..

Using `./wcc` today

Today wcc interface is experimental but from my initial experiments and tests I was too excited and wanted to share it early with you to have a play with -

WCC CMDs

These are the initial top level cmds available but don't be decieved you can make pretty advanced  calls to customise the formatting display:

./wcc files search jsim --mode author --format json | jq -r '.results[] | [.dDocName, .dDocTitle, .dDocAuthor, .dInDate, .dFormat] | @tsv' | column -t -s $'\t'

There also some options to format the output display -

WCC as a CLI

Run it as a CLI (`wcc files search invoice`) and you get JSON on stdout that scripts and LLM agents can compose with `jq`.

WCC as a MCP

Run it as MCP Server `wcc serve --mcp` and the same operations are exposed as native MCP tools over stdio. v0.1.0 ships today with ten WCC operations across files, folders, workflows, system, and a generic IdcService escape hatch.

You can also do simple things like add it to claude code ;)

claude mcp add wcc
--env WCC_HOST=wcc.example.oraclecloud.com
--env WCC_USERNAME=your-user
--env WCC_PASSWORD=your-pass
-- wcc serve --mcp

WCC as a TUI

Run it as a TUI  (`wcc`) - with features such as scrollable panels, tables, clickable regions and much more. - faster than WCC UI running rust in the background with sub 20ms request times compared with node or browser fetches and no need to load or request any addition JS libraries or html - perfect if you are in a low bandwidth area and just want access to the data!

The token argument — and what it costs in real terms

The strongest argument the CLI camp makes is about tokens. Every MCP server an agent connects to imposes an upfront cost - the tool descriptions land in the context window before any actual work happens. For a small server with five tools, you'll never notice it.. But for something the size of the WCC MCP Connector, with x consolidated tools, each with input/output schemas, annotations, scope flags, and role based prompt packs then the manifest pushes well into five-figure tokens before the agent has done anything useful.

A CLI doesn't have that upfront cost.

The agent runs `wcc --help` and gets ~500 tokens of subcommand listing, then `wcc files search --help` (~400 more) only if.. it actually needs to search. Discovery is lazy, so this means that the total context consumed is roughly same as the operations the agent actually invokes.

For one-shot tasks the difference doesn't matter.

.. But for agents running long autonomous loops on a fixed budget, it does.. and the failure mode is subtle.

MindStudio noticed multi-step reasoning breaking down after three or four MCP tool calls this is because the accumulated context pushed the agent into the tail of its attention window. The tokens weren't only more expensive - they were spent in the region where attention quality drops off.

The reliability argument

This comes up alot! - especially MCPs in production and where the 2026 benchmarks really lands. The same MindStudio study measured task-completion side by side 100% reliability on the CLI path, 72% on the MCP path on the harder multi-step tasks.

The CLI agent also hit a 28% higher completion score per token spent. Those tokens weren't only cheaper. They were better-spent!

The reason isn't a mystery if you think about training data. Modern LLMs have read billions of lines of `git`, `docker`, `kubectl`, `aws`, `gh`, `jq`, `psql`, `curl`

Creating a common interface modal is critical

`wcc`'s help text is built around a common interface modal.

This means that every subcommand's `--help` is deliberately verbose — examples, expected output shape, exit codes, common pitfalls. Modern agents read it on demand and behave correctly. Older or less-capable agents still benefit, because the help structure follows conventions they've seen a million times.

And the default output is just JSON.

There's no wire-format design problem. `wcc files search "..." | jq` composes with everything an agent already knows. The exit codes are a contract too — 0 success, 2 not found, 3 auth, 4 config, 5 network — so scripts and agents can branch on failure without parsing stderr. (`WCC_ERROR_FORMAT=json` switches stderr to a one-line JSON object if the agent prefers structured errors.)

My Thoughts on this today..

So this isn't a case of CLI replacing MCP in my opinion; it's a case of CLI being the right tool for the job for the 80% of operations where the agent just needs to do something.. and MCP being the right answer for the 20% where the workflow has compliance requirements that the shell can't carry.

So why both and why one binary is the right packaging?

If you look around the majority of shipped agents have already settled this! Look at Claude Code, Cursor, Gemini CLI they all use both surfaces..

• CLI for the things the model already knows (`git`, `grep`, `npm`, `gh`, anything POSIX)
• MCP for the things that need stateful auth, structured contracts, or services that don't expose a CLI.

Whats on the roadmap

Last week I released v2 MCP server that I had been working on and off for the last 6 months and as I experiment more with this new prototype the more I'm leaning in for yet another refactor v3.0 and bringing in what I've learnt with CLI driven LLM interactions into that project alongside a new rust core to further enhance performance but we will see how technology goes and how much time I can commit to these experimental projects..

If you're building agent-driven workflows against Oracle products and have your own take on the MCP-vs-CLI-vs-TUI architecture, drop me a message over at github..