Comment by CamilleScholtz
4 days ago
I don't understand MCP still? What can MCP do that a skill + cli can't? I've been using hax (https://usehax.dev) and haven't missed skills at all to be honest.
4 days ago
I don't understand MCP still? What can MCP do that a skill + cli can't? I've been using hax (https://usehax.dev) and haven't missed skills at all to be honest.
As a provider, I can add a tool or change instructions on my MCP server, and you'll get it on your next connection, sometimes even mid-session.
With a skill, updates depend on whatever channel delivered it to you. Whichever channel that is, it's out of my hands as a provider.
So, MCP solves the problem of coordinated distribution of updates to a larger subscriber base. Think inside of a company, for example. I don't have to go around and tell people to `git pull` their skills folder.
How is this different from a skill giving you are a URL to another skill file where you can find an up to date list of everything that is available?
Because why should you have to load "here's how to update this skill!" information into the context window every time you use it? Would you expect the agent to go to that URL and look for more recent skill files every time you use it? Is this a real question?
3 replies →
[dead]
Im sure there are more reasons but updates to prompts and tools coming from the server side is a major one.
It's typed so you can build some governance around it, by allowing only some tools or parameters for your org (this is a pretty weak point, but still)
A skill has one giant description from the frontmatter loaded into the context, where MCP loads a smaller one for every tool. Not necessarily better, the skill approach is often better actually, but sometimes the MCP approach fits more
not all agents have access to a terminal. not all agents are coding agents. a cli is a versioned piece of software that the user has to update to get new features. APIs can change in the background and add new capabilities.
MCP's have all the same advantages that a rest api has over a cli.
MCP is like Docker or Kubernetes. If you are operating at a certain level of abstraction (low), these tools look like they are getting in the way more than they are helping. For others, they will seem absolutely mandatory. It depends on what your goals and constraints are with the project.
The biggest win for me is they can have state. So you can log in to an MCP (via oauth) and not worry about having to refresh tokens locally or in the ENV. I use it for Trello. I log in, then I can call all the data about my board. No CLI to install, no token to copy-paste somewhere. It just opens a browser tab to log in when required, next, next, next, and it works.
Why do think CLI programs can't store state (locally or on a server)?
Your cli is slightly different than how a LLM uses it. We use 'export' and 'cd' to store state. LLMs dont do that generally.
There is an argument for and against having the model repeat this state.
I'm still on team CLI in that i think even designing an interface from the CLI perspective gets you a better domain interface compared to when you can 'cheat' with the MCP state.
But the thing MCP is just better at is credentials.
The thing that _was_ the dealbreaker between CLI and MCPs is that MCP's couldn't be composed. Maybe `codemode` fixed this; haven't tried enough to say 1 way or another.
1 reply →
To explain, let me rephrase the question: what can a standard API and remote server do, that a local program and AI-hallucinated text file can't do?
My customers (non technical people) don’t know how to install a CLI. They’ve never opened a terminal. But they can use an MCP. That’s the main difference.
To rephrase the question: what can a standard API and remote server do, that a local program and AI-hallucinated text file can't do?
Plenty of companies will supply an MCP that will never, ever provide a CLI command or free-floating API keys.