MCPs (especially remote MCPs) are like a black box API -- you don't have to install anything, provision any resources, etc. You just call it and get an answer. There's a place for that, but an MCP is ultimately a blunt instrument.
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 have also found this as well. CLI outputs text and input text in an interactive manner, exactly the way that is most conducive to text-based-text-trained LLM.
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?
> 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.
It seems that the author thinks that AI use is limited to developers, I don't understand how short slighted is the debate between CLI and MCP. Sure, CLI are more convenient, but currently most AI users consume LLM through online tools like ChatGPT
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.
This. I work with lots of business users who don't even know what a CLI is. They just want company apps to be connected to a (secure/managed) LLM and interact with those apps via a chat interface. So, MCP definitely has a place for the overwhelming majority of knowledge workers who aren't tech-savvy like developers.
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.
There is nothing wrong with MCP, it's just that stdio MCP was overengineered.
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.
Could you expand on this some more? I'm not quite following.
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.
I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes.
People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.
CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.
That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.
I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.
Very good points, but, I think this blog is pretty focussed on the developer use case for LLMs. It makes a lot more sense in chat style interfaces for connecting to non-dev tools or services with non technical users, if anything just from a UX perspective.
Thank you, I was going to say something like this. I've been reading all the comments here and thinking, "do ChatGPT/LeChat/etc even allow running CLIs from their web or mobile interfaces?".
Exactly. and even if so, how are you going to safe guard tool access?
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.
Supposedly, you make a Skill for it, but even that is out of scope for chat agents. I didn't scroll far, but I wouldn't be surprised more people in this thread have made the mistake of giving that answer.
This is like comparing OpenAPI and strings (that may be JSON). That is, weird, and possibly even meaningless.
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.
CLI tools are designed to provide complete documentation using —help. Given LLMs are capable of fully understanding the output then how is the MCP standardization any better than the CLI —help standardization?
I would spend less time with theory and more time with practice to understand what people are getting at. MCP and CLI could, in theory, be the same. But in practice as it stands today, they are not.
> 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.
> 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
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.
Please, please, please actually do this yourself or read any of the top comments. You are still missing the point, which you will understand if you actually do this and then look at the logs.
Fair enough, I’ll give it a try when I’ll have time for it.
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.
I'm rooting for you, to be clear! It sounds like your approach is more sophisticated than the average, and this is a pain point that is starting to get a lot of attention.
I can't believe everyone is talking about MCP vs CLI and which is superior; both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities. CLIs might be marginably better (LLMs might have been trained on common CLIs), but MCPs have their uses (complex auth, connecting users to data sources) and in my experience if you're using any of the frontier models, it doesn't really matter which tool calling format you're using; a bespoke format also works.
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.
> 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...
> 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 MCP server is automatically launched when the Agent loads that skill
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.
> 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.
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?)
No, it really matters because of the impact it has on context tokens. Reading on GH issue with MCP burns 54k tokens just to load the spec. If you use several MCPs it adds up really fast.
The impact on context tokens would be more of a 'you're holding it wrong' problem, no?
The GH MCP burning tokens is an issue on the GH MCP server, not the protocol itself. (I would say that since the gh CLI would be strongly represented in the training dataset, it would be more beneficial to just use the CLI in this case though.)
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).
MCP specs are verbose json objects and they have to go into the context before you can call them. So yes it is an issue with the fundamental design of the protocol.
Even if the model doesn’t already know the cli commands it can interrogate them at a much lower token cost for just the commands needed.
Verbosity of the output seems orthogonal to the cli vs mcp distinction? When I made mcp tools and noticed a lot of tokens being used, I changed the default to output less and added options to expose different kinds of detailed info depending what the model wants. CLI can support similar behavior.
MCP needs to be supported during the training and trained into the LLM whereas using CLI is very common in the training set already. Since MCP does not really provide any significant benefits I think good CLI tools and its use by LLMs should be the way forward.
This is very developer centric. While Github might have good CLI, there's absolutely no point in having most services develop CLIs and have their non-technical users install those. Not only is it bad UX, but it's bad from security perspective as well. This is like arguing that Github shouldn't have GraphQL/Rest api since everyone should use the CLI.
Yeah, I've gotta use skills more. I didn't quite get it until this last week when I used a skill that I made. I didn't know the skill got pulled into context ONLY for the single command being ran with the skill, I thought the skill got pulled into context and stayed there once it was called.
That does seem very powerful now that I've had some time to think about it.
One underrated reason that CLIs are often better than MCP is that Unix tools seem to have close to information theoretically optimal layout to enabled reasoning. They are concise, in the Solomonoff/Kolmogorov sense.
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.
There's been an anti-MCP pro-CLI train going for a while since ~May of last year (I've been personally beating this drum since then) but I think MCP has a very real use case.
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.
Running both MCP and CLI-based agents in production, my take is that this isn't an either/or question.
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.
I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.
>we can expect it to get much better than it is today
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.
You could strip away 90% of the spec and it would be even more useful. In fact standardizing the tool definitions and prompt formats would probably have done more if you're serious about supporting a certain set of tools between various LLM providers.
The token budget angle is what makes this a real architectural decision rather than a philosophical one.
I've been using both approaches in projects and the pattern I've landed on: MCP for anything stateful (db connections, authenticated sessions, browser automation) and CLI for stateless operations where the output is predictable. The reason is simple - MCP tool definitions sit in context permanently, so you're paying tokens whether you use them or not. A CLI you can invoke on demand and forget.
The discovery aspect is underrated though. With MCP the model knows what tools exist and what arguments they take without you writing elaborate system prompts. With CLI the model either needs to already know the tool (grep, git, curl) or you end up describing it anyway, which is basically reinventing tool definitions.
Honestly the whole debate feels like REST vs GraphQL circa 2017. Both work, the answer depends on your constraints, and in two years we'll probably have something that obsoletes both.
Yup. I’ve been using CLIs with skills that define some common workflows I use and then just tell Claude to use —help for understanding how to use it. Works perfectly and I end up writing the documentation in a way that I would for any other developer.
As far as I'm aware, all of the benefits of MCP over CLI go away if you just bother to run your agents as OS users with locked down permissions such that they only have access to secrets for similarly locked down users on remote systems.
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.
The opposite is true. CLI based integration does not exist in a single consumer grade ai agent product that I’m aware of. CLI is only used in products like Claude Claude and OpenClaw that are targeting technically competent users.
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.
One key aspect that is missed here, is mobile users.
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.
AI Agent's like Claude Code are an arms race to the bottom. Just like frontier model quality, they all converge on feature sets over time (plan mode, skills, remote execution, sandboxing, etc.,) and opencode is holding its own, preferred even, in a lot of cases.
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.
This feels misguided. MCP is still one of the best ways to execute deterministic sub-flows (i.e., stepwise processes) and secure tooling that an LLM would either lose itself while executing or should never access directly.
Im still struggling with understanding when MCP works better. I move everything to cli after a while. Can you give me more concrete examples? Because I don’t doubt you, I just don’t understand.
Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access.
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.
That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.
I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).
Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.
Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?
I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield).
An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to be more "agent compatible".
Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.
You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.
But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.
It's the security layer that I'm most interested with MCPs. Granting full access to the CLI feels super dangerous and maybe there are options to certain commands that I want to restrict from LLM usage.
state. i'm not sure if they had that in mind but one keyword that is important here is: state. Sure CLI tools can also affect state, but in MCP service it's somewhat more natural?
Imagine asking to your favorite LLM the following: "get the document attached to the most recent email from Joe and then upload it into my document management system in a new folder within archive 'Important', make sure to name the folder based the topic of the document following the naming convention already in place for folders in the same archive"
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?
As a counter argument to the kubectl example made in the article, I found the k8s MCP (https://github.com/containers/kubernetes-mcp-server) to be particularly usefuly in trying to restrict LLM access to certain tools such as exec and delete tools, something which is not doable out of box if you use the kubectl CLI (unless you use the --as or --as-group flags and don't tell the LLM what user/usergroup those are).
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.
I somehow agree with this but want to add my two cents here. Cloudflare's Codemode[0] is a great "replacement" for MCP because AI is trained for writing code and handling errors. But it also doesn't fix security and sandboxing. For CLI and file operations we have Vercel's just-bash[1] but for everything else there is no safe solution. Therefore MCP still makes sense until somebody sandboxes this part as well without needing to use Cloudflare or something.
Every MCP vs CLI argument I've seen really glosses over _where_ the agent is running, and how that makes a difference. For individual users where you're running agents locally, I totally agree that CLIs cover the vast majority of use cases, where available.
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.
I've been building tools that use both approaches and the answer really depends on the context.
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.
Most of what the article says is true regarding coding agents, but articles like this are making a big mistake: they're completely forgetting that agentic applications aren't all claude code.
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.
Sure, but it's pretty trivial to generate a CLI application that talks to that API.
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.
Yes. But are you letting your agent make the decision of when and how to call that CLI? And presumably you're invoking it via the Bash tool. In which case your agent is free to write ad-hoc bash orchestration around your CLI calls. And perhaps you don't just have one such CLI but rather N for N different services.
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.
Okay, MCP is useless if the agent has full CLI access, sure. But what if it's a remote cloud agent connecting to another equally remote service. Well, now I need to install said CLI tool. What if I dont want to install a local mcp server either (which was always a stupid idea), and I want for there to be an harness around what the agent can do instead of give it a whole API?
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.
Most of this thread is debating MCP as a CLI wrapper, and for that it's clearly worse. More tokens, no piping, another process to manage.
But the real use case for MCP isn't replacing git or jq. It's giving agents persistent state across sessions. When I close the terminal my agent forgets everything. What it was working on, what it decided, what it tried that failed. Next session starts from zero.
An MCP server that holds structured project state -- tasks, decisions, context -- lets the agent pick up where it left off. It queries what happened last session, updates progress, records new decisions. That's fundamentally different from running a CLI command and parsing stdout. You need a server that maintains state and exposes typed operations on it.
The framing should be: CLI for stateless operations (builds, git, file manipulation). MCP for stateful integrations where the agent needs memory that outlives the session.
I think that's a fair argument. I'd push back a bit on that being unique to MCP. Agent browser (https://github.com/vercel-labs/agent-browser) handles persistent sessions just fine as a CLI.
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?
I understand the argument, and there are some really good points.
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.
The problem with CLIs is that unless it's a super well documented CLI like `gh`, the LLM will have a hard time figuring out how to use it from `--help` alone unless it's a really simple tool. If you want to do something complex, like create a JIRA issue, you either need to put the full issue schema in `--help` so that the LLM knows how to pass an issue or else you can use MCP which bakes tool schemas into the protocol.
That's easily solved by wrapping it in a skill. And every time it fails, once you are done you ask it to update the skill with what it learned. A couple iterations later and it will be solid.
I've yet to play with Emacs MCPs thoroughly. Having said that, after initial exposure to agent skills directing agents to just use CLI/emacsclient, I no longer think I need to go deeper into MCP. emacsclient via CLI has been working remarkably well. Did a little video on that https://www.youtube.com/watch?v=ymMlftdGx4I
You actually answered your own question: "If a tool genuinely has no CLI equivalent, MCP might be the right call."
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.
The important part of MCP (that this misses) is that it's a machine interface you can quickly iterate on. In other words, an API is too slow-moving. You can't break it; it's a promise. A UI is too annoying for an LLM to deal with. An MCP is the perfect middleground: speaks JSON, but there's inference involved, so if you change the tools, the LLM will be just fine. (Just like how you can change your UI much faster than you change your API, because there's inference at runtime, ie in the human brain.)
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.
You use MCP to provide dumb-down API that LLM can consume. It's not that hard. If you MCP server is 1:1 map to your REST - you're doing it wrong.
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 solves a very specific problem: how do you ship a LLM’s tool/function so that it is callable by an LLM in an inter-process manner (so that you don’t need to modify OpenAI’s code to make your tool available in ChatGPT)? CLIs concern what happens inside such tools, namely a `bash` tool. As you can see they are different layers of the same stack.
> 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?
MCP has one thing going for it as an agentic API standard: token efficiency
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.
But the flip side of this is that the tools themselves take up a ton of token context. So if you have one mcp it’s great but there is an upper bound that you hit pretty quick of how many tools you can realistically expose to an agent without adding some intermediary lookup layer. It’s not compact enough of a spec and doesn’t have lazy loading built into it
Yes but I consider that just a bug in the agents that use MCP servers.
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.
But they're not token efficient. Take the terraform example from the post. Plan JSON is massive. You're not saving tokens by using a Terraform MCP and shoving an entire plan into context. Composition allows for efficient token use.
I've been creating a cli tool with a focus on token efficiency. Dont see why cli could not be as token efficient as mcp. The cli has the option to output ascii, markdown and json.
I'm working on a paper on this, if you are using a hypermedia-like system for progressive revelation of functionality you are likely to find that this chatty style of API is inefficient compared with an RPC-like system. The problem is architectural rather than representational.
I say this as a hypermedia enthusiast who was hoping to show otherwise.
the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.
So far, cli --help seems to work quite well. I'm optimizing the cli to interact with the agent, e.g., commands that describe exactly what output is expected for the cli DSL, error messages that contain DSL examples that exactly describe the agent how to fix bugs, etc. Overall i think the DSL is more token efficient that a similar JSON, and easier to review for humans.
fair point on token efficiency -- dsls are usually tighter than json. where i see mcp still winning is tool discovery: the client learns what tools exist and what args they take without having to try calling them first or knowing the commands upfront. with cli you have to already know the tool exists.
If the author is just using Claude Code on their own personal computer, they can do whatever they want.
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.
I haven't been able to make a coherent argument against MCP, so I've settled for "I just don't like it".
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!
These are all evolving technologies and it's pretty evident that the big AI labs are trying different things to see what sticks. Some of it does and they keep evolving it.
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:
The only MCP server I use is Svelte's and every time I use it, I feel as though I'm just spamming my context window for little to no reason. I mostly only use it when I'm unsure about something.
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.
My success with LLMs has increased quite a bit since I stopped using MCP servers. I credit it to a couple things:
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
For me, GitHub CLI is the prime example of this. This CLI is so incredibly powerful when combined with regular command line tools. Agents know how to use head, tail, jq and so on to only extract the parts it needs.
The best selling point of CLIs is the ability to chain, transform and combine. MCP cannot do this.
This author gets it. Ignore MCP, WebMCP, etc and instead build for humans like we always have. If LLM providers want usage they can push models to engage with tools like a human does - read docs, use a11y features, and when in doubt `--help`.
I keep asking why the default Claude tools like Read(), Write(), Edit(), MultiEdit(), Replace() tools aren’t just Bash() with some combination of cat, sed, grep, find. Isn’t it just easier to pipe everything through the shell? We just need to figure out the permissions for it.
Because the Tools model allows for finer grained security controls than just bash and pipe. Do you really want Claude doing `find | exec` instead of calling an API that’s designed to prevent damage?
not for every user or use case. when developing of course i run claude —-do-whatever-u-want; but in a production system or a shared agent use case, im giving the agent least privilege necessary. being able to spawn POSIX processes is not necessary to analyze OpenTelemetry metric anomalies.
yeah, I would rather it did that. You run Claude in a sandbox that restricts visibility to only the files it should know about in the first place. Currently I use a mix of bwrap and syd for filtering.
Making those tools first-class primitives is good for (human) UX: you see the diffs inline, you can add custom rules and hooks that trigger on certain files being edited, etc.
I’ve found that humans are pretty good at reading through the output of bash commands. And Claude Code keeps insisting on truncating the output for some reason.
One clear use case where MCP is better than anything else: design system documentation for an enterprise, or using a specific UI library. Daisy UI has an example: https://github.com/birdseyevue/daisyui-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.
The skill-based approach has been a game changer for me. Instead of wrestling with MCP server configs, I just write a small markdown file describing the CLI tool and its common use cases. The agent loads it on demand when it detects the tool is relevant. Much simpler than maintaining a running process, and the documentation lives right next to my code rather than in some separate server config. The composability argument is what really sold me - piping through jq, chaining commands, redirecting to files... that's stuff I do daily and never have to think about.
Reports of MCP's demise have been greatly exaggerated, but a CLI is indeed the right choice when the interface to the LLM is not a chat in a browser window.
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.
When we give LLM access to the terminal, LLM doesn't need anything else. LLM already knows all the commands, and there's no need to waste context on MCP. When we tell it to use a new command, it can get `--help` as needed.
> CLIs have had decades of design iteration. They’re composable, debuggable, and they piggyback on auth systems that already exist. MCP tried to build a better abstraction. Turns out we already had a pretty good one.
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.
Strong take: MCP is the wrong default for agent runtimes.
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.
> When Claude does something unexpected with Jira, I can run the same jira issue view command and see exactly what it saw. Same input, same output, no mystery.
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.
> This is where the gap gets wide. CLIs compose. I can pipe through jq, chain with grep, redirect to files. This isn’t just convenient; it’s often the only practical approach.
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.
This is actually the first use case where I agree with the poster. really interesting, especially for technical people using ai. why would you spend time setting up and installing an mcp server when u can give it one man page
Some developers started asking a custumer of mine for a MCP server. They don't have one. They have an API on Postman (docs and examples) so they are exporting it as JSON and sending it to those developers. It might work but it's not what those developers want and maybe they will go to another similar service. So useless or not the availability a MCP server could be part of marketing and a checkbox on a due diligence sheet.
The only place MCP made sense for me, so I thought, was to give my Claude Web agents access to the same cli tools my Claude Code agents had. In this context, agents don't have shells.
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?
I've been thinking about this a lot lately in terms of my personal clauding, and it's hard for me to think of a scenario where an mcp server makes more sense than CLI tools and AGENTS.md. But if you're deploying an agentic product, it's probably different. Seems like you could just deploy little Bash sandboxes for each customer. Or you could deploy mcp servers. The latter feels much easier to reason about in terms of attack surface and potential side effects.
Remote MCP solve the distribution problem just like everyone uses web apps for everything nowadays instead of desktop apps. Local MCP servers make as much sense as local web apps.
?? I'm using my own remote MCP server with openclaw now. I do understand the use case for CLI. In his Lex Friedman interview the creator highlights some of the advantages of CLI, such as being able to grep over responses. But there are situations where remote MCP works really well, such as where OAuth is used for authentication - you can hit an endpoint on the MCP server, get redirected to authenticate and authorise scopes etc and the auth server then responds to the MCP server.
Agree. MCP isn't really required. Skills/CLI/API is good enough.
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.
If you’re going this far, why even have a cli? Just have your agent grab the openapi spec from the server and set envvars. It can curl its way around happily. Security? I don’t see how this is any more or less secure than any other claude code workflow.
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.
In terms of what companies are actually implementing, MCP isnt dead by a long time. Number of companies with a MCP server grew 242% in the last 6 months and is actually accelerating (according to Bloomberry) [1]
Right, but even if this is just a matter of "chasing a trend", it does have a network effect and makes the entire MCP ecosystem much more useful to consumers, which begets more MCP servers.
I've found MCP is great for stacking claude code instances- https://github.com/cduerr/stewardmcp has legit been a useful tool for me, and more reliable than handing a single instance 100k lines of code over a dozen repos.
Somewhat. The stewards (sub-Claudes) won't share their parents context window and have the ability to talk to one another. That said I'm sure there's a lot out there that solves for this.
MCP Servers are not simple wrappers around REST APIs, they can do much more and we will see more advanced use-cases surrounding MCP as MCP clients continually improve their conformance to the spec. Just wrapping REST APIs may be what MCP Servers are now, but that's just because MCP clients still need to catch up in supporting these more advanced features.
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.
I've come to the same conclusion as op, created a CLI tool to work with Chrome sessions. It works well, and I'm planning to do some token comparison on this vs an MCP approach. https://news.ycombinator.com/item?id=47207790
It does so many things though, very similar in the core though. I'm wondering what the token counts will be when I compare. Also the agent browser seems to support other browsers too, I only when with chromium
What if you want to build a third party integration to connect to Claude Chat or Cowork? Those can't run arbitrary CLIs. The only way to integrate with them is via MCP.
For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.
This will happen with GUIs as well, once computer-use agents start getting good. Why bother providing an API, when people can just direct their agent to click around inside the app? Trillions of matmuls to accomplish the same result as one HTTP request. It will be glorious. (I am only half joking...)
Half joking, sure, but the "click around the app" problem is already real for teams running browser automation at scale. The issue isn't the clicks themselves - it's that every Chrome instance looks identical to a bot detector the moment you spin up ten of them from the same machine. The fingerprint (canvas, WebGL, navigator properties, etc.) is basically screaming "I'm automated".
Dealing with this from the ops side: the headache isn't writing the automation, it's keeping each browser session isolated enough that sites don't treat them as the same entity. MCP or CLI doesn't really change that underlying problem.
> OpenClaw doesn’t support it. Pi doesn’t support it.
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.
MCPs are useful to deploy internally as an agent tool gateway for your organization or customers. That's a totally different use case than how most of us interact with agents (claude code / cursor). That said, there's only limited benefit over just using OpenAPI.
This doesn't really pay attention to token costs. If I'm making a series of statically dependent calls I want to avoid blowing up the context with information on the intermediary states. Also, I don't really want to send my users skill.md files on how to do X,Y & Z.
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.
But that's the current primary use case for AI. We aren't anywhere close to being able to sanitise input from hostile third parties enough to just let people start inputting prompts to my own system.
there's a whole world of AI tools out there that don't focus on developers. These tools often need to interact with external services in one way or another, and MCP gives those less technical users an easy way to connect e.g. Notion or Linear in a couple of clicks, with auth taken care of automatically. CLIs are never replacing that use case.
For personnal agents like claude code, clis are awesome.
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.
Even for Openclaw, the response API is a better way to interact with it adhoc. I tell Cursor how to contact OC with a bearer key, and they work things out in the background when I'm building something for Openclaw.
I’ve noticed Claude Codes sandbox mode works with MCPs. With CLIs I’ve rain into permission issues. CLIs also need reminding about whats available unless references are baked the context window.
I don't understand the CLI vs MCP. In cli's like Claude Code, MCPs give a lot of additional functionality, such as status polling that is hard to get right with raw documentation on what APIs to call.
Also when they use cli you can learn from it and sometimes, next time you’ll be faster if its just a simple edit compared to an ai that first has to understand relevant context.
MCP is worth it when you need standardized, safe, observable tool calls across many systems; for single-purpose workflows, a CLI stays simpler and more debuggable.
IMO the biggest issue with CLIs for agents is to know when the agent is allowed to type. When is the command fully proceed, and next tokens can now be generated.
Biggest downside of CLI for me is that it needs to run in a container. You're allowing the agent to run CLI tools, so you need to limit what it can do.
It gets significantly harder to isolate the authentication details when the model has access to a shell, even in a container. The CLI tool that the model is running may need to access the environment or some credentials file, and what's to stop the model from accessing those credentials directly?
It breaks most assumptions we have about the shell's security model.
Such a mechanism would need to be implemented at `execve`, because it would be too easy for the model to stuff the command inside a script or other executable.
on the other hand, MCP/tools style lets me run specialized agents without needing to give them a bash-like unix environment. Vercel makes a fake bash simulator but if i’m trying to run an agent that analyzes production telemetry, it’s a hell of a lot easier to do that safely with just MCP
Is it just me or is hackernews being flooded with overhyped AI "Discoveries". Only thing that changes is what data is being trained on it or the interface. I come here for interesting computer science/systems related content.
I get it, the entire economy is being invested into LLMs right now...
Lots of AI Salesmen these days pissing me the fuck off.
This is the dumbest most myopic take I’ve seen in awhile. MCP servers aren’t just used for geeks using Claude Code. If I have an app in production that uses an MCP server what is he suggesting? That my LLM create a shell script and run it inside of a Docker container?
This take is so incredibly short sighted. Sure mcp is not perfect and needs better tooling and a bit updated standards, but clis are >maybe< just the future for agents that are clis themselves but i would argue these agents will be not the mainstream future but a niche i call "low level system agents" or things for coding bros. An agent of the future needs to be way more secure, auditable, reasonable and controllable none of which is possible by slapping a cli with execution rights into a container even with a bubblewrap profile. An agent of the future will run in a sandbox similar to cloudflare workers/workerd isolate with capabilities. The default will be connecting one central MCP endpoint to an agent that runs in its own sandbox without direct access to the systems it works on. The MCP gateway handles all the things that matter, connecting LLM providers, tokens for APIs, enforcing policies, permission requests, logging, auditing, threat detection and also tools. Tools execute on the container level, so there is not even a need to change anything about any existing containerised workloads, its all transparently happening in the container realm. I am not saying system level agents have no use but any company running anything like kubernetes or docker compose will have zero need or tolerance for an agent like that.
what honestly is the difference between an mcp and a skill + instructions + curl.
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?
The difference is that the server gives a description of the api it understands in enough detail that the llm can make use of it.
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.
> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit
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
MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!
> The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves.
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.
Strongly disagree, despite that meaning I'm swimming upstream here.
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.
This is what I've been working on. I've written a project wrapper CLI that has a consistent interface that wraps a bunch of tools. The reason I wrote the CLI wrapper is for consistency. I wrote a skill that states when and how to call the CLI. AI agents are frequently inconsistent with how they will call something. There are some things I want executed in a consistent and controlled way.
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.
that's what the MCP server is, except I don't always want a cli.
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.
It does not, your MCP server can be a small python file, your agent would execute it as a process and use stdio to communicate with it. You can also run it as an HTTP server, but if it's all on the same machine, I don't see the point. I'm pretty sure in under 15 loc of python you can wrap subprocess.check_ouptput as an stdio MCP server for example to let your agent run any commands or a specific command.
Because that is a consistent and reliable way of doing it? what happens when I have to use something that can't be done via cli, or if I have lots of small use cases (like I sometimes do with MCP servers - lots of tiny functions), do I create a separate readme for each of them and manage the mess? what exactly is the issue with MCP? is it too well organized?
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.
There are certainly things can't be done via CLI, or more suitable for a persistent daemon with various RPC rather than a CLI. But most things are simpler than that, and MCP is overcomplicating it.
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.
Maybe I don't understand how other people are using MCP, if it is for code generation agents, that I can't speak of. but for your own agent code, for me at least an MCP server is much easier to use than running commands directly.
> 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!
If you do that, you end up with all the problems that MCP attempts to solve: how to authorize using a standard mechanism, how to summarize operations in a better way than just dumping the OpenAPI spec on the LLM, providing structured input/output, providing answers to users that the LLM cannot see (for sensitive data or just avoiding polluting the context) and so on.
Authorization, in my opinion, is the big problem you need MCP for, though the current MCP Authorization spec still needs some refinement.
I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used.
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.
For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me.
We don’t use the cloud versions, so not sure if they work better with cloud.
On the other hand, i found some unofficial CLIs for both and they work great.
I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
I deal with a ton of different atlassian instances and the most infuriating thing to me about the mcp configuration is that atlassian really thinks you should only have one atlassian instance to auth against. Their mcp auth window takes you to a webpage where you can’t see which thing you are authoring against forcing you to paste the login page url into an incognito window. Pretty half baked implementation.
I noticed that it’s better for some things than others. It’s pretty bad at working with confluence it just eats tokens but if you outlay a roadmap you want created or updated in Jira it’s pretty good at that
I have had some positive experiences using the Jira and Confluence MCPs. However, I use a third-party MCP because my company has a data centre deployment of Jira and Confluence, which the official Atlassian MCP does not support.
My use case was for using it as an advanced search tool rather than for creating tickets or documentation. Considering how poor the Confluence search function is, the results from Confluence via an MCP-powered search are remarkably good. I was able to solve one or two obscure, company-specific issues purely by using the MCP search, and I'm convinced that finding these pages would have been almost impossible without it.
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.
It’s telling the best MCP implementations are those which are a CLI to handle the auth flow then allow the agent to invoke it and return results to stdout.
But even those are not better for agent use than the human cli counterpart.
How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.
I've been running Claude Code in a Docker compose environment with two containers - one without Claude that has all the credentials setup and a Claude container which transparently executes commands via ssh. The auth container then has wrappers which explicitly allow certain subcommands (eg. `gh api` isn't allowed). The `gh` command in the Claude container is just a wrapper script which bassically `ssh auth-container gh-wrapper`.
Lots of manual, opinionated stuff in here, but it prevents Claude from even accessing the credentials and limits what it can do with them.
I’ve been testing with an ENV variable for a cli tool for LLMs that I’m making. Basically, I have a script that sets an ENV variable to launch the TUI that I want and that ENV variable changes the behavior for LLMs if they run it (changes the -h output, changes the default output format to json to make it easier to grep)
None of those work when dealing with external services, I wouldn’t even trust them as a solution for dealing with access to a database. It seems like the pushback against MCPs is based on their application to problems like filesystem access, but I’d say there are plenty of cases in which they are useful or can be a tool used to solve a problem.
Interestingly think I just came to the opposite conclusion after building CLIs + MCPs for code.deepline.com
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.
In my experience, a skill is better suited for this instead of an MCP.
If you don’t want the agent to probe the CLI when it needs it, a skill can describe the commands, arguments and flags so the agent can use them as needed.
They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands
Fwiw I'm having a good experience with a skill using Jira CLI directly. My first attempt using a Jira MCP failed. I didn't invest much time debugging the MCP issues, I just switched to the skill and it just worked.
Yes occasionally Claude uses the wrong flag and it has to retry the command (I didn't even bother to fork the skill and add some memory about the bad flag) but in practice it just works
Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now.
I'm good, yet my coworkers keep having problems using the Atlassian MCP.
Even if the help isn't great, good coding agents can try out the cli for a few minutes and write up a skill, or read the sources or online docs and write up a skill. That takes the spot of the --help if needed. I found that I can spare quite a lot of time, I don't have to type up how to use it, if there is available info about it on the web, in man pages, in help pages, or the source is available, it can figure it out. I've had Claude download the sources of ffmpeg and blender to obtain deeper understanding of certain things that aren't much documented. Recent LLMs are great at quickly finding where a feature is implemented, how it works based on the code, testing the hypothesis, writing it up so it's not lost, and moving on with the work with much more grounding and fewer guessing and assumptions.
Using the source code to ask questions about poorly documented features in projects you have no experience is my favourite thing that LLMs make possible (of course you could do this before but it would take way, way more time). There are so many little annoyances that I’ve been able to patch and, thanks to NixOS, have the patched software permanently available to me.
In fact NixOS + LLMs feels like the full promise of open source software is finally available to me. Everything is within reach. If you don’t like something, patch it out. If you want to change a default, patch that in.
No need to know the language, the weird build process, or the custom tooling. Idea to working binary in minutes. I love it so much.
Yes, the idea that you can meaningfully modify the program for your own purposes (one of Stallman's four freedoms) was quite unrealistic except for the most skilled and invested among users. LLMs change this. I mean, as long as you use open models. I fear that in the future, corporate models may start to refuse building software like this that is inconvenient for them. Like possible future-Gemini saying, "oh I see you're patching chromium to continue working with adblockers, this is harmful activity, I cannot help you and reported your account to Google. Cease and desist from these plans or you lose your Gmail!"
Today is the honeymoon phase, enshittification will come later when the pie stops growing and the aspect of control comes more into focus.
It's just too good to be true. Most people still don't know that you can now do what you just described. Once people in the suits understand this, the propaganda will start about how unsafe this all is and that platforms must be locked down at the hardware level, subscriptions cut off if building unapproved software etc.
> 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.
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.
We have a lot of tools (starting with the internal wiki) which are normally only exposed to engineers through web interfaces; MCPs make them available to terminal agents to use autonomously. This can get really interesting with e.g. giving Claude access to query logs and metrics to debug a production issue.
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.
Because "him" is objectively wrong, under almost any interpretation of any words involved. You can cause Claude, or any text-based LLM, to emit language that matches almost any personality / gender / character in the training set. At best you might be able to say "the default outputs have a masculine tone / vibe", but this still doesn't justify, by modern discourse, the "him".
The use of "him" by GP is extremely unusual IMO, and I suspect is odd for anyone with English as their native language. The current convention among normal people seems to me to be to avoid pronouns other than "it" with these tools, and generally just use the name. The name is not really relevant: like, sure, in some contexts we think of ships as "she/her", and may prefer feminine names for them, but if you used e.g. "she" rather than "it" to refer to the Titanic or any other ship with a female name, this is going to cause some double-takes / disfluent comprehension in the vast majority of native speakers in most cases.
Only if you imagine e.g. some stereotypical pirate with an eyepatch slapping the hull and saying something like "Aye, but she weathered the storm, as she always does" might this feel normal. Or, maybe if you are a Redditor and trying to make it your AI boyfriend / girlfriend, you can use he/him or some other neo-pronoun, but this is currently abnormal and not the general context.
And the fact that you can make the model act as any gender again shows why choosing "him" as some default here is strange. Absent any specific context, the choice of "him" here is poorly justified.
The GPTs are "it" because they were deliberately named in a way to discourage anthropomorphizing them. Anthropic does want you to anthropomorphize Claude, and they gave their model a male name. It's not that deep!
I'll just disagree with an example: Codex on Windows.
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.
Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.
And your most common command sequences can be dropped into a script that takes options. Add a tools.md documenting the tools and providing a few examples. How many workflows need more than maybe two dozen robust scripts?
When is MCP the right choice though? For example - letting internal users ask questions on top of datasets? Is it better to just offer the api openapi specs and let claude run wild? or provide an MCP with instructions?
If you want to build an AI app that lets people “do random thing here”, then build an app.
Peak MCP is people trying to write a declarative UI as part of the MCP spec (1, I’m not kidding); which is “tldr; embed a webview of a web app and call it MCP”.
MCP is just “me too”; people want MCP to be an “AI App Store”; but the blunt, harsh reality is that it’s basically impossible to achieve that dream; that any MCP consumer can have the same app like experience for installed apps.
Seriously, if we can barely do that for browsers which have a consistent ui, there was never any hope even remotely that it would work out for the myriad of different MCP consumer apps.
It’s just stupid. Build a web app or an API.
You don’t need an MCP sever; agents can very happily interact with higher level functions.
While I do agree that MCP was probably bit too far from whats required, there is some benefit for sure. Providing information in a consistent format across all the services makes it easier work with. It lowers the brittleness of figuring out things making the products built using LLMs more stable/predictable. Most importantly it becomes the latest version of the documentation about a service. This can go a long way in M2M communication, pretty much standardization of Application layer.
Oh wait, things like open-api and all already exists and pretty much built to solve the same problem.
This was my gut from the beginning. If they can't do "fully observable" or "deterministic" (for what is probably a loose definition of that word) -- then, what's the point?
Funny. Dealing with Kubernetes is my day job, and I can be equally critical of it. Pointing out absurdities is how we make things better, and that’s ok.
Hi friends! Author here. This blew up a bit, so some words.
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).
Thank you for writing this. I've had similar thoughts myself and have been teetering back and forth between MCP and skills that invoke CLI. I'm hoping this creates a discussion that points to the right pattern.
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.
I get it. This is coming from a place where I see MCP's being adopted, where CLI is (in my opinion) better. Particularly where you're already in a CLI environment, and tool composition is necessary. I'm sure there's plenty of folks that aren't operating in that environment.
MCPs (especially remote MCPs) are like a black box API -- you don't have to install anything, provision any resources, etc. You just call it and get an answer. There's a place for that, but an MCP is ultimately a blunt instrument.
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 have also found this as well. CLI outputs text and input text in an interactive manner, exactly the way that is most conducive to text-based-text-trained LLM.
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?
> 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)
> you have to install them locally once
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.
Unrelated, but as a non native English speaker it's funny to me that you use MCPs (plural) to refer to MCP tools.
It seems that the author thinks that AI use is limited to developers, I don't understand how short slighted is the debate between CLI and MCP. Sure, CLI are more convenient, but currently most AI users consume LLM through online tools like ChatGPT
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.
This. I work with lots of business users who don't even know what a CLI is. They just want company apps to be connected to a (secure/managed) LLM and interact with those apps via a chat interface. So, MCP definitely has a place for the overwhelming majority of knowledge workers who aren't tech-savvy like developers.
MCP isn't good for enterprise.
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.
Underrated comment
There is nothing wrong with MCP, it's just that stdio MCP was overengineered.
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.
Could you expand on this some more? I'm not quite following.
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.
I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes.
People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.
I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.
CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.
That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.
I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.
This is my take as well.
Way easier to set up, centralized auth and telemetry.
Just use it for the right use cases.
Very good points, but, I think this blog is pretty focussed on the developer use case for LLMs. It makes a lot more sense in chat style interfaces for connecting to non-dev tools or services with non technical users, if anything just from a UX perspective.
Yes, exactly. Not only can you not run CLIs in Chat interfaces, the services that non devs use often don’t even have CLIs to begin with.
Developers have a rich set of CLIs because they live in the terminal and built those tools for themselves.
Thank you, I was going to say something like this. I've been reading all the comments here and thinking, "do ChatGPT/LeChat/etc even allow running CLIs from their web or mobile interfaces?".
Exactly. and even if so, how are you going to safe guard tool access?
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.
Supposedly, you make a Skill for it, but even that is out of scope for chat agents. I didn't scroll far, but I wouldn't be surprised more people in this thread have made the mistake of giving that answer.
Interface for non-devs has evolved. We already have OpenClaw and things like Claude Cowork.
This is like comparing OpenAPI and strings (that may be JSON). That is, weird, and possibly even meaningless.
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.
CLI tools are designed to provide complete documentation using —help. Given LLMs are capable of fully understanding the output then how is the MCP standardization any better than the CLI —help standardization?
Read only access control.
Instead of giving them read only credentials let’s spin up a server that wraps the cli and only has read only credentials…
Seems pretty roundabout.
I would spend less time with theory and more time with practice to understand what people are getting at. MCP and CLI could, in theory, be the same. But in practice as it stands today, they are not.
> 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.
> 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
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.
Please, please, please actually do this yourself or read any of the top comments. You are still missing the point, which you will understand if you actually do this and then look at the logs.
Fair enough, I’ll give it a try when I’ll have time for it.
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.
I'm rooting for you, to be clear! It sounds like your approach is more sophisticated than the average, and this is a pain point that is starting to get a lot of attention.
I can't believe everyone is talking about MCP vs CLI and which is superior; both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities. CLIs might be marginably better (LLMs might have been trained on common CLIs), but MCPs have their uses (complex auth, connecting users to data sources) and in my experience if you're using any of the frontier models, it doesn't really matter which tool calling format you're using; a bespoke format also works.
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.
[0]: https://ampcode.com/manual#mcp-servers-in-skills
>as long as it provides the same capabilities.
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.
> 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...
> 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 MCP server is automatically launched when the Agent loads that skill
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.
> 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.
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?)
> both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities.
MCP tool calls aren't composable. Not the same capabilities. Big difference.
No, it really matters because of the impact it has on context tokens. Reading on GH issue with MCP burns 54k tokens just to load the spec. If you use several MCPs it adds up really fast.
The impact on context tokens would be more of a 'you're holding it wrong' problem, no? The GH MCP burning tokens is an issue on the GH MCP server, not the protocol itself. (I would say that since the gh CLI would be strongly represented in the training dataset, it would be more beneficial to just use the CLI in this case though.)
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).
MCP specs are verbose json objects and they have to go into the context before you can call them. So yes it is an issue with the fundamental design of the protocol.
Even if the model doesn’t already know the cli commands it can interrogate them at a much lower token cost for just the commands needed.
Verbosity of the output seems orthogonal to the cli vs mcp distinction? When I made mcp tools and noticed a lot of tokens being used, I changed the default to output less and added options to expose different kinds of detailed info depending what the model wants. CLI can support similar behavior.
It has nothing to do with outputs, it’s about the json spec data that goes into the context.
In the front page there's a project that attempts to reduce tje boilerplate of mcp output in claude code
Eventually I hope that models themselves become smarter and don't save the whole 54k tokens in their context window
MCP needs to be supported during the training and trained into the LLM whereas using CLI is very common in the training set already. Since MCP does not really provide any significant benefits I think good CLI tools and its use by LLMs should be the way forward.
This is very developer centric. While Github might have good CLI, there's absolutely no point in having most services develop CLIs and have their non-technical users install those. Not only is it bad UX, but it's bad from security perspective as well. This is like arguing that Github shouldn't have GraphQL/Rest api since everyone should use the CLI.
MCP vs CLI is the modern version of people discussing the merits of curly braces vs significant whitespace.
That is, I don't think we're gonna be arguing about it for very long.
Yeah, I've gotta use skills more. I didn't quite get it until this last week when I used a skill that I made. I didn't know the skill got pulled into context ONLY for the single command being ran with the skill, I thought the skill got pulled into context and stayed there once it was called.
That does seem very powerful now that I've had some time to think about it.
Or you could argue that if the assistant needs so much modular context your tools are defective.
One underrated reason that CLIs are often better than MCP is that Unix tools seem to have close to information theoretically optimal layout to enabled reasoning. They are concise, in the Solomonoff/Kolmogorov sense.
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
There's been an anti-MCP pro-CLI train going for a while since ~May of last year (I've been personally beating this drum since then) but I think MCP has a very real use case.
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.
Running both MCP and CLI-based agents in production, my take is that this isn't an either/or question.
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.
I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.
>we can expect it to get much better than it is today
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.
This is excessively cynical, it's a useful tool despite its shortcomings.
You could strip away 90% of the spec and it would be even more useful. In fact standardizing the tool definitions and prompt formats would probably have done more if you're serious about supporting a certain set of tools between various LLM providers.
Why? The llm can install cli through apt-get or equivalent and non developers wouldn’t need to know
well I'm sure you can understand the dangers of that, and why that won't work if your app is hosted and doesn't run on users' local machines
What non developer would have apt installed on their device though
The token budget angle is what makes this a real architectural decision rather than a philosophical one.
I've been using both approaches in projects and the pattern I've landed on: MCP for anything stateful (db connections, authenticated sessions, browser automation) and CLI for stateless operations where the output is predictable. The reason is simple - MCP tool definitions sit in context permanently, so you're paying tokens whether you use them or not. A CLI you can invoke on demand and forget.
The discovery aspect is underrated though. With MCP the model knows what tools exist and what arguments they take without you writing elaborate system prompts. With CLI the model either needs to already know the tool (grep, git, curl) or you end up describing it anyway, which is basically reinventing tool definitions.
Honestly the whole debate feels like REST vs GraphQL circa 2017. Both work, the answer depends on your constraints, and in two years we'll probably have something that obsoletes both.
What about --help? Isn't that a perfect parallel to discovery of available tools in an MCP server?
Yup. I’ve been using CLIs with skills that define some common workflows I use and then just tell Claude to use —help for understanding how to use it. Works perfectly and I end up writing the documentation in a way that I would for any other developer.
As far as I'm aware, all of the benefits of MCP over CLI go away if you just bother to run your agents as OS users with locked down permissions such that they only have access to secrets for similarly locked down users on remote systems.
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.
The opposite is true. CLI based integration does not exist in a single consumer grade ai agent product that I’m aware of. CLI is only used in products like Claude Claude and OpenClaw that are targeting technically competent users.
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.
One key aspect that is missed here, is mobile users.
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.
[1] https://github.com/benkaiser/joey-mcp-client
AI Agent's like Claude Code are an arms race to the bottom. Just like frontier model quality, they all converge on feature sets over time (plan mode, skills, remote execution, sandboxing, etc.,) and opencode is holding its own, preferred even, in a lot of cases.
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.
This feels misguided. MCP is still one of the best ways to execute deterministic sub-flows (i.e., stepwise processes) and secure tooling that an LLM would either lose itself while executing or should never access directly.
Im still struggling with understanding when MCP works better. I move everything to cli after a while. Can you give me more concrete examples? Because I don’t doubt you, I just don’t understand.
Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access.
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.
That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP.
I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill).
Now I'm not using my cli tools in Claude Chat proper, but I'm not using MCPs either because they just keep failing me. This could very well be a me problem, but I'm still looking for that "ah-ha" moment.
Maybe I'm misunderstanding you, but the way you describe MCP sure sounds like it's just another RPC endpoint. Those are easy to add using traditional methods. Why deal with all the overhead of MCP for those cases?
I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield).
An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to be more "agent compatible".
Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.
You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.
But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.
It's the security layer that I'm most interested with MCPs. Granting full access to the CLI feels super dangerous and maybe there are options to certain commands that I want to restrict from LLM usage.
state. i'm not sure if they had that in mind but one keyword that is important here is: state. Sure CLI tools can also affect state, but in MCP service it's somewhat more natural?
MCP makes sense when you're not running a full container-based Unix environment for your agent to run Bash commands inside of.
yep! thats the motivation behind https://github.com/r33drichards/mcp-js
I want to be able to give agents access to computation in a secure way without giving them full access to a computer
Imagine asking to your favorite LLM the following: "get the document attached to the most recent email from Joe and then upload it into my document management system in a new folder within archive 'Important', make sure to name the folder based the topic of the document following the naming convention already in place for folders in the same archive"
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?
OpenClaw and similar agents do that now without using MCP servers.
As a counter argument to the kubectl example made in the article, I found the k8s MCP (https://github.com/containers/kubernetes-mcp-server) to be particularly usefuly in trying to restrict LLM access to certain tools such as exec and delete tools, something which is not doable out of box if you use the kubectl CLI (unless you use the --as or --as-group flags and don't tell the LLM what user/usergroup those are).
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.
I somehow agree with this but want to add my two cents here. Cloudflare's Codemode[0] is a great "replacement" for MCP because AI is trained for writing code and handling errors. But it also doesn't fix security and sandboxing. For CLI and file operations we have Vercel's just-bash[1] but for everything else there is no safe solution. Therefore MCP still makes sense until somebody sandboxes this part as well without needing to use Cloudflare or something.
[0]: https://developers.cloudflare.com/agents/api-reference/codem... [1]: https://github.com/vercel-labs/just-bash
Every MCP vs CLI argument I've seen really glosses over _where_ the agent is running, and how that makes a difference. For individual users where you're running agents locally, I totally agree that CLIs cover the vast majority of use cases, where available.
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.
I've been building tools that use both approaches and the answer really depends on the context.
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.
Most of what the article says is true regarding coding agents, but articles like this are making a big mistake: they're completely forgetting that agentic applications aren't all claude code.
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.
Sure, but it's pretty trivial to generate a CLI application that talks to that API.
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.
Yes. But are you letting your agent make the decision of when and how to call that CLI? And presumably you're invoking it via the Bash tool. In which case your agent is free to write ad-hoc bash orchestration around your CLI calls. And perhaps you don't just have one such CLI but rather N for N different services.
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.
Okay, MCP is useless if the agent has full CLI access, sure. But what if it's a remote cloud agent connecting to another equally remote service. Well, now I need to install said CLI tool. What if I dont want to install a local mcp server either (which was always a stupid idea), and I want for there to be an harness around what the agent can do instead of give it a whole API?
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.
Most of this thread is debating MCP as a CLI wrapper, and for that it's clearly worse. More tokens, no piping, another process to manage.
But the real use case for MCP isn't replacing git or jq. It's giving agents persistent state across sessions. When I close the terminal my agent forgets everything. What it was working on, what it decided, what it tried that failed. Next session starts from zero.
An MCP server that holds structured project state -- tasks, decisions, context -- lets the agent pick up where it left off. It queries what happened last session, updates progress, records new decisions. That's fundamentally different from running a CLI command and parsing stdout. You need a server that maintains state and exposes typed operations on it.
The framing should be: CLI for stateless operations (builds, git, file manipulation). MCP for stateful integrations where the agent needs memory that outlives the session.
I think that's a fair argument. I'd push back a bit on that being unique to MCP. Agent browser (https://github.com/vercel-labs/agent-browser) handles persistent sessions just fine as a CLI.
YES, I have been thinking the same and wrote a bit about it: https://vizzly.dev/blog/cli-json-output-llm-friendly/
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?
Great read. Thanks for sharing. 100% agree, `—json | jq` is where it’s at.
I understand the argument, and there are some really good points.
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.
The problem with CLIs is that unless it's a super well documented CLI like `gh`, the LLM will have a hard time figuring out how to use it from `--help` alone unless it's a really simple tool. If you want to do something complex, like create a JIRA issue, you either need to put the full issue schema in `--help` so that the LLM knows how to pass an issue or else you can use MCP which bakes tool schemas into the protocol.
That's easily solved by wrapping it in a skill. And every time it fails, once you are done you ask it to update the skill with what it learned. A couple iterations later and it will be solid.
I've yet to play with Emacs MCPs thoroughly. Having said that, after initial exposure to agent skills directing agents to just use CLI/emacsclient, I no longer think I need to go deeper into MCP. emacsclient via CLI has been working remarkably well. Did a little video on that https://www.youtube.com/watch?v=ymMlftdGx4I
You actually answered your own question: "If a tool genuinely has no CLI equivalent, MCP might be the right call."
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.
The important part of MCP (that this misses) is that it's a machine interface you can quickly iterate on. In other words, an API is too slow-moving. You can't break it; it's a promise. A UI is too annoying for an LLM to deal with. An MCP is the perfect middleground: speaks JSON, but there's inference involved, so if you change the tools, the LLM will be just fine. (Just like how you can change your UI much faster than you change your API, because there's inference at runtime, ie in the human brain.)
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.
MCPs were dead in the water and were completely a bad standard to begin with. The hype around never made sense.
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.
[0] https://news.ycombinator.com/item?id=44528411
You use MCP to provide dumb-down API that LLM can consume. It's not that hard. If you MCP server is 1:1 map to your REST - you're doing it wrong.
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 solves a very specific problem: how do you ship a LLM’s tool/function so that it is callable by an LLM in an inter-process manner (so that you don’t need to modify OpenAI’s code to make your tool available in ChatGPT)? CLIs concern what happens inside such tools, namely a `bash` tool. As you can see they are different layers of the same stack.
> 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?
Recently, I was wondering why http API don’t make use of the body of a http OPTIONS query to discover what an endpoint does.
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
MCP has one thing going for it as an agentic API standard: token efficiency
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.
But the flip side of this is that the tools themselves take up a ton of token context. So if you have one mcp it’s great but there is an upper bound that you hit pretty quick of how many tools you can realistically expose to an agent without adding some intermediary lookup layer. It’s not compact enough of a spec and doesn’t have lazy loading built into it
Yes but I consider that just a bug in the agents that use MCP servers.
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.
you know what you could do? You could write a skill that turns mcps on or off!
But they're not token efficient. Take the terraform example from the post. Plan JSON is massive. You're not saving tokens by using a Terraform MCP and shoving an entire plan into context. Composition allows for efficient token use.
I've been creating a cli tool with a focus on token efficiency. Dont see why cli could not be as token efficient as mcp. The cli has the option to output ascii, markdown and json.
I'm working on a paper on this, if you are using a hypermedia-like system for progressive revelation of functionality you are likely to find that this chatty style of API is inefficient compared with an RPC-like system. The problem is architectural rather than representational.
I say this as a hypermedia enthusiast who was hoping to show otherwise.
the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.
So far, cli --help seems to work quite well. I'm optimizing the cli to interact with the agent, e.g., commands that describe exactly what output is expected for the cli DSL, error messages that contain DSL examples that exactly describe the agent how to fix bugs, etc. Overall i think the DSL is more token efficient that a similar JSON, and easier to review for humans.
fair point on token efficiency -- dsls are usually tighter than json. where i see mcp still winning is tool discovery: the client learns what tools exist and what args they take without having to try calling them first or knowing the commands upfront. with cli you have to already know the tool exists.
This can be easily done using CLAUDE.md or similar. Easier than registering the MCP with the agent.
If the author is just using Claude Code on their own personal computer, they can do whatever they want.
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.
You're right, but it still doesn't mean MCP was a good design even in that space. We could've done better.
Here’s your chance to educate us. It’s not at all obvious what sorts of limitations you’re talking about.
I haven't been able to make a coherent argument against MCP, so I've settled for "I just don't like it".
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!
These are all evolving technologies and it's pretty evident that the big AI labs are trying different things to see what sticks. Some of it does and they keep evolving it.
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:
https://fragmentedpodcast.com/episodes/302/
The only MCP server I use is Svelte's and every time I use it, I feel as though I'm just spamming my context window for little to no reason. I mostly only use it when I'm unsure about something.
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.
My success with LLMs has increased quite a bit since I stopped using MCP servers. I credit it to a couple things:
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
For me, GitHub CLI is the prime example of this. This CLI is so incredibly powerful when combined with regular command line tools. Agents know how to use head, tail, jq and so on to only extract the parts it needs.
The best selling point of CLIs is the ability to chain, transform and combine. MCP cannot do this.
This author gets it. Ignore MCP, WebMCP, etc and instead build for humans like we always have. If LLM providers want usage they can push models to engage with tools like a human does - read docs, use a11y features, and when in doubt `--help`.
I keep asking why the default Claude tools like Read(), Write(), Edit(), MultiEdit(), Replace() tools aren’t just Bash() with some combination of cat, sed, grep, find. Isn’t it just easier to pipe everything through the shell? We just need to figure out the permissions for it.
Because the Tools model allows for finer grained security controls than just bash and pipe. Do you really want Claude doing `find | exec` instead of calling an API that’s designed to prevent damage?
It might be the wrong place to do security anyway since `bash` and other hard-to-control tools will be needed. Sandboxing is likely the only way out
not for every user or use case. when developing of course i run claude —-do-whatever-u-want; but in a production system or a shared agent use case, im giving the agent least privilege necessary. being able to spawn POSIX processes is not necessary to analyze OpenTelemetry metric anomalies.
yeah, I would rather it did that. You run Claude in a sandbox that restricts visibility to only the files it should know about in the first place. Currently I use a mix of bwrap and syd for filtering.
Making those tools first-class primitives is good for (human) UX: you see the diffs inline, you can add custom rules and hooks that trigger on certain files being edited, etc.
I’ve found that humans are pretty good at reading through the output of bash commands. And Claude Code keeps insisting on truncating the output for some reason.
One clear use case where MCP is better than anything else: design system documentation for an enterprise, or using a specific UI library. Daisy UI has an example: https://github.com/birdseyevue/daisyui-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.
The skill-based approach has been a game changer for me. Instead of wrestling with MCP server configs, I just write a small markdown file describing the CLI tool and its common use cases. The agent loads it on demand when it detects the tool is relevant. Much simpler than maintaining a running process, and the documentation lives right next to my code rather than in some separate server config. The composability argument is what really sold me - piping through jq, chaining commands, redirecting to files... that's stuff I do daily and never have to think about.
Reports of MCP's demise have been greatly exaggerated, but a CLI is indeed the right choice when the interface to the LLM is not a chat in a browser window.
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.
[1] https://github.com/awebai/aw
When we give LLM access to the terminal, LLM doesn't need anything else. LLM already knows all the commands, and there's no need to waste context on MCP. When we tell it to use a new command, it can get `--help` as needed.
> CLIs have had decades of design iteration. They’re composable, debuggable, and they piggyback on auth systems that already exist. MCP tried to build a better abstraction. Turns out we already had a pretty good one.
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.
Strong take: MCP is the wrong default for agent runtimes.
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.
> When Claude does something unexpected with Jira, I can run the same jira issue view command and see exactly what it saw. Same input, same output, no mystery.
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.
> This is where the gap gets wide. CLIs compose. I can pipe through jq, chain with grep, redirect to files. This isn’t just convenient; it’s often the only practical approach.
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.
This is actually the first use case where I agree with the poster. really interesting, especially for technical people using ai. why would you spend time setting up and installing an mcp server when u can give it one man page
Some developers started asking a custumer of mine for a MCP server. They don't have one. They have an API on Postman (docs and examples) so they are exporting it as JSON and sending it to those developers. It might work but it's not what those developers want and maybe they will go to another similar service. So useless or not the availability a MCP server could be part of marketing and a checkbox on a due diligence sheet.
The only place MCP made sense for me, so I thought, was to give my Claude Web agents access to the same cli tools my Claude Code agents had. In this context, agents don't have shells.
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?
There is a global setting you can do to disable using the Claude.ai MCPs from being used on your Claude code.
Thank you so much.
I've been thinking about this a lot lately in terms of my personal clauding, and it's hard for me to think of a scenario where an mcp server makes more sense than CLI tools and AGENTS.md. But if you're deploying an agentic product, it's probably different. Seems like you could just deploy little Bash sandboxes for each customer. Or you could deploy mcp servers. The latter feels much easier to reason about in terms of attack surface and potential side effects.
Remote MCP solve the distribution problem just like everyone uses web apps for everything nowadays instead of desktop apps. Local MCP servers make as much sense as local web apps.
?? I'm using my own remote MCP server with openclaw now. I do understand the use case for CLI. In his Lex Friedman interview the creator highlights some of the advantages of CLI, such as being able to grep over responses. But there are situations where remote MCP works really well, such as where OAuth is used for authentication - you can hit an endpoint on the MCP server, get redirected to authenticate and authorise scopes etc and the auth server then responds to the MCP server.
Agree. MCP isn't really required. Skills/CLI/API is good enough.
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.
If you’re going this far, why even have a cli? Just have your agent grab the openapi spec from the server and set envvars. It can curl its way around happily. Security? I don’t see how this is any more or less secure than any other claude code workflow.
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.
Yes, it's surely possible, but a well-designed CLI or any tool of that matter would be efficient when it comes to the context size.
Why choose if you can have both? You can turn any MCP into an CLI with Pete's MCPorter: https://mcporter.dev.
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.
Tell my business users to use CLI when they create their agents. It's just not happening. MCP is point-and-click for them.
MCP is far from dead, at least outside of tech circles.
It really seems the primary benefit of MCP servers was to force companies to establish some externally exposed APIs if/when they did not have them.
In terms of what companies are actually implementing, MCP isnt dead by a long time. Number of companies with a MCP server grew 242% in the last 6 months and is actually accelerating (according to Bloomberry) [1]
https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
Companies are usually chasing last year's trend, and MCP makes for an easy "look, were adopting AI!" bullet point.
Right, but even if this is just a matter of "chasing a trend", it does have a network effect and makes the entire MCP ecosystem much more useful to consumers, which begets more MCP servers.
MCP is a completely useless abstraction, and I’m not sure why anyone would push for it over basic cli tools / skills.
I've found MCP is great for stacking claude code instances- https://github.com/cduerr/stewardmcp has legit been a useful tool for me, and more reliable than handing a single instance 100k lines of code over a dozen repos.
Isn't that handled pretty well these days with sub agents? They can research the code without polluting the context.
Somewhat. The stewards (sub-Claudes) won't share their parents context window and have the ability to talk to one another. That said I'm sure there's a lot out there that solves for this.
MCP Servers are not simple wrappers around REST APIs, they can do much more and we will see more advanced use-cases surrounding MCP as MCP clients continually improve their conformance to the spec. Just wrapping REST APIs may be what MCP Servers are now, but that's just because MCP clients still need to catch up in supporting these more advanced features.
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.
And for anything at all complicated, what’s even better than a CLI is a JS or Python library so the thing can just write code.
I've come to the same conclusion as op, created a CLI tool to work with Chrome sessions. It works well, and I'm planning to do some token comparison on this vs an MCP approach. https://news.ycombinator.com/item?id=47207790
Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.
It does so many things though, very similar in the core though. I'm wondering what the token counts will be when I compare. Also the agent browser seems to support other browsers too, I only when with chromium
What if you want to build a third party integration to connect to Claude Chat or Cowork? Those can't run arbitrary CLIs. The only way to integrate with them is via MCP.
For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.
This will happen with GUIs as well, once computer-use agents start getting good. Why bother providing an API, when people can just direct their agent to click around inside the app? Trillions of matmuls to accomplish the same result as one HTTP request. It will be glorious. (I am only half joking...)
Half joking, sure, but the "click around the app" problem is already real for teams running browser automation at scale. The issue isn't the clicks themselves - it's that every Chrome instance looks identical to a bot detector the moment you spin up ten of them from the same machine. The fingerprint (canvas, WebGL, navigator properties, etc.) is basically screaming "I'm automated". Dealing with this from the ops side: the headache isn't writing the automation, it's keeping each browser session isolated enough that sites don't treat them as the same entity. MCP or CLI doesn't really change that underlying problem.
> OpenClaw doesn’t support it. Pi doesn’t support it.
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.
MCPs are useful to deploy internally as an agent tool gateway for your organization or customers. That's a totally different use case than how most of us interact with agents (claude code / cursor). That said, there's only limited benefit over just using OpenAPI.
CLI vs MCP debate misses the protocol's actual value prop: steering the agent: https://cra.mr/context-management-and-mcp
This doesn't really pay attention to token costs. If I'm making a series of statically dependent calls I want to avoid blowing up the context with information on the intermediary states. Also, I don't really want to send my users skill.md files on how to do X,Y & Z.
Why? MCP and CLI is similar here.
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.
This feels right in theory and wrong in practice
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.
the article only makes sense if you think that only developers use AI tools, and that the discovery / setup problem doesn't matter
But that's the current primary use case for AI. We aren't anywhere close to being able to sanitise input from hostile third parties enough to just let people start inputting prompts to my own system.
there's a whole world of AI tools out there that don't focus on developers. These tools often need to interact with external services in one way or another, and MCP gives those less technical users an easy way to connect e.g. Notion or Linear in a couple of clicks, with auth taken care of automatically. CLIs are never replacing that use case.
For personnal agents like claude code, clis are awesome.
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.
Even for Openclaw, the response API is a better way to interact with it adhoc. I tell Cursor how to contact OC with a bearer key, and they work things out in the background when I'm building something for Openclaw.
Oh no what am I going to do with my MCP tattoos now?
I think if you want background agents with sandboxes and well scoped permissions, you want MCP to be your data protocol and security layer.
If you’re vibing and doing the open claw thing without any security concerns; then you’re absolutely right.
I’ve noticed Claude Codes sandbox mode works with MCPs. With CLIs I’ve rain into permission issues. CLIs also need reminding about whats available unless references are baked the context window.
I don't understand the CLI vs MCP. In cli's like Claude Code, MCPs give a lot of additional functionality, such as status polling that is hard to get right with raw documentation on what APIs to call.
Also when they use cli you can learn from it and sometimes, next time you’ll be faster if its just a simple edit compared to an ai that first has to understand relevant context.
MCP is worth it when you need standardized, safe, observable tool calls across many systems; for single-purpose workflows, a CLI stays simpler and more debuggable.
Only when you sell something MCP related.
Jokes aside, normies that can hook an MCP in ChatGPT/claude desktop is a real world usecases
https://github.com/mcpshim/mcpshim - converts MCPs to CLI - best of both worlds
IMO the biggest issue with CLIs for agents is to know when the agent is allowed to type. When is the command fully proceed, and next tokens can now be generated.
Use APIs for building things (and preparing for things to be built upon). Production.
Use CLI for exploration, coding, and learning. Greenfield.
In general, Declarative > Imperative.
I wonder if what we'll get out of MCP tech in the end is a standardised machine readable description of CLI interfaces? Could be neat actually.
To be fair to MCP it came out 150 years ago, in November 2024. Agents were running on steam and coal then with Sam Altman shovelling the furnace.
Biggest downside of CLI for me is that it needs to run in a container. You're allowing the agent to run CLI tools, so you need to limit what it can do.
It gets significantly harder to isolate the authentication details when the model has access to a shell, even in a container. The CLI tool that the model is running may need to access the environment or some credentials file, and what's to stop the model from accessing those credentials directly?
It breaks most assumptions we have about the shell's security model.
Couldn't that be solved by whitelisting specific commands?
Give it a try, and challenge yourself (or ChatGPT) to break it.
You'll quickly realize that this is not feasible.
Such a mechanism would need to be implemented at `execve`, because it would be too easy for the model to stuff the command inside a script or other executable.
Advancing capability in the models themselves should be expected to eat alive every helpful harness you create to improve its capabilities.
For teams that have tried both, where does MCP clearly outperform just giving the model a CLI?
genuine question: how would you turn a debugger-mcp into a CLI? do CLI tools used in agents have the concept of persistence?
APIs and CLIs still remain king, just like before. The difference is mostly in UIs and how you deliver it.
MCPs were always for chat apps, not coding agents. Benefit is auth for normies + can serve UI through ChatGPT + Claude.
Couldn't agree more. Simple REST APIs often do the job as well. MCP felt like a vibe-coded fever dream from the start.
What, those job ads asking for 5 years of experience with MCP were useless after all?
on the other hand, MCP/tools style lets me run specialized agents without needing to give them a bash-like unix environment. Vercel makes a fake bash simulator but if i’m trying to run an agent that analyzes production telemetry, it’s a hell of a lot easier to do that safely with just MCP
Browser automation: chrome-devtools-mcp, playwright-mcp, etc.
That's too close to actual programming, vibe coders will never go for it.
I’ve been using the command line tools except for teams integration which I use MCP for
CLIs are dead. Long live the skill. Which is a wrapper around the CLI! Haha.
*when does an LLM make sense vs writing your own code.
Dang, I fixed the title for you.
Is it just me or is hackernews being flooded with overhyped AI "Discoveries". Only thing that changes is what data is being trained on it or the interface. I come here for interesting computer science/systems related content.
I get it, the entire economy is being invested into LLMs right now... Lots of AI Salesmen these days pissing me the fuck off.
Thoughts on Agent Context Protocol (ACP)?
Been ignoring this junk for a long but I had to look since the front page is littered with "MCP". Is acronym on purpose?
I don't know about this. I use AI, but I've never used or tried MCP. I've never had any problems with the current tools.
That's the way my 80 year old grandpa talks.
This is the dumbest most myopic take I’ve seen in awhile. MCP servers aren’t just used for geeks using Claude Code. If I have an app in production that uses an MCP server what is he suggesting? That my LLM create a shell script and run it inside of a Docker container?
This take is so incredibly short sighted. Sure mcp is not perfect and needs better tooling and a bit updated standards, but clis are >maybe< just the future for agents that are clis themselves but i would argue these agents will be not the mainstream future but a niche i call "low level system agents" or things for coding bros. An agent of the future needs to be way more secure, auditable, reasonable and controllable none of which is possible by slapping a cli with execution rights into a container even with a bubblewrap profile. An agent of the future will run in a sandbox similar to cloudflare workers/workerd isolate with capabilities. The default will be connecting one central MCP endpoint to an agent that runs in its own sandbox without direct access to the systems it works on. The MCP gateway handles all the things that matter, connecting LLM providers, tokens for APIs, enforcing policies, permission requests, logging, auditing, threat detection and also tools. Tools execute on the container level, so there is not even a need to change anything about any existing containerised workloads, its all transparently happening in the container realm. I am not saying system level agents have no use but any company running anything like kubernetes or docker compose will have zero need or tolerance for an agent like that.
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
This is spot on
what honestly is the difference between an mcp and a skill + instructions + curl.
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?
The difference is that the server gives a description of the api it understands in enough detail that the llm can make use of it.
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.
Author here! Biggest difference is composition. MCP tools don't chain (there's people trying to fix that, but it's still true right now).
[dead]
This got renamed right in front of my eyes
First they came for our RAGs, now for our MCPs. What’s next ?
> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit
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
MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!
> The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves.
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.
Do you mean for code generation, or process automation? for process automation, I think MCP is still very useful right?
Strongly disagree, despite that meaning I'm swimming upstream here.
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.
If you want a validation layer, why not write a cli that wraps the other cli?
This is what I've been working on. I've written a project wrapper CLI that has a consistent interface that wraps a bunch of tools. The reason I wrote the CLI wrapper is for consistency. I wrote a skill that states when and how to call the CLI. AI agents are frequently inconsistent with how they will call something. There are some things I want executed in a consistent and controlled way.
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.
that's what the MCP server is, except I don't always want a cli.
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.
> 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 does not, your MCP server can be a small python file, your agent would execute it as a process and use stdio to communicate with it. You can also run it as an HTTP server, but if it's all on the same machine, I don't see the point. I'm pretty sure in under 15 loc of python you can wrap subprocess.check_ouptput as an stdio MCP server for example to let your agent run any commands or a specific command.
You can just write a README.md and put it along with the CLI
Because that is a consistent and reliable way of doing it? what happens when I have to use something that can't be done via cli, or if I have lots of small use cases (like I sometimes do with MCP servers - lots of tiny functions), do I create a separate readme for each of them and manage the mess? what exactly is the issue with MCP? is it too well organized?
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.
There are certainly things can't be done via CLI, or more suitable for a persistent daemon with various RPC rather than a CLI. But most things are simpler than that, and MCP is overcomplicating it.
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.
Maybe I don't understand how other people are using MCP, if it is for code generation agents, that I can't speak of. but for your own agent code, for me at least an MCP server is much easier to use than running commands directly.
> 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!
Agreed; the majority of use cases can be solved with either CLI tools or internal “CLI-like” calling conventions.
However, MCP can make sense when connecting to a complex GUI app; especially one that provides visual output. The example here would be Figma.
Why don't you just have the agent write scripts against the APIs? The skills-based workflow doesn't confine you to bash only.
If you do that, you end up with all the problems that MCP attempts to solve: how to authorize using a standard mechanism, how to summarize operations in a better way than just dumping the OpenAPI spec on the LLM, providing structured input/output, providing answers to users that the LLM cannot see (for sensitive data or just avoiding polluting the context) and so on.
Authorization, in my opinion, is the big problem you need MCP for, though the current MCP Authorization spec still needs some refinement.
I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used.
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.
For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me.
We don’t use the cloud versions, so not sure if they work better with cloud.
On the other hand, i found some unofficial CLIs for both and they work great.
I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
I deal with a ton of different atlassian instances and the most infuriating thing to me about the mcp configuration is that atlassian really thinks you should only have one atlassian instance to auth against. Their mcp auth window takes you to a webpage where you can’t see which thing you are authoring against forcing you to paste the login page url into an incognito window. Pretty half baked implementation.
I noticed that it’s better for some things than others. It’s pretty bad at working with confluence it just eats tokens but if you outlay a roadmap you want created or updated in Jira it’s pretty good at that
I have had some positive experiences using the Jira and Confluence MCPs. However, I use a third-party MCP because my company has a data centre deployment of Jira and Confluence, which the official Atlassian MCP does not support.
My use case was for using it as an advanced search tool rather than for creating tickets or documentation. Considering how poor the Confluence search function is, the results from Confluence via an MCP-powered search are remarkably good. I was able to solve one or two obscure, company-specific issues purely by using the MCP search, and I'm convinced that finding these pages would have been almost impossible without it.
Fully agree.
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.
It’s telling the best MCP implementations are those which are a CLI to handle the auth flow then allow the agent to invoke it and return results to stdout.
But even those are not better for agent use than the human cli counterpart.
How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.
I've been running Claude Code in a Docker compose environment with two containers - one without Claude that has all the credentials setup and a Claude container which transparently executes commands via ssh. The auth container then has wrappers which explicitly allow certain subcommands (eg. `gh api` isn't allowed). The `gh` command in the Claude container is just a wrapper script which bassically `ssh auth-container gh-wrapper`.
Lots of manual, opinionated stuff in here, but it prevents Claude from even accessing the credentials and limits what it can do with them.
I’ve been testing with an ENV variable for a cli tool for LLMs that I’m making. Basically, I have a script that sets an ENV variable to launch the TUI that I want and that ENV variable changes the behavior for LLMs if they run it (changes the -h output, changes the default output format to json to make it easier to grep)
Containers, virtual machines, jails.
Containers have jail runtimes available. See for example gVisor/runsc.
None of those work when dealing with external services, I wouldn’t even trust them as a solution for dealing with access to a database. It seems like the pushback against MCPs is based on their application to problems like filesystem access, but I’d say there are plenty of cases in which they are useful or can be a tool used to solve a problem.
Interestingly think I just came to the opposite conclusion after building CLIs + MCPs for code.deepline.com
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.
I hate MCP servers
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...
I always get a kick out of seeing MCP wrappers around CLI’s.
In my experience, a skill is better suited for this instead of an MCP.
If you don’t want the agent to probe the CLI when it needs it, a skill can describe the commands, arguments and flags so the agent can use them as needed.
They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands
Fwiw I'm having a good experience with a skill using Jira CLI directly. My first attempt using a Jira MCP failed. I didn't invest much time debugging the MCP issues, I just switched to the skill and it just worked.
Yes occasionally Claude uses the wrong flag and it has to retry the command (I didn't even bother to fork the skill and add some memory about the bad flag) but in practice it just works
Do you mean wrap the CLI with an MCP? I don't get that approach. I wrapped the Jira cli with a skill. It's taken a few iterations to dial it in but it works pretty damn well now.
I'm good, yet my coworkers keep having problems using the Atlassian MCP.
Silly. All it needs is docs. No need to overcomplicate it.
Even if the help isn't great, good coding agents can try out the cli for a few minutes and write up a skill, or read the sources or online docs and write up a skill. That takes the spot of the --help if needed. I found that I can spare quite a lot of time, I don't have to type up how to use it, if there is available info about it on the web, in man pages, in help pages, or the source is available, it can figure it out. I've had Claude download the sources of ffmpeg and blender to obtain deeper understanding of certain things that aren't much documented. Recent LLMs are great at quickly finding where a feature is implemented, how it works based on the code, testing the hypothesis, writing it up so it's not lost, and moving on with the work with much more grounding and fewer guessing and assumptions.
Using the source code to ask questions about poorly documented features in projects you have no experience is my favourite thing that LLMs make possible (of course you could do this before but it would take way, way more time). There are so many little annoyances that I’ve been able to patch and, thanks to NixOS, have the patched software permanently available to me.
In fact NixOS + LLMs feels like the full promise of open source software is finally available to me. Everything is within reach. If you don’t like something, patch it out. If you want to change a default, patch that in.
No need to know the language, the weird build process, or the custom tooling. Idea to working binary in minutes. I love it so much.
Yes, the idea that you can meaningfully modify the program for your own purposes (one of Stallman's four freedoms) was quite unrealistic except for the most skilled and invested among users. LLMs change this. I mean, as long as you use open models. I fear that in the future, corporate models may start to refuse building software like this that is inconvenient for them. Like possible future-Gemini saying, "oh I see you're patching chromium to continue working with adblockers, this is harmful activity, I cannot help you and reported your account to Google. Cease and desist from these plans or you lose your Gmail!"
Today is the honeymoon phase, enshittification will come later when the pie stops growing and the aspect of control comes more into focus.
It's just too good to be true. Most people still don't know that you can now do what you just described. Once people in the suits understand this, the propaganda will start about how unsafe this all is and that platforms must be locked down at the hardware level, subscriptions cut off if building unapproved software etc.
> 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.
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.
Tools eat up so much context space, too. By contrast the shell tool is trained into Claude.
We have a lot of tools (starting with the internal wiki) which are normally only exposed to engineers through web interfaces; MCPs make them available to terminal agents to use autonomously. This can get really interesting with e.g. giving Claude access to query logs and metrics to debug a production issue.
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.
> dump a large payload into Claude's filesystem and let him figure it out
I just realized I never thought of Claude as ‘him’, usually I think of Claude as ‘it’..
Because "him" is objectively wrong, under almost any interpretation of any words involved. You can cause Claude, or any text-based LLM, to emit language that matches almost any personality / gender / character in the training set. At best you might be able to say "the default outputs have a masculine tone / vibe", but this still doesn't justify, by modern discourse, the "him".
You took the time to write this entire paragraph and didn’t realize it’s just because Claude is a masculine name?
The use of "him" by GP is extremely unusual IMO, and I suspect is odd for anyone with English as their native language. The current convention among normal people seems to me to be to avoid pronouns other than "it" with these tools, and generally just use the name. The name is not really relevant: like, sure, in some contexts we think of ships as "she/her", and may prefer feminine names for them, but if you used e.g. "she" rather than "it" to refer to the Titanic or any other ship with a female name, this is going to cause some double-takes / disfluent comprehension in the vast majority of native speakers in most cases.
Only if you imagine e.g. some stereotypical pirate with an eyepatch slapping the hull and saying something like "Aye, but she weathered the storm, as she always does" might this feel normal. Or, maybe if you are a Redditor and trying to make it your AI boyfriend / girlfriend, you can use he/him or some other neo-pronoun, but this is currently abnormal and not the general context.
And the fact that you can make the model act as any gender again shows why choosing "him" as some default here is strange. Absent any specific context, the choice of "him" here is poorly justified.
I thought they picked it specifically because it is gender neutral, but now I double checked and apparently it's only gender neutral in French,
https://en.wikipedia.org/wiki/Claude_(given_name)
The GPTs are "it" because they were deliberately named in a way to discourage anthropomorphizing them. Anthropic does want you to anthropomorphize Claude, and they gave their model a male name. It's not that deep!
And we should IMO resist Anthropic wanting us to anthropomorphize it, because Claude is not a person with a gender!
Be careful. I'm pretty sure my wife is going to leave me for Claude any day now.
I'll just disagree with an example: Codex on Windows.
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.
Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.
MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.
And your most common command sequences can be dropped into a script that takes options. Add a tools.md documenting the tools and providing a few examples. How many workflows need more than maybe two dozen robust scripts?
When is MCP the right choice though? For example - letting internal users ask questions on top of datasets? Is it better to just offer the api openapi specs and let claude run wild? or provide an MCP with instructions?
MCP is never the right choice.
If you want to build an AI app that lets people “do random thing here”, then build an app.
Peak MCP is people trying to write a declarative UI as part of the MCP spec (1, I’m not kidding); which is “tldr; embed a webview of a web app and call it MCP”.
MCP is just “me too”; people want MCP to be an “AI App Store”; but the blunt, harsh reality is that it’s basically impossible to achieve that dream; that any MCP consumer can have the same app like experience for installed apps.
Seriously, if we can barely do that for browsers which have a consistent ui, there was never any hope even remotely that it would work out for the myriad of different MCP consumer apps.
It’s just stupid. Build a web app or an API.
You don’t need an MCP sever; agents can very happily interact with higher level functions.
(1) - https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-ap...
What about MCP Apps? That seems like a legit use case but open to learning why maybe it isn't.
While I do agree that MCP was probably bit too far from whats required, there is some benefit for sure. Providing information in a consistent format across all the services makes it easier work with. It lowers the brittleness of figuring out things making the products built using LLMs more stable/predictable. Most importantly it becomes the latest version of the documentation about a service. This can go a long way in M2M communication, pretty much standardization of Application layer.
Oh wait, things like open-api and all already exists and pretty much built to solve the same problem.
This was my gut from the beginning. If they can't do "fully observable" or "deterministic" (for what is probably a loose definition of that word) -- then, what's the point?
Lol people are so lost in the bs
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
I remember this kind of people against Kubernetes the same exact way. Very funny.
Funny. Dealing with Kubernetes is my day job, and I can be equally critical of it. Pointing out absurdities is how we make things better, and that’s ok.
Same clowns complaining that `npm install` downloads the entire internet.
Now it's completely fine for an AI agent to do the same and blow up their context window.
Hi friends! Author here. This blew up a bit, so some words.
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).
Thank you for writing this. I've had similar thoughts myself and have been teetering back and forth between MCP and skills that invoke CLI. I'm hoping this creates a discussion that points to the right pattern.
"intentionally provocative"
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.
I get it. This is coming from a place where I see MCP's being adopted, where CLI is (in my opinion) better. Particularly where you're already in a CLI environment, and tool composition is necessary. I'm sure there's plenty of folks that aren't operating in that environment.