> 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 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.
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.
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.
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 using 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.
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.
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?
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?".
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.
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 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.
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.
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
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.
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.
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.
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.
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?
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.
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.
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.
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
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.
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.
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.
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.
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 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.
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
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 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?
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.
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.
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.
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]
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).
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.
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.
> 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.
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.
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
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.
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.
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?
umairnadeem123|50 minutes ago
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
binsquare|39 minutes ago
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.
ejholmes|44 minutes ago
bloppe|6 minutes ago
wenc|1 hour ago
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 using 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.
itintheory|9 minutes ago
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.
leohart|52 minutes ago
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?
rimeice|36 minutes ago
quectophoton|10 minutes ago
novaleaf|5 minutes ago
goranmoomin|3 hours ago
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
ejholmes|37 minutes ago
MCP tool calls aren't composable. Not the same capabilities. Big difference.
goodmythical|3 hours ago
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.
jeremyjh|2 hours ago
sophiabits|1 hour ago
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.
vojtapol|3 hours ago
avaer|3 hours ago
That is, I don't think we're gonna be arguing about it for very long.
xenodium|19 minutes ago
jackfranklyn|1 hour ago
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.
bartek_gdn|41 minutes ago
goodmodule|1 hour ago
[0]: https://developers.cloudflare.com/agents/api-reference/codem... [1]: https://github.com/vercel-labs/just-bash
drdaeman|1 hour ago
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.
fasbiner|30 minutes ago
> 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.
drecked|39 minutes ago
juanre|3 hours ago
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
unknown|3 hours ago
[deleted]
phpnode|3 hours ago
sigmoid10|3 hours ago
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.
simianwords|3 hours ago
mikkelam|1 hour ago
The best selling point of CLIs is the ability to chain, transform and combine. MCP cannot do this.
bartek_gdn|44 minutes ago
ejholmes|41 minutes ago
iamspoilt|2 hours ago
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.
simonw|2 hours ago
someguy101010|2 hours ago
I want to be able to give agents access to computation in a secure way without giving them full access to a computer
sebast_bake|2 hours ago
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.
CuriouslyC|3 hours ago
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.
_pdp_|40 minutes ago
827a|37 minutes ago
wrs|36 minutes ago
unknown|36 minutes ago
[deleted]
g947o|1 hour ago
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.
ejholmes|18 minutes ago
Mapsmithy|28 minutes ago
vladdoster|25 minutes ago
recursivedoubts|3 hours ago
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.
ejholmes|19 minutes ago
SOLAR_FIELDS|3 hours ago
ako|3 hours ago
bikeshaving|3 hours ago
fcarraldo|3 hours ago
rfw300|3 hours ago
mavam|2 hours ago
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.
brumar|1 hour ago
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.
baq|1 hour ago
appsoftware|2 hours ago
p_ing|3 hours ago
MCP is far from dead, at least outside of tech circles.
AznHisoka|3 hours ago
https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
lakrici88284|3 hours ago
ejholmes|2 hours ago
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).
g947o|1 hour ago
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.
csheaff|1 hour ago
the_mitsuhiko|2 hours ago
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.
orange_joe|3 hours ago
krzyk|3 hours ago
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.
phpnode|3 hours ago
Nevin1901|2 hours ago
ddp26|2 hours ago
ako|3 hours ago
wolttam|3 hours ago
It breaks most assumptions we have about the shell's security model.
tuwtuwtuwtuw|3 hours ago
lukol|3 hours ago
lasgawe|3 hours ago
I_am_tiberius|2 hours ago
rvz|3 hours ago
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
dnautics|2 hours ago
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?
ejholmes|47 minutes ago
whatever1|2 hours ago
SignalStackDev|3 hours ago
[deleted]
aplomb1026|2 hours ago
[deleted]
nimbus-hn-test|3 hours ago
[deleted]
mudkipdev|2 hours ago
mt42or|3 hours ago
tedk-42|2 hours ago
Now it's completely fine for an AI agent to do the same and blow up their context window.