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.

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.

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

Seems like unnecessarily constraining it.

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.

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

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).