If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own?
MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc..
cli tools aren't aware of the context window either, they're not keeping track of it. I might want my cli tool to output lots of useful text but maybe I don't want some of that for the LLM to save on tokens. Sure, I could create another cli tool to wrap my cli tool, now i have two cli tools to maintain. I'd prefer to do all the wrapping and pre-llm cleanup done in one consistent place. The instructions for the LLM letting it know what tools, parameters,etc.. are available is also defined in a consistent way, instead of me inventing my own scheme. I'd rather just focus on getting a usable agent.
I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.
Doesn’t an MCP server require running a process for the endpoint? A CLI tool doesn’t have this problem.
It is also easier to write and debug CLI tooling, and other human devs get to benefit from the CLI tools. MCP includes agent instructions of how to use it, but the same can be done with skills or AGENTS.md (CLAUDE.md) for CLI.
I mean technically I could be using cli tools to browse HN as well I guess. curl would do fine I suppose, but that'd be too annoying. Why not use the best tool for the task. as far as I'm concerned an stdio MCP server is a cli tool, it just happens to be an integration layer that can run either other cli tools, or do other things as it makes sense.
And FFS! I know jq can do wonderful things, but I'd seriously question anyone's competency if you're building a production code base that relies on a tangled mess of jq piping commands when you could just write a python function to parse, validate and process the content. And don't get me started with the risks of letting an agent running commands unchecked. What happens when your agent is running your cli tool using user-input arguments and you forgot to make sure command-injection won't be a thing? That can happen with MCP as well, but in many cases you shouldn't just run cli commands, you would call libraries, apis, process data files directly instead. You wouldn't call the sqlite3 command when you can just use the library/module.
MCP does not make things more organized. Everything is a file, and the filesystem is a mature infrastructure that we can trust. I don't see how MCP can be more organized than it.
curl is a great example of what CLI can do. Is there really a better way than curl for AI to browse HN?
Of course we should use Python or other sane scripts rather than shell to process JSON in production, but there is no need to hide the script in an MCP server. Also I don't see how it's easier to sandbox an MCP server than the CLI tools.
However, MCP can make sense when connecting to a complex GUI app; especially one that provides visual output. The example here would be Figma.
> Is there really a better way than curl for AI to browse HN?
Yes, curl can't render the DOM and HN requires captcha when registering. WebMCP is a better way!
Authorization, in my opinion, is the big problem you need MCP for, though the current MCP Authorization spec still needs some refinement.
MCP in its default state takes up too much context, creating the new for "MCP as code", which seems a bit circular.
Unlike cli flags, with MCP I can tune the comments for the tool more easily (for my own MCPs at least) than a cli flag. You can only put so much in a cli --help output. The error handling and debugability is also nicer.
Heck, I would even favor writing an MCP tool to wrap cli commands. It's easier for me to ensure dangerous flags or parameters aren't used, and to ensure concrete restrictions and checks are in place. If you control the cli tools it isn't as bad, but if you don't, and it isn't a well known cli tool, the agent might need things like vague errors explaing to it a bit.
MCP is more like "REST" or "GRPC", at the simplest level just think of it as a wrapper.
You mentioned redirecting to files, what if the output is too much that way, you'll still burn tokens. But with MCP, if the output is too much you can count the tokens and limit, or... better yet you can paginate so that it gets some results, it sees how many results there are and either decides to re-run the tool with params that will yield less results, or consume the results page-by-page.