Live data from Hacker News

Claude Advanced Tool Use

anthropic.com

151–160 of 280 posts

Re: Claude Advanced Tool Use

#151

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…

Reminds me a bit of the problem that GraphQL solves for the frontend, which avoids a lot of round-trips between client and server and enables more processing to be done on the server before returning the result.

Re: Claude Advanced Tool Use

#152
post #146
post #75

Earlier quoted context omitted.

An HTTP Range request asks the server to send parts of a resource back to a client. Range requests are useful for various clients, including media players that support random access, data tools that require only part of a large file, and download managers that let users pause and resume a download. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...

HTTP Range doesn't have anything to do with allowing a client to select a subset of fields.

The Range header isn't for requesting a subset of a resource from the server?

Re: Claude Advanced Tool Use

#153
post #145

Earlier quoted context omitted.

Woah woah woah, you’re ignoring a whole revenue stream caused by deliberately complicating the ecosystem, and then selling tools and consulting to “make it simpler”! Think of all the new yachts our mega-rich tech-bros could have by doing this!

my VS fork brings all the boys to the yard and they're like it's better than yours, damn right, it's better than yours

This is the most creative comment I've read on HN as of late.

Re: Claude Advanced Tool Use

#154

I never really understood why you have to stuff all the tools in the context. Is there something wrong with having all your tools in, say, a markdown file, and having a subagent read it with a description of the problem at hand and returning just the tool needed at that moment? Is that what this tool search is?

Claude is pretty good at totally disregarding most of what’s in your CLAUDE.md, so I’m not optimistic. For example a project I work on gives it specific scripts to run when it runs automated tests, because the project is set up in a way that requires some special things to happen before tests will work correctly. I’ve never once seen it actually call those scripts on the first try. It always tries to run them using the typical command that doesn’t work with our setup, and I have to remind it the what correct thing to run is.

Re: Claude Advanced Tool Use

#155
I like how the conceptual curve of this new frontier is starting to look more and more like a circle. Yes we have these amazing new tools. But hey, we also have decades of practices, honed by selflessly lazy intelligent people into relative efficiency.

It's starting to feel like this will come around to in the end become "self-writing code" -- any problem you pose in the fuzzy human language is gradually converted into hard crystal edges of machine code, but padded with soft escape hatches of natural language to deal with contingencies, surprise edge cases, etc.

Self-writing, self-healing, self-adapting code? Now that we can, perhaps we need to consider whether we should.

Re: Claude Advanced Tool Use

#156

I like how the conceptual curve of this new frontier is starting to look more and more like a circle. Yes we have these amazing new tools. But hey, we also have decades of practices, honed by selflessly lazy intelligent people into relative efficiency. It's starting to feel like this will come around to in the end become "self-writing code" -- any problem you pose in the fuzzy human language is gradually converted in…

Unfortunately the question of whether we should is not a very popular one right now.

Re: Claude Advanced Tool Use

#157

Feels like the next step will be improving llm lsp integration, so tool use discovery becomes lsp auto complete calls. This is a problem coding agents already need to solve to work effectively with your code base and dependencies. So we don't have to keep solving problems introduced by odd tools like mcp.

It's kind of annoying, right now at least, when an agent can see all the LSP noise and it decides to go off on a tangent to address the LSP noise in the middle of running a task that the LSP is responding to.

For this to work, the LLM has to be trained on the LSP and the LSP has to know when to wait reporing changes and when to resume.

Re: Claude Advanced Tool Use

#158

Feels like the next step will be improving llm lsp integration, so tool use discovery becomes lsp auto complete calls. This is a problem coding agents already need to solve to work effectively with your code base and dependencies. So we don't have to keep solving problems introduced by odd tools like mcp.

I want LLM AST integration so it's better at dealing with code than I am.

Re: Claude Advanced Tool Use

#159
post #5

Nice! Feature #2 here is basically an implementation of the “write code to call tools instead of calling them directly” that was a big topic of conversation recently. It uses their Python sandbox, is available via API, and exposes the tool calls themselves as normal tool calls to the API client - should be really simple to use! Batch tool calling has been a game-changer for the AI assistant we've built into our produ…

The "write code to call tools instead of calling them directly" has been such an obvious path, the team at Huggingface & smolagents figured that out a while ago, agents that write code instead of natural language are just better for most cases.

Re: Claude Advanced Tool Use

#160

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…

Reminds me a bit of the problem that GraphQL solves for the frontend, which avoids a lot of round-trips between client and server and enables more processing to be done on the server before returning the result.

And introduce a new set of problems in doing so.
Post reply on HN