Live data from Hacker News

Claude Advanced Tool Use

anthropic.com

231–240 of 280 posts

Re: Claude Advanced Tool Use

#231

The Programmatic Tool Calling has been an obvious next step for a while. It is clear we are heading towards code as a language for LLMs so defining that language is very important. But I'm not convinced of tool search. Good context engineering leaves the tools you will need so adding a search if you are going to use all of them is just more overhead. What is needed is a more compact tool definition language like, I d…

I've been experimenting with giving the LLM a Prolog-based DSL, used in a CodeAct style pattern similar to Huggingface's smolagents. The DSL can be used to orchestrate several tools (MCP or built in) and LLM prompts. It's still very experimental, but a lot of fun to work with. See here: https://github.com/deepclause/deepclause-desktop.

Re: Claude Advanced Tool Use

#232

Earlier quoted context omitted.

This would be awesome, but great CLIs would have already been valuable prior to the age of LLMs and yet most services didn't ship one. I think it is because services like Jira and others do not want to be too open. Ultimately, despite the current LLM/MCP craze, I think this won't change and MCP tools will start getting locked down and nerfed somehow, the same way APIs have in not so recent memory after there being a…

I agree with your conclusion that this stuff will get locked down again over time. I think there's also another major reason people don't like to ship desktop software, and that's the cost of support of dealing with outdated tools, it can be immense. Ticket as raised, "Why is my broken?" After several rounds of clarification, it's established they're using a 6-year old version that's hitting API endpoints that were f…

A big problem with CLI tooling is it starts off seeming like it’s an easy problem to solve from a devs perspective. “I’ll just write a quick Go or Node app that consumes my web app’s API”

Fast forward 12-18 months, after several new features ship and several breaking API changes are made and teams that ship CLIs start to realize it’s actually a big undertaking to keep installed CLI software up-to-date with the API. It turns out there’s a lot of auto-updating infrastructure that has to be managed and even if the team gets that right, it can still be tricky managing which versions get deprecated vs not.

I built Terminalwire (https://terminalwire.com) to solve this problem. It replaces JSON APIs with a smaller API that streams stdio (kind of like ssh), and other commands that control browsers, security, and file access to the client.

It’s so weird to me how each company wants to ship their own CLI and auto-update infrastructure around it. It’s analogous to companies wanting to ship their own browser to consume their own website and deal with all the auto update infrastructure around that. It’s madness.

Re: Claude Advanced Tool Use

#233
post #77

I'm starting to notice a pattern with these AI assistants. Scenario: I realize that the recommended way to do something with the available tools is inefficient, so I implement it myself in a much more efficient way. Then, 2-3 months later, new tools come out to make all my work moot. I guess it's the price of living on the cutting edge.

The consequences of having the world's smartest people working on those things 24/7. Often, either the model itself gets improvements that render past scaffolding redundant, or your clever hacks to squeeze more performance out get obsoleted by official features that do the same thing better.

I think this is specifically the consequence of smart people working in a bubble: there's no clearly defined problem being solved, and there's no common solution everyone's aiming for, there's just a general feeling of a direction ("AI") along with a pressure to get there before anyone else.

It leads to the false feeling of progress, because everyone thinks they're busy working at the forefront, when in reality, only a tiny handful of people are are actually innovating.

Everyone else (including me and the person you responded to) is just wasting time relearning new solutions every week to "the problem with current AI" .

It's tiring reading daily/weekly "Advanced new solution to that problem we said was the advanced new solution last month", especially when that solution is almost always a synonym of "prompt engineering", "software engineering" or "prompt engineering with software engineering".

Re: Claude Advanced Tool Use

#234
The 'tool use' framing is interesting but feels like a rebranding of what's essentially sophisticated prompt engineering with structured outputs. The real limitation isn't whether Claude can 'use' tools—it's the latency and token overhead. Has anyone benchmarked whether these tool calls are actually faster/cheaper than fine-tuning smaller models with deterministic output schemas? Curious if the 'advanced' framing here is product differentiation or genuine architectural improvement.

Re: Claude Advanced Tool Use

#235
post #181

Earlier quoted context omitted.

The frustrating part is, with all the hype it is hard to see, what are really the working ways right now. I refused to go your way to live on the edge and just occasionally used ChatGPT for specific tasks, but I do like the idea to get AI assistants for the old codebases and gave the modern ways a shot just now again, but it still seems messy and I never know if I am simply not doing it right, or if there simply is n…

This is the cost of bleeding edge... in our internal company ai slack channel people ask what is the best method to do something every week. The answer is always something like: "As of today, do a,b,c. But this will be different next week/month". I like it, we are at the forefront of this technology and years from now we will be telling stories to kids on how it used to be.

I think the stories told about this time in particular will be the same as the stories told about any boom/bust cycle: a frenzied feeling of progress which resulted in a tiny handful of people getting outrageously wealthy, whilst the vast majority of people and society as a whole loses a whole lot of time, money and dignity.

Re: Claude Advanced Tool Use

#236
post #77

I'm starting to notice a pattern with these AI assistants. Scenario: I realize that the recommended way to do something with the available tools is inefficient, so I implement it myself in a much more efficient way. Then, 2-3 months later, new tools come out to make all my work moot. I guess it's the price of living on the cutting edge.

Hah I’m only on the cutting edge part time on the side so my experience has been more like - start thinking about the problem and then 2 or 3 days later new tools come out that solve it for me

Re: Claude Advanced Tool Use

#237
post #233

Earlier quoted context omitted.

The consequences of having the world's smartest people working on those things 24/7. Often, either the model itself gets improvements that render past scaffolding redundant, or your clever hacks to squeeze more performance out get obsoleted by official features that do the same thing better.

I think this is specifically the consequence of smart people working in a bubble: there's no clearly defined problem being solved, and there's no common solution everyone's aiming for, there's just a general feeling of a direction ("AI") along with a pressure to get there before anyone else. It leads to the false feeling of progress, because everyone thinks they're busy working at the forefront, when in reality, only…

> It's tiring reading daily/weekly "Advanced new solution to that problem we said was the advanced new solution last month"

At least for the current iterations that come to mind here, every advanced new solution solves the problem for a subset of problems, and the advanced new solution after that solves it for a subset of the remaining problems.

E.g. if you are tool calling with a fixed set of 10 tools you don't _need_ anything outlined in this blog post (though, you may use it as token count optimization).

It's just the same as in other programming disciplines. Nobody is forcing you to stay up to date with frontend framework trends if you have a minimally interactive frontend where a elements already solves your problem. Similarly, nobody forces you to stay up-to-date with AI trends on a daily basis. There are still plenty of product problems ready to be exploited, that do well enough with state of AI & dumb prompt engineering from a year ago.

Re: Claude Advanced Tool Use

#238

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

I use the GitLab CLI (glab) extensively, because it is so much better than the (official) GitLab MCP. I just run `glab auth login` before launching Claude Code, then tell CC to use `glab` to communicate with the GitLab API.

When using the MCP, I have to do a whole OAuth browser-launch process and even then I am only limited to the 9-10 tools that they've shipped it with so far.

Re: Claude Advanced Tool Use

#239

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

[flagged]

Stop spamming.

Re: Claude Advanced Tool Use

#240

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

I think this is about tools that are executed on the server instead of on the client. This is all very confusing - so I might be mistaken.
Post reply on HN