MCP: Your API Is the Product. Everything Else Is a Client.

I keep seeing people say things along the lines of:

"Don't build an MCP server. Build a CLI."

I understand where that idea comes from. CLIs are familiar, easy to automate, easy to debug, and they fit into almost any engineering workflow without much ceremony. For a developer building tools, the command line is one of the fastest ways to prove out an idea and make it useful.

But I think framing this as "CLI vs MCP" misses the bigger architecture question. The decision should not start with the interface. It should start with where the real product lives.

Take a step back for a second and think about the system you are building. If the business logic lives inside your CLI, then yes, an MCP server probably feels like a second implementation. Same story if the logic lives inside your web app, or buried in whatever agent-facing wrapper you happened to build first.

That is the trap.

The API, or the core library behind it, should be the product. The CLI, MCP server, REST API, desktop app, web app, or whatever comes next are clients of that product. Once the system is shaped that way, adding a new interface stops being a rewrite and becomes another adapter.

Most of my side projects started as CLI-first because that was the most direct path. I wanted something I could run, test, script, and wire into a pipeline without spending a week making a UI. That worked well, and I still think it is one of the best ways to start a developer tool.

When MCP came along, I did not throw that work away. I added MCP as another client on top of the same core logic. The business rules stayed in the same place, the indexing code stayed in the same place, and the API surface stayed mostly intact. The adapter changed because the consumer changed.

That is why the "use CLI, not MCP" take feels strange to me. It treats the interface as the architecture. If your core logic is trapped behind a command line entry point, then sure, MCP may feel like extra work. If your core logic sits behind a clean internal API, then CLI and MCP can both exist without fighting each other.

A CLI Exposes Commands

A CLI is a great interface for humans and automation. You give it commands, flags, paths, config, and it gives you output. It fits well in terminals, scripts, CI/CD pipelines, cron jobs, local dev workflows, and those random one-off things engineers build at 1 AM because clicking through a UI one more time might send them over the edge.

A CLI tends to think in commands:

search
index
analyze
render
graph
export

That model is excellent when the caller knows what it wants and can express that intent through arguments. It is also easy to log, version, test, document, and reason about. There is nothing wrong with that model.

But a CLI is still a command interface. It is not designed to describe a full capability graph to an agent. It is not designed to expose structured resources, tool schemas, prompts, state, and relationships in a way another client can discover and compose.

You can make an agent call a CLI. That works. But then the agent has to understand the command, build the right arguments, interpret stdout, recover from failures, and infer structure from text. We have all done some version of that, and it can be useful, but it starts to feel like teaching a robot to read terminal tea leaves.

MCP Exposes Capabilities

MCP starts from a different place. It is not only about giving an agent a way to run a function. It gives a client a structured way to discover what a system can do, what inputs those actions expect, what resources are available, and how those pieces can be used together.

A CLI says:

Here are my commands.

An MCP server says:

Here are my tools, here is what they do, here are the schemas, here are the resources, here is the context, and here is how you can interact with the system.

That may sound like a small difference until you start building with it. Once the agent can discover the shape of the system instead of guessing at it, the interaction changes. You stop treating the model like a shell user and start treating it like a client with a real contract.

That is the part I think gets lost in the debate. MCP is not remote CLI execution with a fancy name. It is a protocol for exposing capabilities in a way that agents and applications can reason about.

The Interesting Part Is the Application Layer

I have been building MCP applications in CodeMind that go well beyond "run this command." The first version of the idea was pretty basic: let an agent search code, inspect symbols, follow references, and answer questions against an indexed repository.

That was useful, but it did not take long before text output started feeling like the wrong medium. Code architecture is visual. Execution flow is visual. Redux state, dependency graphs, package drift, ownership boundaries, and pull request impact all make more sense when you can see them.

So the MCP work started turning into applications.

Interactive architecture visualizers that render dependency graphs from code indexes. Execution-flow explorers that let an agent trace a request across repositories. Redux state graphs that show actions, thunks, listeners, reducers, selectors, and who touches what. Semantic search across codebases. PR review assistants with visual navigation. Dependency analyzers that can explain the impact of a package upgrade before someone finds out the hard way in CI.

Those do not feel like command wrappers to me. They feel like tools built for a world where humans and agents are both using the same system from different angles.

The agent can gather context, call tools, and produce the first cut. The human can inspect the graph, question the relationships, follow the flow, and decide what matters. That is a much better workflow than asking an LLM to dump another wall of markdown into chat and hoping the important parts are in there somewhere.

Humans Still Belong Here

One thing I think people get wrong about MCP is assuming it only exists for agents. In the tooling I have been building, the best experiences are the ones that give the agent and the human something shared to work with.

The agent can create the artifact. The human can explore it. The agent can then respond to what the human finds. That loop feels closer to pair programming with a toolsmith than asking a chatbot for a report.

For example, if I ask CodeMind to visualize an execution flow through a service, I do not want a paragraph describing the system. I want the graph. I want to click a node, inspect a handler, follow the call chain, and then ask the agent why a certain path exists. That is where MCP starts to feel like an application platform instead of a function-calling layer.

This is also why I like having humans under the MCP server in the diagram. The human is not talking to the protocol directly in the same way an agent might, but the human is still consuming an MCP-powered experience. The agent and the UI are both clients of the same capability layer.

That feels important.

Build the Product Once

None of this is an argument against CLIs. I love building them, and I think most backend or developer-focused systems benefit from having one. A good CLI gives you a clean operational surface area. It forces you to think about inputs, outputs, config, errors, and repeatability.

The mistake is treating the CLI as the product.

If you build the product as a core library or API, then the CLI becomes one client. MCP becomes another. REST or Web becomes another. That keeps your logic in one place and lets each interface do what it is good at.

The CLI can serve humans, scripts, and CI/CD. The MCP server can serve agents, visual applications, and interactive workflows. The web app can serve users who need dashboards, forms, search, or reporting. Each client gets the interface that makes sense without forcing the whole system to contort around it.

That is the architecture I would rather build.

Where This Goes Next

Right now, a lot of the MCP conversation sounds like "AI can call my functions." That is useful, but I do not think it is the destination. Function calling is the starting point, not the interesting part.

The interesting part starts when agents can launch rich interfaces, stream progress, maintain state, render graphs, expose resources, build artifacts, and collaborate across tools in a way humans can inspect. At that point, MCP starts looking less like a command runner and more like a foundation for application experiences.

That is where I think the surface area opens up. Not "how do I let an LLM run my CLI?" but "how do I expose my system so humans and agents can work with it together?"

From where I sit, that is the part we have barely started exploring.

Thanks

/J