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

101–110 of 149 posts

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

#101

Post by eikenberry »

hparadiz wrote: post #88
gitonup wrote: post #61

Earlier quoted context omitted.

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.

Which models?

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

#103

Post by hparadiz »

eikenberry wrote: post #101
hparadiz wrote: post #88

Earlier quoted context omitted.

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.

Which models?

Most recently https://lmstudio.ai/models/qwen/qwen3.5-9b

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

#104

Post by brabel »

ewild wrote: post #80
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 feel like I don't fully understand mcp. I've done research on it but I definitely couldn't explain it. I get lost on the fact that to my knowledge it's a server with API endpoints that are well defined into a json schema then sent the to LLM and the LLM parses that and decides which endpoints to hit (I'm aware some llms use smart calling now so they load the tool name and description but nothing else until it's cal…

You need to go back to LLM tools. Before MCP, you could write tools for your LLM to use by normally using Python, something like this:

    @tool def do_great_thing(arg: string) -> string:
        // todo
The LLM now understands that to do the great thing, it can just call this function and get some result back that - which it will use to answer some query from the user.

Notice that the tool uses structured inputs/outputs (the types - they can also be "dictionaries", or objects in most languages - giving the LLM powerful capabilities).

Now, imagine you want to write this in any language. What do you do?

Normally, you create some sort of API for that. Something like good old RPC. Which is essentially what MCP does: it defines a JSON-RPC API for tools, but it also adds some useful stuff, like access to static resources, elicitation (ask user for input outside of the LLM's chat) and since the MCP auth spec, an unified authorization system based on OAuth. This gives you a lot of advantages over a CLI, as well as some disadvantages. Both make sense to use. For example, for web usage, you just want the LLM to call Curl! No point making that a MCP server (except perhaps if you want to authorize access to URLs?). However, if you have an API that exposes a lot of stuff (e.g. JIRA) you definitely want a MCP for that. Not only does it get only the access you want to give the LLM instead of using your own credentials directly, now you can have a company wide policy for what can be done by agents when accessing your JIRA (or whatever) system.

A big disadvantage of MCP is that all the metadata to declare the RPC API take a lot of context, but recently agents are smart about that and load that partially and lazily as required, which should fix the problem.

In summary: whatever you do, you'll end up with something like MCP once you introduce "enterprise" users and not just yolo kids giving the LLM access to their browsers with their real credentials and unfiltered access to all their passwords.

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

#105

Post by Toby11 »

ewild wrote: post #80
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 feel like I don't fully understand mcp. I've done research on it but I definitely couldn't explain it. I get lost on the fact that to my knowledge it's a server with API endpoints that are well defined into a json schema then sent the to LLM and the LLM parses that and decides which endpoints to hit (I'm aware some llms use smart calling now so they load the tool name and description but nothing else until it's cal…

LLM is not doing the work.. your code is doing the work, LLM is just telling you which of the functions (aka tools) you should run.

web search is also another tool and you can gate it with logic so LLMs don’t go rogue.

that’s kinda simplest explanation i guess

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

#106

Post by brabel »

thecopy wrote: post #81
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).

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

Who isn't?

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

#107

Post by amzil »

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

The post isn't MCP vs CLI. It covers where MCP wins.

> The entire security posture of "Install this CLI with access to everything on your box" terrifies me This is fair for hosted MCPs, However I'm not claiming the CLI is universally more secure. users needs to know what they're doing.

Honestly though, after 20 years of this, the whole thread is debating the wrong layer. A well-designed API works through CLI, MCP, whatever. A bad one won't be saved by typed schemas.

> At this point it's just a trope that is repeated from blog post to blog post

Well, "Use whatever gets the job done" and "it's just a trope" can't both be true. If the CLI gets the job done for some use cases, it's not a trope. It's an option. And I'd argue what's happening is the opposite of a trope. Nobody's hyping CLIs because they're exciting. There's no protocol foundation, no spec committee, no ecosystem to sell into. CLIs are 40-year-old boring technology. When multiple teams independently reach for the boring tool, that's a signal, not a meme.

> This blog post too alludes to this and talks about the need for infrastructure to make it work

When tool search is baked into Claude Code, that's Anthropic building and maintaining the infrastructure for you. The search index, ranking, retrieval pipeline, caching. It didn't disappear. It moved.

And it only works in clients that support it. Try using tool search from a custom Python agent, a bash script, or a CI/CD pipeline. You're back to loading everything.

A CLI doesn't need the client to do anything special. `--help` works everywhere. That's the difference between infrastructure that's been abstracted away for some users and infrastructure that's genuinely not needed.

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

#108

Post by kayig »

nzoschke wrote: post #48

The industry is talking in circles here. All you need is "composability". UNIX solved this with files and pipes for data, and processes for compute. AI agents are solving this this with sub-agents for data, and "code execution" for compute. The UNIX approach is both technically correct and elegant, and what I strongly favor too. The agent + MCP approach is getting there. But not every harness has sub-agents, or their…

[flagged]
Post reply on HN