MCP earns its keep in specific cases: when the agent has no shell access, when you need to keep credentials out of the prompt context, or when you want runtime tool discovery across teams. But I've built a few MCP servers and half of them would've been simpler as a CLI script the agent calls directly.

▲

TimTheTinker 4 hours ago | parent | next [-]

I've had good results from creating a command-line bash utility (and associated skill) that wraps and supplies credentials opaquely to a cli tool.

▲

cadamsdotcom 5 hours ago | parent | prev [-]

Why wouldn’t you just give the agent a shell (and by implication a sandbox)?

Seems like unnecessarily constraining it.

▲

arthurjean 4 hours ago | parent [-]

Most of the time you should. But it depends on what you're wrapping. Exa is a good example of where MCP makes sense, it's not just one API call, it's 4 different tools (web search, code search, crawling, advanced search) plus embedded skills for chaining them. One MCP connection and the agent discovers all of that at runtime. Doing that with a CLI means building a multi-command script and hoping the agent figures out the orchestration.

On the other hand, something like context7 is just `npx ctx7 resolve <lib>` then `npx ctx7 docs <id>` — two stateless shell calls, done. No server to maintain, no protocol overhead. CLI is the right tool there.

	▲	TimTheTinker 4 hours ago \| parent [-]
		Why not put all of that into a skill file? The context overhead from an MCP connection is significantly higher.