- MCP - if you need discoverability. a great example for this is something like context7
- CLI/API + Skill: When you have a defined workflow you want to use. For me a good example of this is using the Linear GraphQL API instead of their MCP
I prefer the Linear API because, where I work, we have come up with our way of using the tool so I don't need the entire MCP to do what I need the agent to do. I think for most use cases an MCP is a waste of context.
Team CLI. I generally think we should build tools that are usable by humans and agents alike. An anti-pattern is having to use an agent to do something because you didn't build a human-accessible one. Another anti-pattern are MCP (Model Context Protocol) interfaces that are not managing any context.
That said, MCP could be an effective way to sandbox what an agent can do with a tool. Also, it seems plausible to me that a tool that actually provided information to a model via the MCP protocol could be more useful than a CLI tool which operates in the "silence means success" mode of most unix CLI tools.
Basically, make a design choice for _reasons_ and not just because you like that TLA of the option you picked.
Doesn'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).
CLI 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!
CLIs, 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.
To me it depends on the intended use:
- MCP - if you need discoverability. a great example for this is something like context7
- CLI/API + Skill: When you have a defined workflow you want to use. For me a good example of this is using the Linear GraphQL API instead of their MCP
I prefer the Linear API because, where I work, we have come up with our way of using the tool so I don't need the entire MCP to do what I need the agent to do. I think for most use cases an MCP is a waste of context.
The trend toward AI-native content formats suggests we are moving toward a web that serves machines and humans simultaneously.
Team CLI. I generally think we should build tools that are usable by humans and agents alike. An anti-pattern is having to use an agent to do something because you didn't build a human-accessible one. Another anti-pattern are MCP (Model Context Protocol) interfaces that are not managing any context.
That said, MCP could be an effective way to sandbox what an agent can do with a tool. Also, it seems plausible to me that a tool that actually provided information to a model via the MCP protocol could be more useful than a CLI tool which operates in the "silence means success" mode of most unix CLI tools.
Basically, make a design choice for _reasons_ and not just because you like that TLA of the option you picked.
Team everyone should have APIs that I can get to with or without LLMs.
So, neither?
Doesn'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).
CLI 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!
CLI because if you have to ask, the answer is almost always the more simple one
I would go with MCP because it can run over the internet with authentication, and it has JSON schemas.
CLIs, 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.
Why not both ?
CLI 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.
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.