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

131–140 of 149 posts

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

#131

Post by JyB »

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

This has always surprised me as this always comes up in MCP discussions. To me, it just seem like a matter of updating the protocol to not have that context hungry behaviour. Doesn't seem like an insurmountable problem technically.

Glad you say it has already been addressed. Was the protocol itself updated to reflect that? Or are you just referring to off-spec implementations?

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

#132

Post by antihero »

zamalek wrote: post #24
antihero wrote: post #16

Earlier quoted context omitted.

Can the MCP tell them how to use the CLI? Surely that would mean less time wasted on discovering it each time. Going to try this with fastmail-cli and see what happens.

Yes, MCP instructions are a blob that is injected at the start of the context. That file is prefixed to the agent specific help[1] for the instructions (that is returned if --help is invoked with CLAUDE=1 or AGENT=1). [1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/age...

Ah cool, that said: If your tool is primarily for Claude Desktop (or mobile if hosted), that surely needs the MCP to actually do anything right?

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

#134

Post by BTAQA »

Using MCP daily as a solo founder with Claude Code. The "consistent rails" point resonates. The value isn't just tool calling, it's that the agent knows how to behave within a defined boundary. The security posture argument is underrated too. Giving a CLI unrestricted box access vs a hosted MCP server with scoped permissions is a completely different risk profile.

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

#135

Post by zamalek »

antihero wrote: post #132
zamalek wrote: post #24

Earlier quoted context omitted.

Yes, MCP instructions are a blob that is injected at the start of the context. That file is prefixed to the agent specific help[1] for the instructions (that is returned if --help is invoked with CLAUDE=1 or AGENT=1). [1]: https://github.com/jcdickinson/ferrisfetch/blob/main/cmd/age...

Ah cool, that said: If your tool is primarily for Claude Desktop (or mobile if hosted), that surely needs the MCP to actually do anything right?

I'm not sure about Claude Desktop (it must surely have CLI access?), but I think your line of thinking is correct.

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

#136

Post by dirk94018 »

MCP is a bit of a rube goldberg machine. Unix solved that problem. Pipe text in, get text out, discover capabilities incrementally. The fact that we need benchmarks to prove CLIs use fewer tokens than dumping 55k of JSON schema upfront is embarrassing. toast is just pipe stuff to an LLM and let stdin/stdout be the protocol. No schema tax, no connection lifecycle, no tool registry middleware to manage your middleware. The thing is that AIs are just not good at outputting structure, like people, json isn't natural.

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

#137

Post by dirk94018 »

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…

Unix approach can be surprisingly powerful.

https://linuxtoaster.com/blog/gradientdescentforcode.html

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

#138

Post by dirk94018 »

user3939382 wrote: post #116
brabel wrote: post #104

Earlier quoted context omitted.

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

Totally agree. We need to get the ratio between deterministic and non deterministic software right.

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

#140

Post by krzyk »

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.

They are not also, but I like that they didn't ban those, we can use agents thanks to that.
Post reply on HN