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

111–120 of 149 posts

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

#111

Post by strbean »

agoodusername63 wrote: post #89
lionkor wrote: post #29

Earlier quoted context omitted.

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.

> Did you know if you ask a question and it doesn't know the answer, sometimes it just makes something up?!

I think maybe a lot of us live in a bubble where the above statement is less frequently true of our peers than average.

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

#112

Post by pmontra »

thamer wrote: post #98
ewild wrote: post #80

Earlier quoted context omitted.

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…

There is not a lot to learn to understand the basics, but maybe one step that's not necessarily documented is the overall workflow and why it's arranged this way. You mentioned the LLM "using web search" and it's a related idea: LLMs don't run web searches themselves when you're using an MCP client, they ask the client to do it. You can think of an MCP server as a process exposing some tools. It runs on your machine…

Maybe it's because of the example, but if the LLM knows the GitHub CLI and I bet it knows it, shouldn't it be able to run the commands (or type them for us) to count the open PRs on foo/bar?

However I see the potential problem of the LLM not knowing an obscure proprietary API. The traditional solution has been writing documentation, maybe on a popular platform like Postman. In that case the URL of the documentation could be enough, or an export in JSON. It usually contains examples too. I dread having to write and maintain both the documentation for humans and the MCP server for bots.

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

#113

Post by justboy1987 »

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…

[flagged]

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

#114

Post by vesselapi »

OsrsNeedsf2P wrote: post #8
gertjandewilde wrote: post #2

We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message. The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts. The post covers the benc…

How is progressive discovery not more expensive due to the increased number of steps?

[dead]

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

#115

Post by ewild »

Toby11 wrote: post #105
ewild wrote: post #80

Earlier quoted context omitted.

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

Ok so in a situation like regular orchestration you would essentially layout all possible steps the LLM can take in your code in a big orchestration layer, and if it hits the sensitive endpoint the orchestration that can occur past that will block off web search. In the design that is. But for something like a manus style agent where you're outsourcing all the work but allowing it to hit your MCP it just becomes a regular API the LLM can call

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

#116

Post by user3939382 »

brabel wrote: post #104
ewild wrote: post #80

Earlier quoted context omitted.

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

For my requirements, over 90% of the LLM integrations and rollouts have it exactly backwards. The only thing you want these agents doing is building modular, testable traditional CLI tools which can then be scripted as easily by a human or agent with almost no context/learning required. Humans must distill the probabalism of agent output into composable deterministic functions.

Pushing opaque probabalistic black boxes into the execution of your day to day operations, communications, whatever it is, is horrible even if it works. At best it’s a pyrrhic victory. I see startups using these agents to mitigate healthcare disputes.

There’s no such thing as a domain that resists modeling but for which you could accept a probabilistic result. Probabilistic must also mean probabilistically acceptable. We have words for the only counter examples: drafting, brainstorming, maybe triage.

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

#119

Post by iam_circuit »

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…

[dead]
Post reply on HN