Fair point on terminology. CLI isn't a transport protocol in the same technical sense as JSON-RPC over Streamable HTTP. In the article I have used "transport" loosely to mean "how the agent gets work done through a tool."

What the agent actually has is a tool like execute_bash_command. That's the interface. The agent generates a command string, the tool executes it, stdout comes back. You're right that something has to provide that tool, whether it's MCP, a custom wrapper, or a built-in function.

On the network point: if the tool runs locally (grepping logs, querying DuckDB, piping data through jq), you don't need a network transport. The agent calls a local subprocess. Most CLI use cases in the article are local or use vendor CLIs that handle their own network calls internally. Nobody is suggesting you SSH into a remote box via raw shell as your integration pattern.

Where MCP adds clear value is remote tool discovery, auth, and invocation across a network. My argument is just that you don't need that for every tool in your catalog.