A good CLI is still worth building. We built one for Docsalot. But a CLI does not remove the need for MCP. In some ways it makes the remaining problem more obvious.
The reason is simple: once you ship a CLI, you own distribution.
Not just the npm package or the README. The actual operational surface. macOS. Linux. Windows. Node versions. PATH issues. Shell behavior. Desktop clients that do not want a shell at all. Users who are not comfortable in a terminal. Every one of those becomes part of the product whether you wanted it or not.
That is the part people skip when they say "why not just expose a CLI?"
A CLI is one interface. MCP is a protocol.
That difference matters a lot.
What the CLI Solves
A CLI is great when the user is already technical and already in a shell.
For Docsalot, our CLI gave us a clean workflow for:
- authenticating with API tokens
- listing documentations
- pulling docs locally
- pushing docs back as a version
- publishing a version
- previewing docs locally
That is a real product surface. It is useful. It also maps well to agents that can run terminal commands.
If the world stopped there, we could have just kept improving the CLI.
But it does not stop there.
What the CLI Does Not Solve
A CLI does not magically become universal just because it exists.
To make it broadly usable, you still have to answer questions like:
- How do we distribute this cleanly across macOS, Linux, and Windows?
- What runtime assumptions are we making?
- What happens when the user's shell environment is weird?
- What happens when a desktop AI client does not want to manage a local binary?
- What happens when the person updating docs is not technical enough to debug
PATH,npx, or Node versions?
We ran into exactly this kind of friction while testing the MCP path through desktop clients.
Even when the Docsalot server was fine, the local environment could still fail in annoying ways:
- an old
npxbeing picked from the wrong Node install - a client resolving the wrong
nodebinary fromPATH - a remote bridge working on one machine and failing on another
None of those are really "documentation problems." They are packaging and runtime problems.
That is the hidden tax of a CLI-first distribution model.
The Distribution Problem Is Worse Than It Looks
When people say "just ship a CLI," they usually mean "technical users can figure it out."
That is often true. It is also a weak standard if you want broad adoption.
A CLI means you are effectively shipping multiple operational experiences:
- one for macOS users
- one for Linux users
- one for Windows users
- one for whoever has the wrong language/runtime version installed
- one for whoever is trying to call your tool through an AI desktop app instead of a shell
Even if the commands are logically the same, the support burden is not the same.
You do not just have one product anymore. You have the combinatorics of product × operating system × runtime × client behavior.
That is manageable for a small technical audience. It is not a great default if your goal is: "connect once and let any compatible client use the workflow."
What MCP Changes
MCP gives you a stable protocol surface instead of asking every user to adopt your local runtime assumptions.
That is the key point.
With a remote MCP server, the client only needs to know how to speak MCP. The server owns the implementation details. The auth model is explicit. The tool schemas are explicit. The request/response format is explicit.
For our Docsalot docs-management flow, that means we can expose:
list_documentationspull_documentationpush_documentationpublish_documentation
as one authenticated surface at /api/cli/v1/mcp.
Now the integration problem shifts from:
"Can this user install and run our binary correctly on this machine?"
to:
"Can this client talk MCP?"
That is a much better question.
It is narrower. It is more standard. It ages better.
Why This Matters Specifically for Docsalot
Docsalot is not just serving docs to engineers in terminals.
We also care about:
- coding agents operating documentation directly
- desktop MCP clients
- less technical users making documentation updates without learning a CLI
- workflows that should behave the same way across different environments
If we stayed CLI-only, we would keep paying the binary tax forever.
That means:
- more packaging work
- more support work
- more environment debugging
- more platform-specific docs
- more chances for "works on my machine" to become part of the user experience
MCP does not make all integration problems disappear. It does remove one big class of them.
Instead of shipping the same docs-management workflow as multiple binaries and hoping each client environment behaves, we can expose one protocol surface and let MCP-compatible clients connect to it.
That matters even more when the user is not technical.
If a product manager, support lead, or founder can connect through a desktop app and update docs without touching a shell, that is not a nice-to-have. That is a real expansion of who can use the system.
This Is Not an Argument Against CLIs
CLIs are still useful.
In our case, the CLI still matters for:
- local preview
- terminal-native workflows
- direct automation
- users who want explicit command-level control
The point is not "MCP replaces the CLI."
The point is that a CLI and an MCP server solve different distribution problems.
The CLI is for users who want to run your workflow locally. MCP is for users and clients that want a stable protocol surface without inheriting your packaging story.
Those are not the same thing.
The More Honest Framing
I think the more honest way to talk about MCP is this:
MCP matters when you want one interface to work across many clients without shipping your implementation details to every user environment.
That is the win.
For Docsalot, that means we can keep the CLI for local power users and still expose docs management through a protocol that works across MCP-native clients.
That gives us:
- less cross-OS binary overhead
- less environment-specific breakage
- better compatibility with desktop clients
- a more accessible path for non-technical users
Or, more bluntly:
Connect once, communicate forever is a better distribution model than shipping the same docs workflow as a growing pile of binaries.