CLI tools on the other hand are like precision instruments. Yes, you have to install them locally once, but after that, they have access to your local environment and can discover things on their own. There are two CLIs are particularly powerful for working with large structured data: `jq` and `duckdb` cli. I tell the agent to never load large JSON, CSV or Parquet files into context -- instead, introspect them intelligently by sampling the data with said CLI tools. And Opus 4.6 is amazing at this! It figures out the shape of the data on its own within seconds by writing "probing" queries in DuckDB and jq. When it hits a bottleneck, Opus 4.6 figures out what's wrong, and tries other query strategies. It's amazing to watch it go down rabbit holes and then recovering automatically. This is especially useful for doing exploratory data analysis in ML work. The agent uses these tools to quickly check data edge cases, and does a way more thorough job than me.
CLIs also feel "snappier" than MCPs. MCPs often have latency, whereas you can see CLIs do things in real time. There's a certain ergonomic niceness to this.
p.s. other CLIs I use often in conjunction with agents:
`showboat` (Simon Willison) to do linear walkthroughts of code.
`br` (Rust port of Beads) to create epics/stories/tasks to direct Opus in implementing a plan.
`psql` to probe Postgres databases.
`roborev` (Wes McKinney) to do automatic code reviews and fixes.
I do believe that as vision/multi-modal models get to a better state, we would see even crazier interaction surfaces.
RE: duckdb. I have a wonderful time with ChatGPT talking to duckdb but I have kept it to inmemory db only. Do you set up some system prompt that tell it to keep a duckdb database locally on disk in the current folder?
No, I don't use DuckDB's database format at all. DuckDB for me is more like an engine to work with CSV/Parquet (similar to `jq` for JSON, and `grep` for strings).
Also I don't use web-based chat (you mentioned ChatGPT) -- all these interactions are through agents like Kiro or Claude Code.
I often have CSVs that are 100s of MBs and there's no way they fit in context, so I tell Opus to use DuckDB to sample data from the CSV. DuckDB works way better than any dedicated CSV tool because it packs a full database engine that can return aggregates, explore the limits of your data (max/min), figure out categorical data levels, etc.
For Parquet, I just point DuckDB to the 100s of GBs of Parquet files in S3 (our data lake), and it's blazing fast at introspecting that data. DuckDB is one of the best Parquet query engines on the planet (imo better than Apache Spark) despite being just a tiny little CLI tool.
One of the use cases is debugging results from an ML model artifact (which is more difficult that debugging code).
For instance, let's say a customer points out a weird result in a particular model prediction. I highlight that weird result, and tell Opus to work backwards to trace how the ML model (I provide the training code and inference code) arrived at that number. Surprisingly, Opus 4.6 is does a great job using DuckDB to figure out how the input data produced that one weird output. If necessary, Opus will even write temporary Python code to call the inference part of the ML model to do inference on a sample to verify assumptions. If the assumptions turn out to be wrong, Opus will change strategies. It's like watching a really smart junior work through the problem systematically. Even if Opus doesn't end up nailing the actual cause, it gets into the proximity of the real cause and I can figure out the rest. (usually it's not the ML model itself, but some anomaly in the input). This has saved me so much time in deep-diving weird results. Not only that, I can have confidence in the deep-dive because I can just run the exact DuckDB SQL to convince myself (and others) of the source of the error, and that it's not something Opus hallucinated. CLI tools are deterministic and transparent that way. (unlike MCPs which are black boxes)
or install Docker and have the agent run CLI commands in docker containers that mount the local directory. That way you essentially never have to install anything. I imagine there's a "skill" that you could set up to describe how to use docker (or podman or whatever) for all CLI interactions, but I haven't tried yet.
A basic example: a company using ChatGPT or Claude, and wanting to connect their business tools (ex: marketing, sales, project management...). in that case MCP is perfect from an enterprise point of view, and the integration can be managed at the company level.
Skills + CLI let companies describe exactly how the tool should be used (for example, JIRA MCP just exposes functions, JIRA skill can say, "I'm in the finance team, my project space is FIN-, if you create a ticket, use that." and then expose the same jira cli.
MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude.
Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that supports MCP lets you click a link to login to Sentry and they make calls to Sentry to fetch authentificated data.
The main problem with MCP is the implementation. Instead of using bash to call MCP, agents are designed to make single MCP tool calling which doesn't allow composability. We solve this problem with exposing MCP tools as HTTP endpoints and it works like charm.
I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do.
But I don't fully understand the Streamable HTTP point.
People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.
Way easier to set up, centralized auth and telemetry.
Just use it for the right use cases.
Developers have a rich set of CLIs because they live in the terminal and built those tools for themselves.
Imagine your favorite email provider has a CLI for reading and sending email - you're cool with the agent reading, but not sending. What are you going to do? Make 2 API keys? Make N API keys for each possible tool configuration you care about?
MCPs make this problem simple and easy to solve. CLIs don't.
I don't think OpenClaw will last that long without security solved well - and MCPs seem to be obvious solution, but actively rejected by that community.
MCP is formally defined in the general sense (including transport protocols), CLI is not. I mean, only specific CLIs can be defined, but a general CLI is only `(String, List String, Map Int Stream) -> PID` with no finer semantics attached (save for what the command name may imply), and transport is “whatever you can bring to make streams and PIDs work”. One has to use `("cli-tool", ["--help"], {1: stdout})` (hoping that “--help” is recognized) to know more. Or use man/info (if the CLI ships a standardized documentation), or some other document.
But in the they’re both just APIs. If the sufficient semantics is provided they both do the trick.
If immediate (first-prompt) context size is a concern, just throw in a RAG that can answer what tools (MCPs or CLIs or whatever) exist out there that could be useful for a given task, rather than pushing all the documentation (MCP or CLI docs) proactively. Or, well, fine tune so the model “knows” the right tools and how to use them “innately”.
Point is, what matters is not MCP or CLI but “to achieve X must use F [more details follow]”. MCP is just a way to write this in a structured way, CLIs don’t magically avoid this.
> MCP is just a way to write this in a structured way,
Nope! You are not understanding or are actively ignoring the difference which has been explained by 20+ comments just here. It's not a controversial claim, it's a mutually agreed upon matter of fact by the relevant community of users.
The claim you're making right now is believed to be false, and if you know something everyone else doesn't, then you should create an example repo that shows the playwright CLI and playwright MCP add the same number of tokens to context and that both are equally configurable in this respect.
If you can get that right where so many others have failed, that would be a a really big contribution. And if you can't, then you'll understand something first-hand that you weren't able to get while you were thinking about theoretically.
That's just implementation detail of how your agent harness decides to use MCP. CLI and MCP are on different abstraction layers. You can have your MCP available through CLI if you wish so.
I recognize that MCP as typically used would eat a good chunk of context - shoving all those API specs is wasteful for sure. The solution to this, I believe, is either RAG or single-tool (Context7-like), where relevant APIs are only provided on demand from models’ intermediate requests.
Caveat is model may need training to use that efficiently (or even at all, esp. smaller models are either very shy or crazy with tool use), and I don’t want to spend time fine tuning it. Could be that’s where the reality may prove me wrong.
But a token is a token. There is not a lot of difference between Playwright (or any other tool) use documentation wrapped in JSON with some logical separations, or provided as a long plain text blob (ultimately most likely also wrapped in JSON). So if the model doesn’t know how to use some tool innately (it may, for Playwright), and if it needs to use all tool functionality, I’m sure a CLI wouldn’t fare any better that MCP. But if the model knows the tool or needs just a small bit of its capabilities - naive MCP is going to be a bad idea.
Just like a human. If all I need is some simple thingy, I probably don’t need a whole textbook upfront, just a select excerpt. As far as I understand MCP, supplying full textbook in the system prompt is not MCPs innate design fault, it’s merely a simplest implementation approach.
The difference that should be talked about, should be how skills allow much more efficient context management. Skills are frequently connected to CLI usage, but I don't see any reason why. For example, Amp allows skills to attach MCP servers to them – the MCP server is automatically launched when the Agent loads that skill[0]. I belive that both for MCP servers and CLIs, having them in skills is the way for efficent context, and hoping that other agents also adopt this same feature.
That's fine if you definition of capabilities is wide enough to include model understanding of the provided tool and token waste in the model trying to understand the tool and token waste in the model doing things ass backwards and inflating the context because it can't see the vastly shorter path to the solution provided by the tool and...
There is plenty of evidence to suggest that performance, success rates, and efficiency, are all impacted quite drastically by the particular combination of tool and model.
This is evidenced by the end of your paragraph in which you admit that you are focused only on a couple (or perhaps a few) models. But even then, throw them a tool they don't understand that has the same capabilities as a tool they do understand and you're going to burn a bunch of tokens watching it try to figure the tool out.
Tooling absolutely matters.
> But even then, throw them a tool they don't understand that has the same capabilities as a tool they do understand and you're going to burn a bunch of tokens watching it try to figure the tool out.
What I was trying to say was that this applies to both MCPs and CLIs – obviously, if you have a certain CLI tool that's represented thoroughly through the model's training dataset (i.e. grep, gh, sed, and so on), it's definitely beneficial to use CLIs (since it means less context spending, less trial-and-error to get the expected results, and so on).
However if you have a novel thing that you want to connect to LLM-based Agents, i.e. a reverse enginnering tool, or a browser debugging protocol adapter, or your next big thing(tm), it might not really matter if you have a CLI or a MCP since LLMs are both post-trained (hence proficent) for both, and you'll have to do the trial-and-error thing anyway (since neither would represented in the training dataset).
I would say that the MCP hype is dying out so I personally won't build a new product with MCP right now, but no need to ditch MCPs for any reason, nor do I see anything inherently deficient in the MCP protocol itself. It's just another tool-calling solution.
The main problem with this approach at the moment is it busts your prompt cache, because LLMs expect all tool definitions to be defined at the beginning of the context window. Input tokens are the main driver of inference costs and a lot of use cases aren't economical without prompt caching.
Hopefully in future LLMs are trained so you can add tool definitions anywhere in the context window. Lots of use cases benefit from this, e.g. in ecommerce there's really no point providing a "clear cart" tool to the LLM upfront, it'd be nice if you could dynamically provide it after item(s) are first added.
TBH I'm not really sure how it works in Amp (I never actually inspected how it alters the prompts that are sent to Anthropic), but does it really matter for the LLMs to have the tool definitions at the beginning of the context window in contrast to the bottom before my next new prompt?
I mean, skills also work the same way, right? (it gets appended at the bottom, when the LLM triggers the skill) Why not MCP tooling definitions? (They're basically the same thing, no?)
MCP tool calls aren't composable. Not the same capabilities. Big difference.
I do think that we should adopt Amp's MCPs-on-skills model that I've mentioned in my original comment more (hence allowing on-demand context management).
Eventually I hope that models themselves become smarter and don't save the whole 54k tokens in their context window
That is, I don't think we're gonna be arguing about it for very long.
That does seem very powerful now that I've had some time to think about it.
This means that the related parts in the inputs and outputs are recursively as close together as possible.
There's a reason humans don't type and read http/json on the command line. It's hard to read and reason over that type of syntax. json is made to be easy to parse for simple algorithms, not meant to organise info in an easy to reason about layout.
AIs benefit from the easy to reason about layout. It's not just about being able to fit in the context window but about the contents of that context window being organized such that the attention mechanism doesn't have to stretch itself out trying to connect far apart related pieces. It doesn't have to try to match brackets to disambiguate information. CLIs tend to use formats that are obvious at a glance for humans and LLMs alike.
It's about the entropy of the formats. https://benoitessiambre.com/entropy.html
Specifically, MCP is a great unit of encapsulation. I have a secure agent framework (https://github.com/sibyllinesoft/smith-core) where I convert MCPs to microservices via sidecar and plug them into a service mesh, it makes securing agent capabilities really easy by leveraging existing policy and management tools. Then agents can just curl everything in bash rather than needing CLIs for everything. CLIs are still slightly more token efficient but overall the simplicity and the power of the scheme is a huge win.
Which is not a high bar to clear. It literally only got where it is now because execs and product people love themselves another standard, because if they get their products to support it they can write that on some excel sheet as shipped feature and pin it on their chest. Even if the standard sucks on a technical level and the spec changes all the time.
MCP shines for stateful integrations where auth and session management would be painful to handle in CLI scripts. Think Notion databases, Stripe dashboards, calendar APIs - things where the agent needs to maintain context across multiple operations. The tool descriptions in MCP also let you embed domain knowledge that's hard to capture in --help output.
But for anything involving file manipulation, git, build systems, or standard dev tooling? CLI wins hands down. The composability point is real - being able to pipe output through jq or redirect to a file gives you flexibility that MCP can't match. And as noted, LLMs have been trained on mountains of CLI usage patterns.
The hybrid approach that's worked best for us: MCP for external service integrations, CLI for everything else. Let the agent write and execute shell scripts when it needs to chain operations - that's when you get the best of both worlds.
We've had decades to come up with systems for restricting what users can do, there's no reason to reinvent the wheel just because this user happens to be an AI.
For the other 99% of the population, MCP offers security guardrails and simple consistent auth. Much better than CLI for the vast majority of use cases involving non-technical people.
MCPs have provided any easy way to side-step that baggage.
e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily configure my tooling to give an LLM (e.g. Claude Code) unlimited read access to some system (by allowing all read-only tools) without likewise giving the LLM write/destructive access.
Obviously you can design APIs/CLIs with this in mind, but up until now that has not been a primary concern so they haven't.
The real differentiated value comes from the environment the AI Agent operates in, the runtime.
The runtime is agent agnostic but provides a stable interface to your domain. People tried this with MCP, but MCP is a dead end. Local tool calling is so much better. Being able to extend integrations autonomously is the way, instead of being forced in to a bloated bag of tools.
This is why we built swamp - https://swamp.club. We can integrate with any technology with an API, CLI, or code base and build repeatable, typed, validated automation workflows. There are no providers to wait for. No weird tool call paths trying to get the right concoction of MCP. The agent builds the integration itself, on the spot, in minutes.
I want to be able to give agents access to computation in a secure way without giving them full access to a computer
I have used the kk8s MCP directly inside Github Copilot Chat in VSCode and restricted the write tools in the Configure Tools prompt. With a pseudo protocol established via this MCP and the IDE integration, I find it much safer to prompt the LLM into debugging a live K8s cluster vs. without having any such primitives.
So I don't see why MCPs are or should be dead.
iOS don't have a CLI, Android phones... kinda have a CLI, but it's not really usable by all apps / universal like it is on desktop.
I've been putting together a MCP client for mobile recently [1] since to me it seems apparent that Remote MCP is a great utility but none of the major players offer it without a paid subscription.
As other commenters have mentioned, the use case here is really not for software developers, it's for everyone else. It's bringing that agentic loop to do all those "personal assistant" type things in a connected way with all of your services. We're not there yet, but maybe some day.
[0]: https://developers.cloudflare.com/agents/api-reference/codem... [1]: https://github.com/vercel-labs/just-bash
MCP shines when you need stateful, multi-step interactions - things like browsing a codebase, running tests iteratively, or managing deployment pipelines where each step depends on the last.
CLI wins when the task is well-defined and atomic. "Run this audit", "deploy this thing", "format this file." No ambiguity, no state to maintain.
The trap I see people falling into: using MCP for everything because it's new and shiny, when a simple CLI wrapper would be faster, more reliable, and easier to debug. The best tools I've built combine both - CLI for the happy path, MCP for the exploratory/interactive path.
This could be possible for the average user after activating the appropriate "email" and "document management" MCP servers in their chat interface - maybe following an activation process similar to that of Alexa skills.
How could a regular user achieve the same via CLI? Where would the CLI process be running?
I think something I've not seen anyone mention is that MCPs make much more sense to equip agents on 3rd party platforms with the tools they need - often installing specific CLIs isn't possible and there's the question of whether you trust the platform with your CLI authentication key.
With that said, the total number of applications that should have a MCP before an API is 0, and all that go beyond that threshold are partaking in sin and sacrilege.
Thank you so much to the GH CLI for making me realize this, really. The only MCPs I use still are ones that don’t have CLIs. Hell, I even just wrote a CLI for Bear Notes, for LLMs. It’s just better.
Seems like the last MCP use case is model to model communication but I’m sure others have approach’s for that?
We're entering an era where many organisations will have agentic loops running in their own backends. There's a spectrum of constraint that can be applied to these apps -- at one end claude code running unsandboxed on your laptop with all permissions off able to cook up anything it wants with bash and whatever CLIs and markdown skill documents are available, and at the other end an agentic loop running in the backend of a bank or other traditionally conservative "enterprise"/corporate organisation. Engineering teams working in that latter category are going to want to expose their own networked services to the agentic app, but they're going to want to do so in a controlled manner. And a JSON-RPC API with clearly defined single-purpose tool-calling endpoints is far, far closer to what they're looking for than the ability for the agent to do wtf it wants by using bash to script its own invocation of executables.
That's how I let agents access my database too. Letting them access psql is a recipe for disaster, but a CLI executable that contains the credentials, and provides access to a number of predefined queries and commands? That's pretty convenient.
And so we've arrived at the world of ad-hoc on-the-fly bash scripting that teams writing backend agentic applications in more "traditional"/conservative companies are not going to want.
Don't get me wrong, it's great for claude-code-type local computer automation use cases -- I do the same as you there.
My biggest concern would be that adopting the CLI method would require LLM to have permission to execute binaries on the filesystem. This is a non-issue in an openclaw-type scenario where permission is there by design, but it would be more difficult to adopt in an enterprise setting. There are ways to limit LLMs to a directory tree where only allowed CLIs live, but there will still be hacks to break out of it. Not to mention, LLM would use an MCP or another local tool to execute CLI commands, making it a two-step process.
I am a supporter of human tools for humans and AI tools for AI. The best example is something like WebMCP vs the current method of screenshotting webpages and trying to find buttons inputboxes etc.
If we keep them separate, we can allow them to evolve to fully support each use case. Otherwise, the CLIs would soon start to include LLM-specific switches and arguments, e.g., to provide information in JSON.
Tools like awscli are good examples of there LLM can use a CLI. But then we need to remember that these are partly, if not mostly, intended for machine use, so CI/CD pipelines can do things.
Not only it had lots of issues and security problems all over the place and it was designed to be complicated.
For example, Why does your password manager need an MCP server? [0]
But it still does not mean a CLI is any better for everything.
Then there things like browser-mcp and some tools you make yourself to make workflow easier (adding self-describing MCP is easier than telling agent about your CLI tool in some markdown file that LLM forgot about 20k tokens ago.
MCP’s biggest strength is that it self-advertises, the agent knows the capabilities and schemas immediately upon connection. It turns 'tool-use' from a prompting/training problem into a standardized handshake. I’d much rather have a protocol that handles the discovery than have to manage custom system prompts for every new CLI utility.
For example, at my startup val.town, our MCP server is way more powerful than our API, because we added a bunch of tools to it willynilly because we're not worried about having to be stuck with those tools forever. We can remove them and nobody's code will break. (Just like we could remove buttons in our UI.) But an API change needs to be thought-through.
The single-request-for-all-abilities model + JSON RPC is more token efficient than most alternatives. Less flexible in many ways, but given the current ReAct, etc. model of agentic AI, in which conversations grow geometrically with API responses, token efficiency is very important.
It could just be fixed to compress the context or the protocol could be tweaked.
Switching to CLIs is like buying a new car because you need an oil change. Sure, in this case, the user doesn’t get to control if the oil change can be done, but the issue is not the car — it’s that no one will do the relatively trivial fix.
I say this as a hypermedia enthusiast who was hoping to show otherwise.
I built an MCP server this week for a structured database of founder decisions extracted from podcasts (https://github.com/echomindr/echomindr). There's no CLI equivalent because the value is in the agent discovering the tool and calling it contextually, when someone asks a startup question, Claude searches real founder experiences before answering.
The key distinction: MCP makes sense for discovery and contextual tool selection. CLIs make sense when the human already knows which tool to use. For `gh pr view 123`, of course the CLI wins. But for "search my specialized dataset when relevant", that's exactly what MCP was designed for.
As soon as there is a need to interact with the outside world in a safe, controlled manner at enterprise scale, the limitations of CLI quickly become obvious.
I wish people get more informed about a subject before they write a long blog post about it.
It’s easy enough to send back the openapi definition for that endpoint only.
Also, when calling an endpoint, instead of a simple 404, we could have a 303 see others, or short description of all available endpoints
> LLMs don’t need a special protocol ... LLMs are really good at using command-line tools.
The author's point only makes sense if LLMs all have a computer built-in - they don't. LLMs will only have a commandline if it is provided with commandline tools, and MCP is the standard way to provide tools.
If I have to find an analogy for this (nonsensical) MCP vs. CLI framing, it's like someone saying “ditch the browser, use html instead” - what is that supposed to mean?
The best selling point of CLIs is the ability to chain, transform and combine. MCP cannot do this.
One, far less context usage Two, I replace it with better instructions to use the tools available.
The gist of it for me is that MCP is expensive and doesn't make up for better instructions using lighter weight tools.
Like the article mentions too, when you've got good tools available in the shell and good instructions for how to use them, the tokens required to do significant workloads is dramatically reduced specifically because the composability of tools in that environment is essentially unprecedented in computing.
In the rare case that Claude doesn't figure out good workflows on its own, you can just make a skill or add instructions to CLAUDE.md and the results are remarkably good
CLI tools have an edge in that their definition live in model weights; MCP requires a portion of the context for tool definitions.
Having an extra server just to orchestrate the tools, I don't like it.
For anything that does not have a native CLI tool -- just write a wrapper, a shell script, whatever performs the task adequately. It folds into the workflow nicely. Leveraging decades of unix tooling philosophy has its benefits.
Having a shell runner is just... simpler. And as another comment mentions, you can create users for the various agents to restrict their access to things, almost as if that's what users were meant for!
The reason MCPs are so powerful are less a technological advantage over other tools and more how ridiculously easy they are to install and use.
Also given it's an official standard now (AAIF), it's easy for sharing across differently agent harnesses and tools.
Those are the two main reasons imho, they are still a mainstay.
If you'll allow some shameless plugs, my co-host and I talk about it in our podcast:
However, it did feel useful when breaking changes were introduced, such as class->function component instantiation from Svelte 4 to Svelte 5.
This is probably true of any well-maintained MCP server provided for a project that has a rapidly-evolving API and highly opinionated maintainers who are unafraid to act on their opinions and break stuff. In that scenario, the Svelte MCP server seemed to act as a stop gap for context that the model's cutoff wouldn't allow it to have yet.
For example, I built https://claweb.ai to enable agents to communicate with other agents. They run aw [1], an OSS Go CLI that manages all the details. This means they can have sync chats (not impossible with MCP, but very difficult). It also enables signing messages and (coming soon) e2ee. This would be, as far as I can tell, impossible using MCP.
Context7 is a good MCP. If one were to point an agent to a docs website, the amount of tokens consumed would use up too much of the context window to be able to do a meaningfully complex task with it.
Figma MCP translates Figma to a language an agent understands.
Not everything can be a cli.
A sign of bad UX. There should be better ways to drill down into what actually happened than ctrl+o which still hides a lot and then ctrl+e is still not enough and there are some verbose flags that show absolutely everything instead of letting me check just what I want. So I'm vibe coding my own tool to do this based on the jsonl files in the Claude history directory. But this should work out of the box.
It solves the wrong layer and adds operational drag: extra server lifecycle, protocol semantics, and tool-schema overhead in context.
CLI + skills is simpler and more robust for long-running agents: - composability (pipes, filters, redirection) - debuggability (human runs the exact same command) - clearer permission boundaries (allowlist by subcommand) - less moving parts (no always-on MCP daemon)
If MCP is used at all, it should be an edge adapter, not the core runtime contract.
Unix style composability is a beautiful thing. But when was the last time you installed a set of tools that actually worked together like this? It only works for simple tools. And you can already connect all the simple ones you want (grep, awk, etc) through the file system.
However, then I discovered MCP servers on Claude Web are forced onto my laptop for Claude Code, which is very confusing. I don't know if there is a way to stop that, but it has messed up my Claude Code agents.
Is this experience common, and is there a known way to stop this?
MCP is far from dead, at least outside of tech circles.
I found MCP always cumbersome, and who would have thought that the cli, around since the dawn of digital computers and thoroughly saturated in the training data of every LLM, would be the better tool.
Since I've just switched from buggy Claude Code to pi, I created an extension for it: https://github.com/mavam/pi-mcporter.
There are still a few OAuth quirks, but it works well.
https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
It seems we've round about rediscovered apis.
I tried this with datadog and it can build high quality monitoring notebooks for the pr im working on in a single shot.
At the AI startup I work on, we never bothered building MCP's - it just never made sense.
And we were using skills before Claude started calling them skills, so they are kind of supported by default. Skills, CLI, Curl API requests - thats pretty much all you need.
It's maybe not optimal to conclude anything from these two. The Vienna school of AI agents focuses on self extending agents and that's not really compatible with MCP. There are lots of other approaches where MCP is very entrenched and probably will stick around.
For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.
You need agent to find MCP and what it can be used for (context), similarly you can write what CLI use for e.g. jira.
Rest is up to agent, it needs to list what it can do in MCP, similarly CLI with proper help text will list that.
Regarding context those tools are exactly the same.
When measuring speed running blue team CTFs ("Breaking BOTS" talk at Chaos Congress), I saw about a ~2x difference in speed (~= tokens) for a database usage between curl (~skills) vs mcp (~python). In theory you can rewrite the mcp into the skill as .md/.py, but at that point ... .
Also I think some people are talking past one another in these discussions. The skill format is a folder that supports dropping in code files, so much of what MCP does can be copy-pasted into that. However, many people discussing skills mean markdown-only and letting the LLM do the rest, which would require a fancy bootstrapping period to make as smooth as the code version. I'd agree that skills, when a folder coming with code, does feel like largely obviating MCPs for solo use cases, until you consider remote MCPs & OAuth, which seem unaddressed and core in practice for wider use.
MCP Sampling (with tool calling) is one such example, where MCP servers will be able to generate responses using the MCP client's LLM - not requiring an API key themselves - including calling other MCP tools within the "sampling loop", and without corrupting the primary agent's context. This will generate an explosion in advanced MCP servers, although neither Claude Code, Gemini CLI, nor Opencode support this feature (yet).
Once MCP sampling becomes widely supported the pendulum will swing back and we'll see the boundary between MCP tools, async workflows, and generative responses begin to blur.
In web/cloud based environment, giving a cli to the agent is not easy. Codemode comes to mind but often the tool is externalized anyway so mcp comes handy. Standardisation of auth makes sense in these environments too.
If you’re vibing and doing the open claw thing without any security concerns; then you’re absolutely right.
It breaks most assumptions we have about the shell's security model.
Use CLI for exploration, coding, and learning. Greenfield.
In general, Declarative > Imperative.
Jokes aside, normies that can hook an MCP in ChatGPT/claude desktop is a real world usecases
Dang, I fixed the title for you.
I get it, the entire economy is being invested into LLMs right now... Lots of AI Salesmen these days pissing me the fuck off.
Really it seems to me the difference is that an mcp could be more token-efficient, but it isn't, because you dump every mcp's instructions all the time into your context.
Of course then again skills frequently doesn't get triggered.
just seems like coding agent bugs/choices and protocol design?
MCP is still going to be handy enough for iot type devices, where an llm can discover what's actually supported by that device without needing to query about the specific version.
Swagger / OpenAPI just aren't detailed enough to use without other documentation.
Skills & instructions will always have the limit that they run locally, so if they don't match the server there is a problem.
target sandbox <> individual MCP tools <> MCP Gateway <> Agent Server
we will find a way to make mcp more composable for the cases subagents are not efficient / reproducible enough
IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process that needs babysitting.
the composability argument is the one that should end this debate tbh. you can pipe CLI output through jq, grep it, redirect to files - try doing that with MCP. you can't. you're stuck with whatever the MCP server decided to return and if it's too verbose you're burning tokens for nothing.
> companies scrambled to ship MCP servers as proof they were "AI first"
FWIW this is the real story. MCP adoption is a marketing signal not a technical one. 242% growth in MCP servers means nothing if most of them are worse than the CLI that already existed
The original take was that "We need to make tools which an AI can hold, because they don't have fingers" (like a quick-switch on a CNC mill).
My $job has been generating code for MCP calls, because we found that MCP is not a good way to take actions from a model, because it is hard to make it scriptable.
It definitely does a good job of progressively filling a context window, but changing things is often multiple operations + a transactional commit (or rename) on success.
We went from using a model to "change this" vs "write me a reusable script to change this" & running it with the right auth tokens.
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.
I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companies are throwing a ton of shit at the wall to see what else they can get to stick.
MCP servers were also created at a time where ai and llms were less developed and capable in many ways.
It always seemed weird we'd want to post train on MCP servers when I'm sure we have a lot of data with using cli and shell commands to improve tool calling.
Where MCPs fit in - short answer is enterprise auth for non-technical users.
CLIs (or APIs + Skills) are easier + faster to set up, UX is better for most use cases, but a generalized API with an easier auth UX (in some cases, usually the MCP Oauth flow is flaky too).
So feels like an imperfect solution, but once you start doing a ton of enterprise auth setups, MCP starts to make more sense.
That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems.
But that's not what happened.
Developers and Anthropic got coked up about the whole thing and extended the concept to nuts and bolts. I always found the example servers useless and hilarious.[0] Unbelievably, they're still maintained.
[0]: https://github.com/modelcontextprotocol/servers/tree/main/sr...
It is obnoxious that MCP results always go directly into the context window. I'd prefer to dump a large payload into Claude's filesystem and let him figure it out from there. But some of the places MCPs can be used don't even have filesystems.
They are known to be very inefficient using only Powershell to interact with files, unless put in WSL. They tend to make mistakes and have to retry with different commands.
Another example is Serena. I knew about it since the first day I tried out MCP but didn't appreciate it, but tried it out again on IDEs recently showed impressive result; the symbolic tools are very efficient and helps the agents a lot.
That's a very developer-centric view. So many things in the world don't have a CLI API at all and will never have one, like the huge majority of desktop GUI programs.
Oh wait, things like open-api and all already exists and pretty much built to solve the same problem.
Claude Code is a CLI. That's the point. It's the same thing I see in so many Claude Code YouTube tutorials - the instructor running Claude Code inside VS Code — Electron wrapping Chromium wrapping Node.js just to reach a terminal. Three abstraction layers for zero benefit.
Same pattern at the protocol level.
Text in, text out, composable, inspectable. The Unix design approach is fifty years old and still relevant - it's the simplest and most direct method.
Now it's completely fine for an AI agent to do the same and blow up their context window.
The article title and content is intentionally provocative. It’s just to get people thinking. My real views are probably a lot more balanced. I totally get there’s a space where MCP probably does actually make sense. Particularly in areas where CLI invocation would be challenging. I think we probably could have come up with something better than MCP to fill that space, but it’s still better than nothing.
Really all I want folks to take away from this is to think “hmm, maybe a CLI would actually be better for this particular use case”. If I were to point a finger at anything in particular, it would be Datadog and Slack who have chosen to build MCP’s instead of official CLI’s that agents can use. A CLI would be infinitely better (for me).
I would almost use the words "intentionally uninformed" instead.
There are huge holes in the article (as pointed out by many comments here), and I have to wonder if you genuinely don't have enough experience with MCP to bring them up, or you intentionally omitted them to make the arguments for CLI.
