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

101–110 of 127 posts

Re: Making MCP cheaper via CLI

#101

Post by theshrike79 »

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…

MCPs are like a wall full of tools in an already crowded workshop, you can easily access everything but they're also in the way if you need the space for something else.

Skills are like boxes on shelves with a note of "open this if you want to create or edit PDFs", they take way less space and you only open them when you need the contents.

As for tools, harnesses in general don't usually have many of those, maybe 6-10 for reading/writing/searching/web in total.

Re: Making MCP cheaper via CLI

#102

Post by miroljub »

Eldodi wrote: post #99
miroljub wrote: post #93

Earlier quoted context omitted.

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.

> What is really making MCP stand out is:

> - oauth integration

I don't see a reason a cli can't provide oauth integration flow. Every single language has an oauth client.

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

This is actually a valid point. I solved it by using a sane agent harness that doesn't have artificial restrictions, but I understand that some people have limited choices there and that MCP provides some benefits there.

Same story as SOAP, even a bad standard is better than no standard at all and every vendor rolling out their own half-baked solution.

Re: Making MCP cheaper via CLI

#103

Post by _pdp_ »

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

The point of the MCP is for the upstream provider to provider agent specific tools and to handle authentication and session management.

Consider the Google Meet API. To get an actual transcript from Google Meet you need to perform 3-4 other calls before the actual transcript is retrieved. That is not only inefficient but also the agent will likely get it wrong at least once. If you have a dedicated MCP then Google in theory will provide a single transcript retrieval tool which simplifies the process.

The authentication story should not be underestimated either. For better or worse, MCP allows you to dynamically register oauth client through a self registration process. This means that you don't need to register your own client with every single provider. This simplifies oauth significantly. Not everyone supports it because in my opinion it is a security problem but many do.

Re: Making MCP cheaper via CLI

#104

Post by TCattd »

_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…

Another alternative (to mcpshim): https://github.com/EstebanForge/mcp-cli-ent

Direct usage as CLI tool.

Re: Making MCP cheaper via CLI

#105

Post by tymscar »

_pdp_ wrote: post #103
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

The point of the MCP is for the upstream provider to provider agent specific tools and to handle authentication and session management. Consider the Google Meet API. To get an actual transcript from Google Meet you need to perform 3-4 other calls before the actual transcript is retrieved. That is not only inefficient but also the agent will likely get it wrong at least once. If you have a dedicated MCP then Google in…

Or you could just have a cli that does that, no MCP needed

Re: Making MCP cheaper via CLI

#106

Post by jillesvangurp »

I started adding cli's for a few things last week. Initially just for myself but it didn't take me long to figure out that codex / claude code / etc. are pretty good at figuring out cli's as well. And creating them. If you have APIs, generating a usable cli for them is pretty straightforward. With lots of nice features, documentation, bash/zsh autocomplete support and other bells and whistles. Doing that manually is a lot of repetitive work. Having that stuff generated on the other hand doesn't have to take a lot of time.

The combination with skills is where it really shines. And you can generate those as well for your shiny new cli. Once you have that in place, you can drive your API agentically to do non trivial things in it.

One of my OSS projects, jillesvangurp/ktsearch now has such a cli. Ktsearch is a kotlin multiplatform library for Elasticsearch and Opensearch. The new cli compiles to jvm and native linux/mac binaries. I've been playing with this for the last week and adding a few features. It's very nice to have around if you deal with opensearch/elasticsearch clusters. No more messy curl commands and json blobs.

And I've gotten codex to use it for me for a few things already.

Re: Making MCP cheaper via CLI

#107

Post by thellimist »

arjie wrote: post #40

These days you can rewrite everything yourself for very cheap. So this is `mcporter` rewritten. I prefer to use Rust personally for rewrites. Opus 4.6 can churn it out pretty quickly if that's what you want. To be honest, almost all software that I want to try these days I don't even install. Instead I'd rather read the README and produce a personal version. This allows encoding idiosyncrasies and specifics that anot…

Rust doesn't compile different machines well. So choose Go

Re: Making MCP cheaper via CLI

#108

Post by thellimist »

slopinthebag wrote: post #38
thellimist wrote: post #34

Earlier quoted context omitted.

Ofc it is written by ai, I have a skill for it - https://github.com/thellimist/thellimist.github.io/blob/mast... https://github.com/thellimist/thellimist.github.io/blob/mast... I dump a voice message, then blog comes out. Then I modify a bunch of things, and iterate 1-2 hours to get it right

Might need to iterate on them more because it's still quite obviously machine written, and a lot of people find it disrespectful to read content that was LLM generated.

If you read my posts before 2023, it's same style.

I guess my thinking way is similar to LLMs, has clear structure.

I used to have more grammar issues, that LLMs fix, but the high level outline etc. are actually how I think about it. If it's not, I modify it

Re: Making MCP cheaper via CLI

#110

Post by jedisct1 »

MCP servers were a fad, but virtually all of them are completely useless, and often counterproductive for agents that can run code and execute commands directly.

When agents struggle to quickly understand how to use tools, SKILLS provide a far better solution than MCP.

The real issue is that some agents support MCP yet cannot execute any commands without it; tools like Jan or Claude Desktop. With these agents, you can't even access remote APIs, making an MCP necessary despite its limitations.

Post reply on HN