Dinesh Bhat 
There are four ways to ship the same capability in 2026: MCP servers, Skills, CLI tools, and MCP Apps. From the outside they look interchangeable. They really aren’t, and the teams getting this wrong are spending real engineering time building the same thing twice — once in the wrong surface, then again in the right one.
The question I keep coming back to, and the only one that actually decides the call, is: who is going to consume this?
If the capability needs to work across multiple AI clients, it is an MCP server
A database tool that I want available inside Claude Desktop, inside Cursor, and inside our own CLI agent gets built once and plugged in everywhere. The MCP server is the primitive: one implementation, many consumers. The protocol exists precisely because the alternative — building a slightly different integration into every agent surface — is exactly the kind of work that does not compound.
The signal for “this should be an MCP server” is simple. If you can describe the capability without referring to who is calling it, and if more than one kind of caller is plausible, it is an MCP server.
If you are encoding a workflow the agent should follow, it is a Skill
“Read the spec, write the failing test, write the minimum code to pass, in that order” is a Skill. It is procedural knowledge — how to do something — rather than raw capability. The agent already has all the capability needed to run a test or read a file. What the Skill provides is the rule for the sequence.
The mistake I see most often here is reaching for an MCP server when a Skill is what the work actually needs. If the agent can already do every step using primitives it already has, and what is missing is the discipline of doing them in order, you are building a Skill, not a capability.
If the consumer is a human at a terminal, a shell script, or CI, the CLI still wins
The point of a CLI in 2026 is not “use this when you do not have an AI agent.” The point is composability. A well-built CLI works inside shell pipelines, inside CI workflows, inside cron jobs, and inside the agent’s tool calls. Anything else that has to integrate with the surrounding Unix world ends up paying a tax that the CLI does not pay.
The CLI’s job is to be the thing that everything else can call. The agent can invoke it, the human can invoke it, and the build system can invoke it without anybody having to write an adapter.
If non-engineers need a UI on top of MCP capabilities, that is an MCP App
The MCP Apps layer exists for one reason: the agent didn’t need a UI, the human did. An operations user who needs to approve an expense, view a dashboard, or paginate through a list of campaigns is not going to do that work in a chat window. They need a surface. The MCP server underneath stays the same; the App is the part that wraps it in something a non-engineer can actually use.
If the people consuming the capability cannot or will not work in a terminal or a chat window, you need the App. Skipping it and asking those users to type structured prompts is the version of this mistake that loses you weeks.
The trap
The trap is treating these four as substitutes. They are not. They are four shipping surfaces for four different kinds of consumer, and the right move is almost always to identify the consumer first and let the surface fall out of that.
A useful sequence, if you are building all four around a single capability: start with the MCP server, because it is the primitive layer that everything else composes on top of. Then wrap it in a Skill if there is a workflow worth standardizing, a CLI if the Unix-shaped consumers need it, and an App if the humans demand a UI. The wrapping is cheap once the primitive is right.
Where do you draw the line between a Skill and an MCP server in your own work? I am still calibrating mine.
— Dinesh