[arthurjean]

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]

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.

[arthurjean]

Same here. It's not airtight, the agent could technically read the wrapper or env vars, but in practice it doesn't bother. Good enough for most setups.

[cadamsdotcom]

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

Seems like unnecessarily constraining it.

[arthurjean]

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]

Why not put all of that into a skill file? The context overhead from an MCP connection is significantly higher.

[arthurjean]

You're right actually. Exa's MCP server is stateless, just a REST wrapper. A skill + CLI would do the same job with way less context cost. Someone already built that (https://github.com/tobalsan/exa).