Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin.

> There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this.

This problem is also solved by MCP.

Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working.

One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin.

Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.