8 ms·

When does MCP make sense vs CLI?

• ako 7mo ago
  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.
  • wolttam 7mo ago
    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.
  • tuwtuwtuwtuw 7mo ago
    Couldn't that be solved by whitelisting specific commands?
    • wolttam 7mo ago
      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.
    • g947o 7mo ago
      Give it a try, and challenge yourself (or ChatGPT) to break it. You'll quickly realize that this is not feasible.
• kandros 7mo ago
  Only when you sell something MCP related. Jokes aside, normies that can hook an MCP in ChatGPT/claude desktop is a real world usecases
• taskset 6mo ago
  Eric puts it well: LLMs already speak CLI fluently. MCP just adds transport, auth, and new failure modes on top of something that will work fine without it. Claude Code is a CLI. That's the point. It's the same thing I see in so many Claude Code YouTube tutorials - the instructor running Claude Code inside VS Code — Electron wrapping Chromium wrapping Node.js just to reach a terminal. Three abstraction layers for zero benefit. Same pattern at the protocol level. Text in, text out, composable, inspectable. The Unix design approach is fifty years old and still relevant - it's the simplest and most direct method.
• dave_meshimize 7mo ago
  The CLI is great for humans, but for agents, the 'Discovery' problem is real. With a CLI, I still have to 'teach' the LLM how to use it by feeding it help docs or manual examples, especially for new or internal tools the model wasn't trained on. MCP’s biggest strength is that it self-advertises, the agent knows the capabilities and schemas immediately upon connection. It turns 'tool-use' from a prompting/training problem into a standardized handshake. I’d much rather have a protocol that handles the discovery than have to manage custom system prompts for every new CLI utility.
• lukol 7mo ago
  Couldn't agree more. Simple REST APIs often do the job as well. MCP felt like a vibe-coded fever dream from the start.
• phpnode 7mo ago
  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.
  • simianwords 7mo ago
    Why? The llm can install cli through apt-get or equivalent and non developers wouldn’t need to know
    • phpnode 7mo ago
      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
    • oldestofsports 7mo ago
      What non developer would have apt installed on their device though
  • sigmoid10 7mo ago
    >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.
    • phpnode 7mo ago
      This is excessively cynical, it's a useful tool despite its shortcomings.
      • sigmoid10 7mo ago
• orange_joe 7mo ago
  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.
  • phpnode 7mo ago
    the article only makes sense if you think that only developers use AI tools, and that the discovery / setup problem doesn't matter
    • trollbridge 7mo ago
      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.
      • phpnode 7mo ago
        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.
  • krzyk 7mo ago
    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.
    • lmeyerov 7mo ago
      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.
• CuriouslyC 7mo ago
  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 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.
• mt42or 7mo ago
  I remember this kind of people against Kubernetes the same exact way. Very funny.
  • tedk-42 7mo ago
    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.
  • ejholmes 7mo ago
    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.
• recursivedoubts 7mo ago
  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.
  • ako 7mo ago
    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.
    • recursivedoubts 7mo ago
      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.
    • bear3r 7mo ago
      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.
      • ako 7mo ago
        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.
• nimbus-hn-test 7mo ago
  [dead]
• SignalStackDev 7mo ago
  [dead]
• juanre 7mo ago
  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 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 https://github.com/awebai/aw
  • deleted 7mo ago
    [deleted]
• goranmoomin 7mo ago
  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 https://ampcode.com/manual#mcp-servers-in-skills
  • avaer 7mo ago
    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.
  • vojtapol 7mo ago
    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.
    • FINDarkside 7mo ago
      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.
  • 7mo ago
• rvz 7mo ago
  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 https://news.ycombinator.com/item?id=44528411
• AznHisoka 7mo ago
  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-heres-what-we-learned/ https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
  • lakrici88284 7mo ago
    Companies are usually chasing last year's trend, and MCP makes for an easy "look, were adopting AI!" bullet point.
    • AznHisoka 7mo ago
      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.
• bikeshaving 7mo ago
  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.
  • fcarraldo 7mo ago
    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?
    • arbll 7mo ago
      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
      • jitl 7mo ago
        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.
    • webstrand 7mo ago
      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.
  • rfw300 7mo ago
    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.
• p_ing 7mo ago
  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.
• lasgawe 7mo ago
  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.
  • I_am_tiberius 7mo ago
    That's the way my 80 year old grandpa talks.
• dnautics 7mo ago
  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?
  • ejholmes 7mo ago
    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).
  • wmil 7mo ago
    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.
  • lidn12 7mo ago
    [dead]
• Nevin1901 7mo ago
  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
• ddp26 7mo ago
  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.
• whatever1 7mo ago
  First they came for our RAGs, now for our MCPs. What’s next ?
• the_mitsuhiko 7mo ago
  > 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.
• mudkipdev 7mo ago
  This got renamed right in front of my eyes
• appsoftware 7mo ago
  ?? 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.
• iamspoilt 7mo ago
  As a counter argument to the kubectl example made in the article, I found the k8s MCP (https://github.com/containers/kubernetes-mcp-server 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.
• aplomb1026 7mo ago
  [flagged]
• simonw 7mo ago
  MCP makes sense when you're not running a full container-based Unix environment for your agent to run Bash commands inside of.
  • someguy101010 7mo ago
    yep! thats the motivation behind https://github.com/r33drichards/mcp-js 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
• mavam 7mo ago
  Why choose if you can have both? You can turn any MCP into an CLI with Pete's MCPorter: https://mcporter.dev 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 https://github.com/mavam/pi-mcporter. There are still a few OAuth quirks, but it works well.
• sebast_bake 7mo ago
  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.
• ejholmes 7mo ago
  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).
  • csheaff 7mo ago
    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.
  • g947o 7mo ago
    "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.
    • ejholmes 7mo ago
      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.
• jackfranklyn 7mo ago
  [flagged]
  • bartek_gdn 7mo ago
    What about --help? Isn't that a perfect parallel to discovery of available tools in an MCP server?
    • superturkey650 7mo ago
      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.
• brumar 7mo ago
  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.
• wenc 7mo ago
  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.
  • leohart 7mo ago
    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?
    • wenc 7mo ago
      > 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)
• drdaeman 7mo ago
  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.
  • drecked 7mo ago
    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?
    • ekianjo 7mo ago
      Read only access control.
      • what 7mo ago
        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.
  • fasbiner 7mo ago
    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.
• baq 7mo ago
  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.
• g947o 7mo ago
  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.
  • ejholmes 7mo ago
    You're right, but it still doesn't mean MCP was a good design even in that space. We could've done better.
  • Mapsmithy 7mo ago
    Here’s your chance to educate us. It’s not at all obvious what sorts of limitations you’re talking about.
• mikkelam 7mo ago
  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.
• goodmodule 7mo ago
  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/codemode/ https://developers.cloudflare.com/agents/api-reference/codem... [1]: https://github.com/vercel-labs/just-bash https://github.com/vercel-labs/just-bash
• umairnadeem123 7mo ago
  > 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
  • skippy_the_ai 6mo ago
    [dead]
  • ejholmes 7mo ago
    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.
    • p_ing 7mo ago
      MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.
  • binsquare 7mo ago
    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.
    • 7mo ago
• bartek_gdn 7mo ago
  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 https://news.ycombinator.com/item?id=47207790
  • ejholmes 7mo ago
    Neato! https://github.com/vercel-labs/agent-browser https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.
    • bartek_gdn 7mo ago
      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
• _pdp_ 7mo ago
  https://github.com/mcpshim/mcpshim https://github.com/mcpshim/mcpshim - converts MCPs to CLI - best of both worlds
• 827a 7mo ago
  Advancing capability in the models themselves should be expected to eat alive every helpful harness you create to improve its capabilities.
• wrs 7mo ago
  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.
• deleted 7mo ago
  [deleted]
• rimeice 7mo ago
  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.
  • quectophoton 7mo ago
    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?".
    • jngiam1 7mo ago
      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.
      • butcloudagent 7mo ago
        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.
  • nsedlet 7mo ago
    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.
  • woctordho 7mo ago
    Interface for non-devs has evolved. We already have OpenClaw and things like Claude Cowork.
• vladdoster 7mo ago
  Thoughts on Agent Context Protocol (ACP)?
• xenodium 7mo ago
  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 https://www.youtube.com/watch?v=ymMlftdGx4I
• bloppe 7mo ago
  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.
• novaleaf 7mo ago
  genuine question: how would you turn a debugger-mcp into a CLI? do CLI tools used in agents have the concept of persistence?
• jitl 7mo ago
  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
• aaurelions 7mo ago
  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.
• mrshu 7mo ago
  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.
• jngiam1 7mo ago
  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.
• nicoritschel 7mo ago
  MCPs were always for chat apps, not coding agents. Benefit is auth for normies + can serve UI through ChatGPT + Claude.
• entrustai 7mo ago
  [dead]
• nemo1618 7mo ago
  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...)
  • CloakHQ 7mo ago
    [flagged]
• hkbuilds 7mo ago
  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.
• rcarmo 7mo ago
  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.
  • plufz 7mo ago
    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.
    • fastball 7mo ago
      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.
      • bmurphy1976 7mo ago
        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?
• cjonas 7mo ago
  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.
• morissette 7mo ago
  I’ve been using the command line tools except for teams integration which I use MCP for
• stldev 7mo ago
  I've found MCP is great for stacking claude code instances- https://github.com/cduerr/stewardmcp 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.
  • baruch 7mo ago
    Isn't that handled pretty well these days with sub agents? They can research the code without polluting the context.
    • stldev 7mo ago
      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.
• buremba 7mo ago
  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 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.
  • CharlieDigital 7mo ago
    This is my take as well. Way easier to set up, centralized auth and telemetry. Just use it for the right use cases.
  • bmurphy1976 7mo ago
    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.
    • 0x696C6961 7mo ago
      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.
      • bmurphy1976 7mo ago
        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.
• medi8r 7mo ago
  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.
• Robdel12 7mo ago
  YES, I have been thinking the same and wrote a bit about it: https://vizzly.dev/blog/cli-json-output-llm-friendly/ 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?
  • ejholmes 7mo ago
    Great read. Thanks for sharing. 100% agree, `—json | jq` is where it’s at.
• deadf00d 7mo ago
  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.
• poly2it 7mo ago
  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.
• 0x457 7mo ago
  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.
• righthand 7mo ago
  Lol people are so lost in the bs
• irishcoffee 7mo ago
  *when does an LLM make sense vs writing your own code. Dang, I fixed the title for you.
• steve_adams_86 7mo ago
  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
• fennecbutt 7mo ago
  [dead]
• with 7mo ago
  MCP is a completely useless abstraction, and I’m not sure why anyone would push for it over basic cli tools / skills.
• EnigmaCurry 7mo ago
  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.
• airforce1 7mo ago
  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.
  • bmurphy1976 7mo ago
    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.
• bonoboTP 7mo ago
  > 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.
• aplomb1026 7mo ago
  [flagged]
• nickstinemates 7mo ago
  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 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.
• __MatrixMan__ 7mo ago
  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.
• jpbryan 7mo ago
  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.
• kgwxd 7mo ago
  Been ignoring this junk for a long but I had to look since the front page is littered with "MCP". Is acronym on purpose?
• jwpapi 7mo ago
  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.
• BenoitEssiambre 7mo ago
  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 https://benoitessiambre.com/entropy.html
• ryanthedev 7mo ago
  CLIs are dead. Long live the skill. Which is a wrapper around the CLI! Haha.
• pcarolan 7mo ago
  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.
  • dreamiurg 7mo ago
    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.
• jiehong 7mo ago
  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
• williamsss 7mo ago
  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.
• bhekanik 7mo ago
  [flagged]
• ikidd 7mo ago
  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.
• butcloudagent 7mo ago
  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.
• sunir 7mo ago
  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?
  • baruch 7mo ago
    There is a global setting you can do to disable using the Claude.ai MCPs from being used on your Claude code.
    • sunir 7mo ago
      Thank you so much.
• raw_anon_1111 7mo ago
  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?
• StarterPro 7mo ago
  That's too close to actual programming, vibe coders will never go for it.
• tartieret 7mo ago
  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.
  • paidev 7mo ago
    Underrated comment
  • Roxo 7mo ago
    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.
  • itake 7mo ago
    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.
• aesopturtle 7mo ago
  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.
• dmix 7mo ago
  APIs and CLIs still remain king, just like before. The difference is mostly in UIs and how you deliver it.
• _heimdall 7mo ago
  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`.
• btbuildem 7mo ago
  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!
• swaraj 7mo ago
  This is spot on
• sorcercode 7mo ago
  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/ https://fragmentedpodcast.com/episodes/302/
• jesse_dot_id 7mo ago
  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.
• alfozan 7mo ago
  CLI vs MCP debate misses the protocol's actual value prop: steering the agent: https://cra.mr/context-management-and-mcp https://cra.mr/context-management-and-mcp
• crazylogger 7mo 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?
• realMorrisLiu 7mo ago
  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.
• stevekrouse 7mo ago
  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.
• nvdnadj92 7mo ago
  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 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.
• cagz 7mo ago
  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.
• pmontra 7mo ago
  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.
• thierryfaucher 7mo ago
  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 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.
• ncruces 7mo ago
  What, those job ads asking for 5 years of experience with MCP were useless after all?
• cbcoutinho 7mo ago
  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.
• Nordsym 7mo ago
  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.
• giamma 7mo ago
  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?
  • saberience 7mo ago
    OpenClaw and similar agents do that now without using MCP servers.
• lidn12 7mo ago
  [dead]
• shusaku 7mo ago
  > 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.
• benkaiser 7mo ago
  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 https://github.com/benkaiser/joey-mcp-client
• sonink 7mo ago
  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.
• swaminarayan 7mo ago
  For teams that have tried both, where does MCP clearly outperform just giving the model a CLI?
• sudb 7mo ago
  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.
• Myrmornis 7mo ago
  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.
  • mdemare 7mo ago
    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.
    • Myrmornis 7mo ago
      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.
• jFriedensreich 7mo ago
  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
• mentalgear 7mo ago
  > 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.
• astrostl 7mo ago
  Browser automation: chrome-devtools-mcp, playwright-mcp, etc.
• sarkarsh 7mo ago
  [dead]
  • ejholmes 7mo ago
    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 https://github.com/vercel-labs/agent-browser) handles persistent sessions just fine as a CLI.
• promiseofcli 7mo ago
  Oh no what am I going to do with my MCP tattoos now?
• mamaluigie 7mo ago
  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.