I agree. MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow.

People make the argument that it doesn't matter for non-programmers. I use Bluebeam (a pdf editor which is standard in the construction industry) daily, and it has an MCP, but a big problem is that if the agent wants to import or export a large amount of data from a document, then it has to regurgitate a bunch of tokens into or out of the MCP. If it were a CLI, then it would just pipe things in and out as it needs.

I ended up just having the agent make a script that wraps the MCP so it can use it as a CLI instead.

▲

insin 3 hours ago | parent [-]

> MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow

Tool calls being composable or not are a property of the harness being used, not of MCP servers

	▲	pama 2 hours ago \| parent [-]
		As a trivial counterpoint, streaming outputs and proper signaling support is required for being able to compose efficiently under any setup/harness. The more layers of abstractions you add, the more likely it is your MCP server didn't support the usecase that some later agent came up with and so you can't stop your stream when you find your top 3 hits. If you don't even own the server, you can't even modify the source and restart it to fix it. There are usecases of MCPs (e.g. serving outside customers via proprietary tools), but composability has not been in the minds of the early users of MCP and it is one of the hundreds of little practical drawbacks they have when used in house.