> Problem 1: It Devours the Context Window
Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command.
> Problem 2: Low Operational Reliability
If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol.
> Problem 3: Overlaps with Existing CLI/API
Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP?
But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean).
> Provide CLI -> API -> docs, in that order
Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.
alt Hacker News
> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something?
I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed.
And I guess you can put some usage examples into the skill file. Which might migate the first --help.
Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?