I have for a lot of my own tools and personal stuff a slightly different approach with this that doesn't use MCP. If you combine skills, with a thin CLI for any API you get a dramatically cheaper version of an MCP and with all the benefits of it just being a simple CLI. Most of the time if I have something like Linear or Hubspot, I just point it at the actual API docs and ask the LLM to make a thin CLI for that API. That way I don't have to load tools for the CLI until needed by a slash command, but the definitions are also tiny so my context stays mostly free.
Making MCP cheaper via CLI
121–127 of 127 posts
Re: Making MCP cheaper via CLI
#122It is not better because it invalidates caches.
Re: Making MCP cheaper via CLI
#123Earlier quoted context omitted.
This was my initial understanding but if you want ai agents to do complex multi step workflows I.e. making data pipelines they just do so much better with MCP. After I got the MCP working my case the performance difference was dramatic
Yeah this is just straight up nonsense. Its ability to shuffle around data and use bash and do so in interesting ways far outstrips its ability to deal with MCPs. Also remember to properly name your cli tools and add a `use --help for doing x` in your AGENTS.md, but that is all you need. Maybe you're stuck on some bloated frontend harness?
> Yeah this is just straight up nonsense.
I was just sharing my experience I'm not sure what you mean. Just n=1 data point.
From first principles I 100% agree and yes I was using a CLI tool I made with typer that has super clear --help + had documentation that was supposed to guide multi step workflows. I just got much better performance when I tried MCP. I asked Claude Code to explain the diff:
> why does our MCP onbaroding get better performance than the using objapi in order to make these pipelines? Like I can see the performance is better but it doesn't intuitively make sense to me why an mcp does better than an API for the "create a pipeline" workflow
It's not MCP-the-protocol vs API-the-protocol. They hit the same backend. The difference is who the interface was designed for.
The CLI is a human interface that Claude happens to use. Every objapi pb call means:
- Spawning a new Python process (imports, config load, HTTP setup)
- Constructing a shell command string (escaping SQL in shell args is brutal)
- Parsing Rich-formatted table output back into structured data
- Running 5-10 separate commands to piece together the current state (conn list, sync list, schema classes, etc.)
The MCP server is an LLM interface by design. The wins are specific:
1. onboard://workspace-state resource — one call gives Claude the full picture: connections, syncs, object classes, relations, what exists, what's missing. With the CLI, Claude
runs a half-dozen commands and mentally joins the output.
2. Bundled operations — explore_connection returns tables AND their columns, PKs, FKs in one response. The CLI equivalent is conn tables → pick table → conn preview for each. Fewer
round-trips = fewer places for the LLM to lose the thread.
3. Structured in, structured out — MCP tools take JSON params, return JSON. No shell escaping, no parsing human-formatted tables. When Claude needs to pass a SQL string with quotes
and newlines through objapi pb node add sql --sql "...", things break in creative ways.
4. Tool descriptions as documentation — the MCP tool descriptions are written to teach an LLM the workflow. The CLI --help is written for humans who already know the concepts.
5. Persistent connection — the MCP server keeps one ObjectsClient alive across all calls. The CLI boots a new Python process per command.
So the answer is: same API underneath, but the MCP server eliminates the shell-string-parsing impedance mismatch and gives Claude the right abstractions (fewer, chunkier operations
with full context) instead of making it pretend to be a human at a terminal.
Re: Making MCP cheaper via CLI
#124The best things about AI hypergrowth is the opportunities to discover of meta-frameworks and workflows. This is something Anthropic kills at (MCPs, Skills, Claude Code terminal agents). These are discoveries of workflows. Some of them work some of them don’t. The ones that really click, they explode in popularity like OpenClaw.
How does MCP differ from Skills?
From use case point of view
skills are unstructured. MCP is structured.
You don't want stripe skill. You want stripe MCP of CLI to interact with. When stripe does an update you want to have it.
I didn't go into technical details or anything. Just laid the most important use case that skills cannot be sufficient
Re: Making MCP cheaper via CLI
#125This article is solving a problem that shouldn't exist in the first place. If you're loading 84 MCP tools into every session, the issue isn't MCP vs CLI, it's that you've turned on everything without thinking about when each tool is actually relevant. MCP's token cost is the price of availability. The fix isn't to replace the protocol, it's to only activate the tools that matter for the current context. Claude's Skil…
I go with this approach for all my personal tools and find it much easier to use and have CC or any LLM reason how to use the tools, and the added benefit that it has a super small footprint in context. https://gist.github.com/Shehryar/22059e16ba70a42fc72c13fde9f...
Re: Making MCP cheaper via CLI
#126Is there any redeeming quality of MCP vs a skill with CLI tool? Right now it looks like the latter is a clear winner. Maybe MCP can help segregate auto-approve vs ask more cleanly, but I don't actually see that being done.
MCP defines a consistent authentication protocol. This is the real issue with CLIs, each CLI can (and will) have a different way of handling authentication (env variables, config set, JSON, yml, etc). But tbh there's no reason agents can't abstract this out. As long as a CLI has a --help or similar (which 99% do) with a description of how to login, then it can figure it out for you. This does take context and tool ca…
That's fair. I just really don't like the way MCP gives the tool author control of my context. It's worth setting up some env vars and config files to avoid them.
Re: Making MCP cheaper via CLI
#127MCP
> learn new protocol
> bloat your context with unnecessary tools
> decision overload for agents
> spin up new server, more code to document and maintain
> pain to debug
> constantly changing
CLIs
> 0 context bloat
> one-line install
> on-demand discovery via --help commands
> fast and lightweight
> every model knows bash, even dumb ones
> composable, can chain commands (massively underrated, e.g. cli users list --output json | jq '.[].id' )
> save $$$ on tokens
> no new servers or docs
> can use tools like https://instantcli.com to generate one for any API