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

Apideck CLI – An AI-agent interface with much lower context consumption than MCP

apideck.com

Post reply on HN
Print view View original

81–90 of 149 posts

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#81

Post by thecopy »

krzyk wrote: post #59
yoyohello13 wrote: post #34

Earlier quoted context omitted.

It is a weird trend. I see the appeal of Skills over MCP when you are just a solo dev doing your work. MCP is incredibly useful in an organization context when you need to add controls and process. Both are useful. I feel like the anti-MCP push is coming from people who don't need to work in a large org.

Not sure. Our big org, banned MCPs because they are unsafe, and they have no way to enforce only certain MCPs (in github copilot).

Shameless plug: im working on a product that aims to solve this: https://www.gatana.ai/

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#82

Post by dend »

o_____________o wrote: post #70
dend wrote: post #44

One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases. The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-…

> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation How, "Dynamic Tool Discovery"? Has this been codified anywhere? I've only see somewhat hacky implementations of this idea https://github.com/modelcontextprotocol/modelcontextprotocol... Or are you talking about the pressure being on the client/harnesses as in, https://platform.clau…

More of the latter than the former. The protocol itself is constrained to a set of well-defined primitives, but clients can do a bunch of pre-processing before invoking any of them.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#83

Post by newswasboring »

thenewnewguy wrote: post #64
krzyk wrote: post #59

Earlier quoted context omitted.

Not sure. Our big org, banned MCPs because they are unsafe, and they have no way to enforce only certain MCPs (in github copilot).

But skills where you tell the LLM to shell out to some random command are safe? I'm not sure I understand the logic.

I think big companies already protect against random commands causing damage. Work laptops are tightly controlled for both networking and software.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#84

Post by polynomial »

caust1c wrote: post #22

I'm getting tired of everyone saying "MCP is dead, use CLIs!". Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills. The problem with tossing it out entirely is that it leaves a lot more questions for handling security. When using skills, there's no implicit way to be able to apply policies in the sane way across many…

This is the right framing. The chain policy problem is what happens when you ask the registry to be the entitlement layer.

Here's a longer piece on why the trust boundary has to live at the runtime level, not the interface level, and what that means for MCP's actual job: https://forestmars.substack.com/p/twilight-of-the-mcp-idols

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#86

Post by bazhand »

I ran into this exact problem building a MCP server. 85 tools in experimental mode, ~17k tokens just for the tool manifest before any work starts.

The fix I (well Codex actually) landed on was toolset tiers (minimal/authoring/experimental) controlled by env var, plus phase-gating, now tools are registered but ~80% are "not connected" until you call _connect. The effective listed surface stays pretty small.

Lazy loading basically, not a new concept for people here.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#87

Post by robot-wrangler »

caust1c wrote: post #22

I'm getting tired of everyone saying "MCP is dead, use CLIs!". Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills. The problem with tossing it out entirely is that it leaves a lot more questions for handling security. When using skills, there's no implicit way to be able to apply policies in the sane way across many…

> I'm getting tired of everyone saying "MCP is dead, use CLIs!".

The people saying this and attacking it should first agree about the question.

Are you combining a few tools in the training set into a logical unit to make a cohesive tool-suite, say for reverse engineering or network-debugging? Low stakes for errors, not much on-going development? Great, you just need a thin layer of intelligence on top of stack-overflow and blog-posts, and CLI will probably do it.

Are you trying to weld together basically an AI front-end for an existing internal library or service? Is it something complex enough that you need to scale out and have modular access to? Is it already something you need to deploy/develop/test independently? Oops, there's nothing quite like that in the training set, and you probably want some guarantees. You need a schema, obviously. You can sort of jam that into prompts and prayers, hope for the best with skills, skip validation and risk annotations being ignored, trust that future opaque model-change will be backwards compatible with how skills are even selected/dispatched. Or.. you can use MCP.

Advocating really hard for one or the other in general is just kind of naive.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#88

Post by hparadiz »

gitonup wrote: post #61
rib3ye wrote: post #50

Earlier quoted context omitted.

OSes and software engs did not end up using less RAM.

Measurable responses to the environment lag, Moore's law has been slowing down (e: and demand has been speeding up, a lot). From just a sustainability point, I really hope that the parent post's quote is true, because otherwise I've personally seen LLMs used over and over to complete the same task that it could have been used for once to generate a script, and I'd really like to be able to still afford to own my own…

How many times have we implemented Hello World?

I'm using local models on a 6 year old AMD GPU that would have felt like a technology indistinguishable from magic 10 years ago. I ask it for crc32 in C and it gives me an answer. I ask it to play a game with me. It does. If I'm an isolated human this is like a magic talking box. But it's not magic. It doesn't use more energy than playing a video game either.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#89

Post by agoodusername63 »

lionkor wrote: post #29
hparadiz wrote: post #3

10 years from now: "Can you believe they did anything with such a small context window?"

10 years from now: "The next big thing: HENG - Human Engineers! These make mistakes, but when they do, they can just learn from it and move on and never make it again! It's like magic! Almost as smart as GPT-63.3-Fast-Xtra-Ultra-Google23-v2-Mem-Quantum"

I would love to live in a world where my coworkers learn from their mistakes

is this Human 2.0? I only have 1.0a beta in the office.

I get the joke but it really does highlight how flimsy the argument is for humans. IME humans frequently make simple errors everywhere they don’t learn from and get things right the first time very rarely. Damn. Sounds like LLMs. And those are only getting better. Humans aren’t.

Re: Apideck CLI – An AI-agent interface with much lower context consumption than MCP

#90

Post by siva7 »

il wrote: post #42
caust1c wrote: post #22

I'm getting tired of everyone saying "MCP is dead, use CLIs!". Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills. The problem with tossing it out entirely is that it leaves a lot more questions for handling security. When using skills, there's no implicit way to be able to apply policies in the sane way across many…

Tool search pretty much completely negates the MCP context window argument.

Evidence?
Post reply on HN