I could not agree any less with the author. I don’t want APIs, I want agents to use the same CLI tooling I already use that is locally available. If my agents are using CLI tooling anyways there is no need to add an extra layer via MCP.

I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive.

If I need to call an API, a skill with existing CLI tooling is more than capable.

▲

TheTaytay 3 hours ago | parent | next [-]

I keep getting hung up on securely storing and using secrets with CLI vs MCP. With MCP, you can run the server before you run the agent, so the agent never even has the keys in its environment. That way. If the agent decides to install the wrong npm package that auto dumps every secret it can find, you are less likely to have it sitting around. I haven’t figured out a good way to guarantee that with CLIs.

	▲	Aperocky 2 hours ago \| parent [-]
		A CLI can just be a RPC call to a daemon, exact same pattern apply. In fact my most important CLI based skill are like this.. a CLI by itself is limited in usefulness.

▲

woeirua 3 hours ago | parent | prev [-]

Ok, but there are still many environments where an LLM will not have access to a CLI. In those situations, skills calling CLI tools to hook into APIs are DOA.

▲

egeozcan 3 hours ago | parent | next [-]

What are the advantages of using an environment that doesn't have access to a CLI, only having to run/maintain your own server, or pay someone else to maintain that server, so AI has access to tools? Can't you just use AI in the said server?

▲

daemonologist 3 hours ago | parent | next [-]

Obvious example is a corporate chatbot (if it's using tools, probably for internal use). Non-technical users might be accessing it from a phone or locked-down corporate device, and you probably don't want to run a CLI in a sandbox somewhere for every session, so you'd like the LLM to interface with some kind of API instead.

Although, I think MCP is not really appropriate for this either. (And frankly I don't think chatbots make for good UX, but management sure likes them.)

▲

nostrebored 2 hours ago | parent [-]

Why are they not calling APIs directly with strictly defined inputs and outputs like every other internal application?

The story for MCP just makes no sense, especially in an enterprise.

▲

ok_dad 2 hours ago | parent | next [-]

MCP is an API with strictly defined inputs and outputs.

	▲	nostrebored 2 hours ago \| parent [-]
		This is obviously not what it is. If I give you APIGW would you be able to implement an MCP server with full functionality without a large amount of middleware?

▲

woeirua an hour ago | parent | prev [-]

MCP really only makes sense for chatbots that don’t want to have per session runtime environments. In that context, MCP makes perfect sense. It’s just an adapter between an LLM and an API. If you have access to an execution engine, then yes CLI + skills is superior.

▲

DrJokepu 3 hours ago | parent | prev [-]

The advantage is that I can have it in my pocket.

	▲	Aperocky 2 hours ago \| parent [-]
		gateway agent is a thing for many months now (and I don't mean openclaw, that's grown into a disaster security wise). There are good, minimal gateway agents today that can fit in your pocket.

▲

hansonkd 3 hours ago | parent | prev | next [-]

idk, just have a standard internet request tool that skills can describe endpoints to. like you could mock `curl` even for the same CLI feel

	▲	woeirua an hour ago \| parent [-]
		Now you’ve replicated MCP but with extra steps and it’s harder to debug.

▲

yawnxyz 3 hours ago | parent | prev [-]

skills can have code bundled with them, including MCP code

	▲	woeirua an hour ago \| parent [-]
		The agent still doesn’t have an execution environment. It can’t execute the code!