Comment by drdaeman
8 hours 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.
CLI tools are designed to provide complete documentation using —help. Given LLMs are capable of fully understanding the output then how is the MCP standardization any better than the CLI —help standardization?
Read only access control.
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.
Fair enough, I’ll give it a try when I’ll have time for it.
I recognize that MCP as typically used would eat a good chunk of context - shoving all those API specs is wasteful for sure. The solution to this, I believe, is either RAG or single-tool (Context7-like), where relevant APIs are only provided on demand from models’ intermediate requests.
Caveat is model may need training to use that efficiently (or even at all, esp. smaller models are either very shy or crazy with tool use), and I don’t want to spend time fine tuning it. Could be that’s where the reality may prove me wrong.
But a token is a token. There is not a lot of difference between Playwright (or any other tool) use documentation wrapped in JSON with some logical separations, or provided as a long plain text blob (ultimately most likely also wrapped in JSON). So if the model doesn’t know how to use some tool innately (it may, for Playwright), and if it needs to use all tool functionality, I’m sure a CLI wouldn’t fare any better that MCP. But if the model knows the tool or needs just a small bit of its capabilities - naive MCP is going to be a bad idea.
Just like a human. If all I need is some simple thingy, I probably don’t need a whole textbook upfront, just a select excerpt. As far as I understand MCP, supplying full textbook in the system prompt is not MCPs innate design fault, it’s merely a simplest implementation approach.
> then you should create an example repo that shows the playwright CLI and playwright MCP add the same number of tokens to context and that both are equally configurable in this respect
That's just implementation detail of how your agent harness decides to use MCP. CLI and MCP are on different abstraction layers. You can have your MCP available through CLI if you wish so.
Please, please, please actually do this yourself or read any of the top comments. You are still missing the point, which you will understand if you actually do this and then look at the logs.