Live data from Hacker News

Claude Advanced Tool Use

anthropic.com

161–170 of 280 posts

Re: Claude Advanced Tool Use

#161

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?

That's exactly what Claude Skills do [0], and while this tool search appears to be distinct, I do think that they're on the way to integrating MCP and Skills. [0] https://code.claude.com/docs/en/skills

I haven't had much luck with skills being called appropriately. When I have a skill called "X doer", and then I write a prompt like "Open and do X", it almost never loads up the skill. I have to rewrite the prompt as "Open and do X using the X doer skill".

Which is basically exactly as much effort as what I was doing previously of having prewritten sub-prompts/agents in files and loading up the file each time I want to use it.

I don't think this is an issue with how I'm writing skills, because it includes skill like the Skill Creator from Anthropic.

Re: Claude Advanced Tool Use

#162
post #145

Earlier quoted context omitted.

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.

Thanks, most of the times when I do that people tell me to stop being silly and stop saying nonsense.

¯\_(ツ)_/¯

Re: Claude Advanced Tool Use

#163
post #152
post #146

Earlier quoted context omitted.

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?

Let's say your REST endpoint returned an object with keys foo, bar, baz and quuz. How would you use HTTP Range to only select foo and baz?

Re: Claude Advanced Tool Use

#164

Earlier quoted context omitted.

> It works better! > I strongly believe it is one of the best technologies for AI agents Do you have any quantitative evidence to support this? Sincere question. I feel it would add some much needed credibility in a space where many folks are abusing the hype wave and low key shilling their products with vibes instead of rigor.

I have thought about this for all of thirty seconds, but it wouldn't shock me if this was the case. The intuition here is about types, and the ability to introspect them. Agents really love automated guardrails. It makes sense to me that this would work better than RESTish stuff, even with OpenAPI.

This is a task I think is suited for a sub agent that is small in size. It can can take the context beating to query for relevant tools and return only what is necessary to the main agent thread.

Re: Claude Advanced Tool Use

#165
I thought the idea was to isolate the concerns, so that you have a GitHub agent, and a Linear agent, and a Slack agent independently, and that these agents converse to solve the problem?

The monolith agent seems like a generalist which may fail to be good enough at anything. But what do I know

Re: Claude Advanced Tool Use

#166
post #56

It’s quite obvious that at some point the entire web will become a collection of billions of tools; Google will index them all, and Gemini will dynamically select them to perform actions in the world for you. Honestly, I expected this with Gemini 3

I thought for a while there will be this massive standardized schema connecting all World APIs into a single traversable object. Allowing you to easily connect anything.

og web3- semantic web

Re: Claude Advanced Tool Use

#167

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

I've had a similar experience with Gemini ignoring things I've explicitly told it (sometimes more than once). It's probably context rot. LLM give you a huge advertised number of tokens in the context, but the more stuff you put in there, the less reliably it remembers everything, which makes sense given how transformer attention blocks work internally.

Re: Claude Advanced Tool Use

#168
post #24

Our agentic builder has a single tool. It is called graphql. The agent writes a query and executes it. If the agent does not know how to do particular type of query then it can use graphql introspection. The agent only receives the minimal amount of data as per the graphql query saving valuable tokens. It works better! Not only we don't need to load 50+ tools (our entire SDK) but it also solves the N+1 problem when u…

Whoa there, you don't need to be so sadistic to your team. It's not GraphQL, but having a document describing how your API works, including types, that is important.

I expect you could achieve the same with a comprehensive OpenAPI specification. If you want something a bit stricter I guess SOAP would work too, LLMs love XML after all.

Re: Claude Advanced Tool Use

#170

I thought the idea was to isolate the concerns, so that you have a GitHub agent, and a Linear agent, and a Slack agent independently, and that these agents converse to solve the problem? The monolith agent seems like a generalist which may fail to be good enough at anything. But what do I know

Say you do have those sub-agents, they will likely each have tools, and sometimes many, in which case you'll have you route to those tools somehow. The sub-agents themselves are also almost like tools from the main root agent's perspective, and there may be many of those, which you also have to route to, in which case you can use this pattern again. Put simply, sometimes increasing the hierarchy is not the right abstraction vs having many tools in one hierarchy, and thus the need for more efficient routing.
Post reply on HN