I agree with you for common CLIs that the model will natural have in its training set, but when building your own CLI it seems like the self-documenting nature and progressive disclosure of MCP would have a huge advantage.
With a cli you don’t have the prefix cost, but your agent also doesn’t know that the tool exists, what it’s for, how to use it, etc. once you give it that information, then you have the same issues with prefix cost, right? Changing tools does break the prefix cache, but changing tools is a thing you can do. You can’t change (model awareness of) CLI, and if you could then it’d also break the prefix cache, or you’d have tool instructions scattered throughout the context without structure.
Dumping to file is a harness thing, not a MCP thing. A harness will do the same with large terminal outputs.
Likewise setting up a new CLI can be complicated. I never see an agent try to install an mcp, but I also don’t typically see it try to install a new CLI.

I don’t see how mcp is any more a fixed set of tools than CLI is. It’s just presented to the agent in a structured way, which is important for discovery and instruction following.

But yeah ease of chaining is certainly useful wrt CLI. That’s a huge win for sure.

Can you elaborate on LLMs using CLI more effectively than MCP? Do you have any sense of how likely it is just your domain or the MCPs you’re using? Do you have any theories about why that may be?

You’re telling me you go everywhere with your dedicated camera, and you never find yourself with only your phone camera wanting to take pics? What an asinine argument.
And pixel binning is great, what are you talking about?

The illusion of choice.

If you want the good camera, you need to get the giant version of the phone.

If you want a phone that fits in human hands, you can only choose from subpar cameras.