MCPs can potentially have great value if they cross multiple sources and combine results. For example at work we use an in-house MCP for log/metrics search across five different (legacy) systems. It finds correlation across events in different system within minutes.
https://medium.com/@ravi.madabhushi/mcp-is-up-to-32-more-exp...
There are many more aspects, but even with GitHub MCP, where the agent has a huge amount of pre-training on the CLI, there are still reasons why people use it extensively - you don’t hear it a lot here but suffice to say usage never stopped growing to this day.
I think if CLIs are working for you then good, I also like our cli and did some work on it too, like adding gh skill subcommand.
Do use what works, and measure and improve - but this article is not doing justice to the MCP server IMHO.
Is that why I have to constantly remind Claude and ChatGPT that they do have access to a Github plugin that can access my account, instead of trying and failing to use the gh cli?
Expect more on this. We are looking at the problem.
Yes, an agent with CLI access and access to making HTTPS calls is a lot more efficient for most tasks, but also a lot more unpredictable and with much higher blast radius if it starts misbehaving compared to one that only have access to exactly the tools and data sources you want it to use.
Technically it’d work just as well to have a thin API wrapper or cli tool the agent is allowed to access.
They do exactly what I want and how I want it. They expose just the information and the features I want the LLM to have. And just like in your case, it combines multiple sources of information into 1 response.
cli tools are a natural fit for llms.
MCP and RAG feel like the usual pattern of running a daemon 24/7 that balloons infrastructure spend. So uncivilized.
Any given REST API is a small model. A frontier or local model and modern harness can parse the already existing documentation for that REST API and invoke or generate a tool to use it.