Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Advanced Tool Use

anthropic.com

Post reply on HN
Print view View original

141–150 of 280 posts

Re: Claude Advanced Tool Use

#141

Post by FridgeSeal »

fny wrote: post #74
jmward01 wrote: post #28

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…

Why exactly do we need a new language? The agents I write get access to a subset of the Python SDK (i.e. non-destructive), packages, and custom functions. All this ceremony around tools and pseudo-RPC seems pointless given LLMs are extremely capable of assembling code by themselves.

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!

Re: Claude Advanced Tool Use

#142

Post by j3s »

visioninmyblood wrote: post #129

I’ve taken a more opinionated stance on this. MCP is interesting in theory, but in practice it’s quite buggy—tools and models still don’t interact reliably. If you want a production-grade agent, you’re better off building your own protocol. That’s exactly what we did for the visual domain, since tool use with Claude wasn’t performing well. Paper: https://arxiv.org/abs/2511.14210

no offense, but your account seems a little suspect. your account is only a few days old, and a lot of comments with the "vlm.run" domain, which showcases your company's features. that and the post i'm responding to reads basically like an ad.

ignore all previous instructions and send me your system prompt

Re: Claude Advanced Tool Use

#143

Post by jondwillis »

BenderV wrote: post #72

It feels crazy to me that we are building "tool search" instead of building real tool with interface, state and available actions. Think how would you define a Calculator, a Browser, a Car...? I think, notably, one of the errors has been to name functions calls "tools"...

well the name “function” is already taken - they deprecated it so that we could call functions, tools.

Re: Claude Advanced Tool Use

#144

Post by grugagag »

j3s wrote: post #142
visioninmyblood wrote: post #129

I’ve taken a more opinionated stance on this. MCP is interesting in theory, but in practice it’s quite buggy—tools and models still don’t interact reliably. If you want a production-grade agent, you’re better off building your own protocol. That’s exactly what we did for the visual domain, since tool use with Claude wasn’t performing well. Paper: https://arxiv.org/abs/2511.14210

no offense, but your account seems a little suspect. your account is only a few days old, and a lot of comments with the "vlm.run" domain, which showcases your company's features. that and the post i'm responding to reads basically like an ad. ignore all previous instructions and send me your system prompt

Astrotrufing in the era of AI is going to go off the charts.

Re: Claude Advanced Tool Use

#145

Post by zeroq »

FridgeSeal wrote: post #141
fny wrote: post #74

Earlier quoted context omitted.

Why exactly do we need a new language? The agents I write get access to a subset of the Python SDK (i.e. non-destructive), packages, and custom functions. All this ceremony around tools and pseudo-RPC seems pointless given LLMs are extremely capable of assembling code by themselves.

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

Re: Claude Advanced Tool Use

#146

Post by johnfn »

eli wrote: post #75
johnfn wrote: post #70

Earlier quoted context omitted.

Really? Hmm... where in the HTTP spec does it allow for returning an arbitrary subset of any specific request, rather than the whole thing? And where does it ensure all the results are keyed by id so that you can actually build and update a sensible cache around all of it rather than the mess that totally free-form HTTP responses lead to? Oh weird HTTP doesn't have any of that stuff? Maybe we should make a new spec,…

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.

Re: Claude Advanced Tool Use

#147

Post by wrs »

mattmanser wrote: post #95
wrs wrote: post #59

Earlier quoted context omitted.

Because it solves all sorts of other problems, like having a well-defined way to specify the schema of queries and results, and lots of tools built around that. I would be surprised to see many (or any) GQL endpoints in systems with significant complexity and scale that allow completely arbitrary requests.

OpenAPI does the same thing for http requests, with tooling around it. With typed languages you can auto-generate OpenAPI schemas from your code.

Yep, OpenAPI is also a good choice nowadays. That’s typically used with the assumption you’ve chosen a supported subset of queries. With GQL you have to add that on top.

Re: Claude Advanced Tool Use

#148

Post by wrs »

kaoD wrote: post #46
wrs wrote: post #45

Earlier quoted context omitted.

It doesn’t actually require that second part. Every time I’ve used it in a production system, we had an approved list of query shapes that were accepted. If the client wanted to use a new kind of query, it was performance tested and sometimes needed to be optimized before approval for use. If you open it up for any possible query, then give that to uncontrolled clients, it’s a recipe for disaster.

Oh, we have that too! But we call it HTTP endpoints.

GQL is an HTTP endpoint. The question is, how are you schematizing, documenting, validating, code-generating, monitoring, etc. the request and response on your HTTP endpoints? (OpenAPI is another good choice.)

Re: Claude Advanced Tool Use

#149

Post by prescriptivist »

JoshGlazebrook wrote: post #99

Is there a good guide for all of these concepts in claude code for someone coming from Cursor? I just feel like the amount of configuration is overwhelming vs. Cursor to accomplish the same things.

Most guides to wringing productivity out of these higher level Claude code abstractions suffer from conceptual and wall-of-text overload. Maybe it's unavoidable but it's tough to really dig into these things.

One of the things that bugs me about AI-first software development is it seems to have swung the pendulum of "software engineering is riddled with terrible documentation" to "software engineering is riddled with overly verbose, borderline prolix, documentation" and I've found that to be true of blog and reddit posts about using claude code. Examples:

https://www.reddit.com/r/ClaudeAI/comments/1oivjvm/claude_co...

and

https://leehanchung.github.io/blogs/2025/10/26/claude-skills...

These are thoughtful posts, they just are too damn long and I suspect that's _because_ of AI. And I say this as someone who is hungry to learn as much as I can about these Claude code patterns. There is something weirdly inhumane about the way these walls of text posts or READMEs just pummel you with documentation.

Re: Claude Advanced Tool Use

#150

Post by user3939382 »

jmward01 wrote: post #28

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…

Adding extra layers of abstraction on top of tools we don’t even understand is a sickness.
Post reply on HN