Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making MCP cheaper via CLI

kanyilmaz.me

Post reply on HN
Print view View original

71–80 of 127 posts

Re: Making MCP cheaper via CLI

#71

Post by CuriouslyC »

foota wrote: post #63

Does tool calling in general bloat context, or is there something particular about MCP? One thing I have read recently is that when you make a tool call it forces the model to go back to the agent. The effect of this is that the agent then has to make another request with all of the prompt (include past messages), these will be "cached" tokens, but they're still expensive. So if you can amortize the tool calls by hav…

MCP includes tool definitions in context, whereas models just "know" shell commands and common language tools.

Re: Making MCP cheaper via CLI

#72

Post by martinald »

OsrsNeedsf2P wrote: post #48

So much incorrect and misinformation in these comments. As someone who is building an agent[0] with MCP tools, neither the MCP tool description nor the response is the problem. Both of those are easily solved by not bloating them. The real killer is the input tokens on each step. If you have 100k tokens in the conversation, and the LLM calls an MCP tool, the output and the existing conversation is sent back. So now y…

But this is just the nature of LLMs (so far). Every "conversation" involves sending the entire conversation history back.

The article misses imo the main benefit of CLIs vs _current_ MCP implementations [1], the fact that they can be chained together with some sort of scripting by the agent.

Imagine you want to sum the total of say 150 order IDs (and the API behind the scenes only allows one ID per API calls).

With MCP the agent would have to do 150 tool calls and explode your context.

With CLIs the agent can write a for loop in whatever scripting language it needs, parse out the order value and sum, _in one tool call_. This would be maybe 500 tokens total, probably 1% of trying to do it with MCP.

[1] There is actually no reason that MCP couldn't be composed like this, the AI harnesses could provide a code execution environment with the MCPs exposed somehow. But noone does it ATM AFIAK. Sort of a MCP to "method" shim in a sandbox.

Re: Making MCP cheaper via CLI

#73

Post by eli »

ianm218 wrote: post #55
tymscar wrote: post #54

Earlier quoted context omitted.

So basically the best way to use MCP is not to use it at all and just call the APIs directly or through a CLI. If those dont exist then wrapping the MCP into a CLI is the second best thing. Makes you wonder whats the point of MCP

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

I have never had a problem using cli tools intead of mcp. If you add a little list of the available tools to the context it's nearly the same thing, though with added benefits of e.g. being able to chain multiple together in one tool call

Re: Making MCP cheaper via CLI

#75

Post by eongchen »

This 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 Skills already work this way -> lightweight descriptions loaded upfront, full definitions fetched on demand. That's essentially the same lazy-loading pattern CLIHub describes, just built into the model's native workflow.

Re: Making MCP cheaper via CLI

#76

Post by miki123211 »

_pdp_ wrote: post #23

There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted…

I'd add to that that every tool should have --json (and possibly --output-schema flags), where the latter returns a Typescript / Pydantic / whatever type definition, not a bloated, token-inefficient JSON schema. Information that those exist should be centralized in one place.

This way, agents can either choose to execute tools directly (bringing output into context), or to run them via a script (or just by piping to jq), which allows for precise arithmetic calculations and further context debloating.

Re: Making MCP cheaper via CLI

#78

Post by max8539 »

I’m trying to use the CLI whenever possible - it’s much easier to install and can be used by both me and the agent. For example, gh seems much easier than installing and setting up an MCP server connection, and it’s more human-readable in terms of what the agent is calling and what it’s getting in return.

For other integrations, I first try to find an official or unofficial CLI tool (a wrapper around the API), and only then do I consider using MCP

Re: Making MCP cheaper via CLI

#79

Post by ianm218 »

eli wrote: post #73
ianm218 wrote: post #55

Earlier 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

I have never had a problem using cli tools intead of mcp. If you add a little list of the available tools to the context it's nearly the same thing, though with added benefits of e.g. being able to chain multiple together in one tool call

Not doubting you just sharing my experience - was able to get dramatically better experience for multi step workflows that involve feedback from SQL compilers with MCP. Probably the right harness to get the same performance with the right tools around the API calls but was easier to stop fighting it for me

Re: Making MCP cheaper via CLI

#80

Post by TeMPOraL »

eggplantiny wrote: post #56

I'm looking at this from a slightly different level of abstraction. The CLI approach definitely has practical benefits for token reduction. Not stuffing the entire schema into the runtime context is a clear win. But my main interest lies less in "token cost" and more in "how we structure the semantic space." MCP is fundamentally a tool-level protocol. Existing paradigms like Skills already mitigate context bloat and…

shell is already an answer to your questions. Basic shell constructs and well-known commands provide the abstractions you ask about. `cat`, `grep` and pipes and redirects may not be semantically pure, but they're pretty close to universal, are widely used both as tools and as "semantic primitives", and most importantly, LLMs already know how to use them as both.
Post reply on HN