CLI vs MCP. When direct execution wins.

An MCP server's tool definitions live in your agent's context window. Each tool eats 500–2,000 tokens just to exist — never mind the inputs and outputs. With 20 tools, that's 10–40k tokens of context permanently spent before the model has done anything. CLI tools are invoked through bash. The model sees the help output only when it asks for it. Token cost: 0 by default.

In production agent traces we see MCP tool calls fail roughly 28% of the time — malformed JSON-RPC, schema drift, server timeouts, version mismatches. Bash invocations of CLI tools fail near 0% as long as the binary exists and the args are valid. The feedback loop is also tighter: stderr is right there, no protocol layer to debug.

MCP requests cross JSON-RPC. Even on localhost, that's tens of milliseconds per call, plus serialization overhead. Bash calls are direct exec — microseconds. For an agent chaining 50 tool calls per task, that's the difference between 2 seconds and 0.05.

The Unix philosophy is the original tool calling: small programs that do one thing well, connected by pipes. cat | grep | jq | sort | uniq -c is composable in a way no MCP schema can match. CLI tools inherit decades of this ecosystem for free.

Three cases where MCP earns its complexity:

• You need typed inputs and outputs the model can introspect at parse time
• You're sandboxing untrusted tools and need a controlled IPC boundary
• The tool doesn't exist as a CLI and you don't want to build one

We index both. The directory has CLI tools and MCP servers side by side, because the right answer depends on the agent and the task. But our default recommendation is CLI-first: lower token cost, higher reliability, more composable, faster. Reach for MCP when CLI can't do the job.