Live data from Hacker News

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

apideck.com

91–100 of 149 posts

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

#91
post #36

While I generally prefer CLI over MCP locally, this is bad outdated information. The major harnesses like Claude Code + Codex have had tool search for months now.

Fair point on tool search. Claude Code and Codex do have it. But tool search is solving the symptom, not the cause. You still pay the per-tool token cost for every tool the search returns. And you've added a search step (with its own latency and token cost) before every tool call. With a CLI, the agent runs `--help` and gets 50-200 tokens of exactly what it needs. No search index, no ranking, no middleware. The binar…

Let me guess the command: [error]

Wait, better check help. is it -h? [error]

Nope? Lemme try —-help. [error]

Nope.

How about just “help” [error]

Let me search the web [tons of context and tool calls]

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

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

IMO if you want a metadata registry of how actions work so you can make complicated, fragile, ACL rule systems of actions, then make that. That doesn't need to be loaded into a context window to make that work and can be expanded to general API usage, tool usage, cli usage, and so on. You can load a gh cli metadata description system and so on.

MCPs are clunky, difficult to work with and token inefficient and security orgs often have bad incentive design to mostly ignore what the business and devs need to actually do their job, leading to "endpoint management" systems that eat half the system resources and a lot of fig leaf security theatre to systematically disable whatever those systems are doing so people can do their job in an IT equivalent that feels like the TSA.

Thank god we moving away from giving security orgs these fragile tools to attach ball and chains to everyone.

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

#93
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

#94
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-overf…

[dead]

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

#95
I’m a huge fan of CLIs over MCP for many things, and I love asking Claude Code to take an API, wrap it in a CLI, and make a skill for me. The ergonomics for the agent and the human are fantastic, and you get all of the nice composability of command line Unix build in.

However, MCPs have some really nice properties that CLIs generally don’t, or that are harder to solve for. Most notably, making API secrets available to the CLI, but not to the agent, is quite tricky. Even in this example, the options are env variables (which are a prompt injection away from dumping), or a credentials file (better, but still very much accessible to the agent if it were asked).

MCPs give you a “standard” way of loading and configuring a set of tools/capabilities into a running MCP server (locally or remotely), outside of the agent’s process tree. This allows you to embed your secrets in the MCP server, via any method you choose, in a way that is difficult or impossible for the agent to dump even if it goes rogue.

My efforts to replicate that secure setup for a CLI have either made things more complicated (using a different user for running CLIs so that you can rely upon Linux file permissions to hide secrets), or start to rhyme with MCP (a memory-resident socket server started before the CLI that the CLI can talk to, much like docker.sock or ssh-agent)

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

#96
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]

Schema validates structure, nothing validates intent. That's the actual attack surface and nobody's talking about it.

CLI `--help` is baked into the binary. You'd need a new release to change it. MCP server descriptions can change between sessions and nothing catches it.

Honestly though, the whole thread is arguing about the wrong layer. I've been doing API infra for 20 years and the pattern is always the same: if your API has good resource modeling and consistent naming, agents will figure it out through CLI, MCP, whatever. If it doesn't, MCP schemas won't save you.

Thanks for the CVE reference, hadn't seen that one.

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

#98
post #80
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…

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 communicating via stdin/stdout, or on a server over HTTP. It exposes a list of tools, each tool has a name and named+typed parameters, just like a list of functions in a program. When you "add" an MCP server to Claude Code or any other client, you simply tell this client app on your machine about this list of tools and it will include this list in its requests to the LLM alongside your prompt.

When the LLM receives your prompt and decides that one of the tools listed alongside would be helpful to answer you, it doesn't return a regular response to your client but a "tool call" message saying: "call with ". Your client does this, and sends back the tool call result to the LLM, which will take this into account to respond to your prompt.

That's pretty much all there is to it: LLMs can't connect to your email or your GitHub account or anything else; your local apps can. MCP is just a way for LLMs to ask clients to call tools and provide the response.

1. You: {message: "hey Claude, how many PRs are open on my GitHub repo foo/bar?", tools: [... github__pr_list(org:string, repo:string) -> [PullRequest], ...] } 2. Anthropic API: {tool_use: {id: 123, name: github__pr_list, input:{org: foo, repo: bar}}} 3. You: {tool_result: {id: 123, content: [list of PRs in JSON]} } 4. Anthropic API: {message: "I see 3 PRs in your repo foo/bar"}

that's it.

If you want to go deeper the MCP website[1] is relatively accessible, although you definitely don't need to know all the details of the protocol to use MCP. If all you need is to use MCP servers and not blow up your context with a massive list of tools that are included with each prompt, I don't think you need to know much more than what I described above.

[1] https://modelcontextprotocol.io/docs/learn/architecture

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

#99
post #80
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…

[flagged]

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

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

> MCP gives us a registry such that we can enforce MCP chain policies

Do you have some more info on it?

looking up "registry" in the mcp spec will just describe a centrally hosted, npm-like package registry[^1]

[^1]: The MCP Registry is the official centralized metadata repository for publicly accessible MCP servers, backed by major trusted contributors to the MCP ecosystem such as Anthropic, GitHub, PulseMCP, and Microsoft.

Post reply on HN