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

81–90 of 127 posts

Re: Making MCP cheaper via CLI

#81

Post by paulddraper »

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

MCP is just JSON-RPC plus dynamic OAuth plus some lifecycle things.

It’s a convention.

That everyone follows.

Re: Making MCP cheaper via CLI

#82

Post by crazylogger »

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

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.

Re: Making MCP cheaper via CLI

#83

Post by matheus-rr »

The context window cost is the real story here. Every MCP tool description gets sent on every request regardless of whether the model needs it. If you have 20 tools loaded, that's potentially thousands of tokens of tool descriptions burned before the model even starts thinking about your actual task.

CLI tools sidestep this completely because the agent only needs to know the tool exists and what flags it takes. The actual output is piped and processed, not dumped wholesale into context. And you get composability for free - pipe to jq, grep, head, whatever.

The auth story is where MCP still wins though. If you need a user to connect their Slack or GitHub through a web UI, you need that OAuth dance somewhere. CLI tools assume you already have credentials configured locally, which is fine for developer tooling but doesn't work for consumer-facing AI products.

For developer workflows specifically, I think the sweet spot is what some people are calling SKILL files - a markdown doc that tells the agent what CLI tools are available and when to use them. Tiny context footprint, full composability, and the agent can read the skill doc once and cache it.

Re: Making MCP cheaper via CLI

#85

Post by zamalek »

thellimist wrote: post #16
mijoharas wrote: post #5

This sounds similar to MCPorter[0], can anyone point out the differences? [0] https://github.com/steipete/mcporter

Main differences are CLIHub - written in go - zero-dependency binaries - cross-compilation built-in (works on all platforms) - supports OAuth2 w/ PKCE, S2S, Google SA, API key, basic, bearer. Can be extended further MCPorter - TS - huge dependency list - runtime dependency on bun - Auth supports OAuth + basic token - Has many features like SDK, daemons (for certain MCPs), auto config discovery etc. MCPorter is more c…

I'm a rust fanboy, but I conceded to Go a long time ago as the ideal language to write MCPs in. I know rust can do a musl build, but the fact it's defacto goes a long way.

Back to the article. I've written a few MCPs and the fact that it uses JSON is incredibly unfortunate. In one recent project - not an MCP - I cut token count (not character count) of truly unavoidable context to ~60% just by reformatting it as markdown.

I think I might just try my MCPs as CLIs.

Re: Making MCP cheaper via CLI

#89

Post by jspdown »

matheus-rr wrote: post #83

The context window cost is the real story here. Every MCP tool description gets sent on every request regardless of whether the model needs it. If you have 20 tools loaded, that's potentially thousands of tokens of tool descriptions burned before the model even starts thinking about your actual task. CLI tools sidestep this completely because the agent only needs to know the tool exists and what flags it takes. The a…

On my personal coding agent I've introduced a setup phase inside skills.

I distribute my skills with flake.nix and a lock file. This flake installs the required dependencies and set them up. A frontmatter field defines the name of secrets that need to be passed to the flake.

As it is, it works for me because I trust my skill flakes and skills are static in my system: -I build an agent docker image for the agent in which I inject the skills directory. -Each skill is setup when building the image -Secret are copied before the setup phase and removed right after

All in all, Nix is quite nice for Skills :)

Re: Making MCP cheaper via CLI

#90

Post by with »

MCP's only real value is the auth handshake for third-party SaaS. the actual tool execution is worse than a subprocess call. more tokens, harder to debug, and the failure modes are worse. if someone just extracted the OAuth layer into a standard that CLIs could use, there's very little reason for the rest of the protocol to exist.
Post reply on HN