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.