upvote

points

by CamilleScholtz9 hours ago |
comments
upvoteby fnordsensei9 hours ago|
next
[-]
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.

reply
upvoteby charcircuit6 hours ago|
parent|
next
[-]
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?
reply
upvoteby jun_lung6 hours ago|
parent|
[-]
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?
reply
upvoteby charcircuit5 hours ago|
parent|
[-]
Versus having an agent read MCP config and fetch the existing tools every time it wants to use the MCP? It's duplicate functionality.
reply
upvoteby newtwilly3 hours ago|
parent|
[-]
The agent doesn't do that. The harness does the fetching and provides the tool definitions to the agent without the agent having to do anything.
reply
upvoteby charcircuit2 hours ago|
parent|
[-]
Nothing says that agents can't read skills, interpret them and fetch stuff. Needing to agent to pass things off to powerful LLMs to interpret doesn't have to be done for everything.
reply
upvoteby sthuck9 hours ago|
prev|
next
[-]
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

reply
upvoteby anthonypasq5 hours ago|
prev|
next
[-]
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.

reply
upvoteby james2doyle7 hours ago|
prev|
next
[-]
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.
reply
upvoteby charcircuit6 hours ago|
parent|
[-]
Why do think CLI programs can't store state (locally or on a server)?
reply
upvoteby athrowaway3z5 hours ago|
parent|
[-]
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.

reply
upvoteby charcircuit5 hours ago|
parent|
[-]
CLI support using oauth to authenticate via a browser too.
reply
upvoteby bob10297 hours ago|
prev|
next
[-]
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.
reply
upvoteby crooked-v4 hours ago|
prev|
next
[-]
Plenty of companies will supply an MCP that will never, ever provide a CLI command or free-floating API keys.
reply
upvoteby 0xbadcafebee5 hours ago|
prev|
next
[-]
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?
reply
upvoteby 0xbadcafebee5 hours ago|
prev|
[-]
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?
reply