Comment by rixed
12 hours ago
> 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.
> 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?
Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.
I like MCP, but most servers and harnesses just dump all of the tools into context each message. Also the default tutorials for everything around MCP say to dump tools this way.
It’s really hard to determine which tools an agent will need on the fly. The best idea I’ve seen was to do a “search tools” tool which an agent would use to find relevant tools, then have an “execute tool” tool which did what it says.
Alternatively, if you’re using an agent that’s good with code, give it something like “port of context” (pctx) which translates MCP tools into a JavaScript package so the agent can chain MCP tools together with code, and they can filter the data down to just what they need. I haven’t used this method much yet but soon I need to improve the MCP gateway in our cloud agent builder product so I’m going to try this one out soon myself.