Bonus point is you say why.
Are you team MCP or team CLI?
1–10 of 26 posts
Re: Are you team MCP or team CLI?
#2CLI doesn't make any sense.
They are insecure, dangerous have footguns and based on old primitives that are bad for humans and agents.
CLIs are just a trendy fad currently but will fade away for anything used in serious usecases.
Why would you want to use a CLI for an API when an API is more quicker and less error prone than CLIs.
We need to move away from suboptimally thinking CLIs solve the problem of less token usage entirely.
In the long run, MCPs are only in its infancy stage, and make the most sense for businesses and actual users.
Just because an agent can use a CLI doesn't mean it's the best solution, IMO it is the worst solution.
Re: Are you team MCP or team CLI?
#3CLI doesn't make any sense. They are insecure, dangerous have footguns and based on old primitives that are bad for humans and agents. CLIs are just a trendy fad currently but will fade away for anything used in serious usecases. Why would you want to use a CLI for an API when an API is more quicker and less error prone than CLIs. We need to move away from suboptimally thinking CLIs solve the problem of less token us…
It sounds like you are saying CLI is better now, but not in the long term? If someone is optimizing for less token usage.
Re: Are you team MCP or team CLI?
#4CLI doesn't make any sense. They are insecure, dangerous have footguns and based on old primitives that are bad for humans and agents. CLIs are just a trendy fad currently but will fade away for anything used in serious usecases. Why would you want to use a CLI for an API when an API is more quicker and less error prone than CLIs. We need to move away from suboptimally thinking CLIs solve the problem of less token us…
It sounds like you are saying CLI is better now, but not in the long term? If someone is optimizing for less token usage.
I'm saying it's the wrong solution completely because it's currently a fad.
Re: Are you team MCP or team CLI?
#5Why not both ?
Re: Are you team MCP or team CLI?
#6CLI is a clear choice (right now) for terse, individual use cases, but we need to remember - MCP is a protocol and a new one.
If we think back, even HTTP needed a decade to stabilize and dominate the other early web protocols. Before we throw out MCP, we'll have to see how important stateful vs stateless is for agents. It is still early days of real-world development!
Re: Are you team MCP or team CLI?
#7Team everyone should have APIs that I can get to with or without LLMs.
Re: Are you team MCP or team CLI?
#8CLIs, usually they just work better. I was recently using the Chronosphere MCP server and got great results from it. Then one day it just stopped authenticating. My key was still valid but try as I might I could not use the MCP server anymore. So I just said
"Use the Chronosphere key at $ENVVAR and make yourself a CLI that uses the Chronosphere API. All I need you to do is run PromQL queries, whatever that API is"
And it wrote it in 60s and it works perfectly. I get the same results I got from the MCP server except there is less overhead, both in context and in my mind.
Re: Are you team MCP or team CLI?
#9Doesn't CLI use MCP (if need-be) ? I think you might attempting to say "Neat, discrete buckets of work?" (i.e., MCP - similar to HTTP in that work is broken into discrete canonical buckets), or "Virtually unbounded work made available via various CLI utilities?".
I would pick the second option. CLI.
However, for CRUD B2B SaaS I think MCP works fine (if not better than CLI).
Re: Are you team MCP or team CLI?
#10CLI because if you have to ask, the answer is almost always the more simple one