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

81–90 of 280 posts

Re: Claude Advanced Tool Use

#81

Post by troupo »

awesome_dude wrote: post #50
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.

Without wishing to take part in a pile on - I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries.

> I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries.

Because you never want to expose unbounded unlimited dynamic queries in production. You do want a very small subset that you can monitor, debug, and optimize.

Re: Claude Advanced Tool Use

#82

Post by vessenes »

cube2222 wrote: post #10
vessenes wrote: post #8

I'm confused about these tools - is this a decorator that you can add to your MCP server tools so that they don't pollute the context? How else would I add a "tool" for claude to use?

When you make API calls to generate chat completions, you specify a list of tools. They can be MCP tools, or just arbitrary tool metadata. The API will then respond when it needs the client code to compute a tool output.

got it, thanks!

Re: Claude Advanced Tool Use

#83

Post by adverbly »

_pdp_ wrote: 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…

This is actually a really good use of graphql!

IMO the biggest pain points of graphql are authorization/rate limiting, caching, and mutations... But for selective context loading none of those matter actually. Pretty cool!

Re: Claude Advanced Tool Use

#84

Post by roncesvalles »

tfirst wrote: post #2

We seem to be on a cycle of complexity -> simplicity -> complexity with AI agent design. First we had agents like Manus or Devin that had massive scaffolding around them, then we had simple LLMs in loops, then MCP added capabilities at the cost of context consumption, then in the last month everything has been bash + filesystem, and now we're back to creating more complex tools. I wonder if there will be another roun…

It's because attention dilution stymies everything. A new chat window in the web app is the smartest the model is ever going to be. Everything you prompt into its context, without sophisticated memory management* makes it dumber. Those big context frameworks are like giving the model a concussion before it does the first task.

*which also pollutes the attention btw; saying "forget about this" doesn't make the model forget about it - it just remembers to forget about it.

Re: Claude Advanced Tool Use

#85

Post by brulard »

refibrillator wrote: post #71
_pdp_ wrote: 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…

> 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.

If you knew GraphQL, you may immediately see it - you ask for specific nested structure of the data, which can span many joins across different related collections. This is not the case with common REST API or CLI for example. And introspection is another good reason.

Re: Claude Advanced Tool Use

#86

Post by tlarkworthy »

johnfn wrote: post #70
kaoD wrote: post #46

Earlier quoted context omitted.

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

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

Etag and cache control headers?

Re: Claude Advanced Tool Use

#87

Post by mrinterweb »

The whole time while reading over this, I was thinking how a small orchestrator local model might help with somewhat known workflows. Programmatic orchestration is ideal, but can be impractical for all cases. In the interest of reducing context pollution, improving speed, and providing a better experience; I would think the ideal hierarchy for orchestration would be programmatic > tiny local LLM > frontier LLM. The tiny model doesn't need to be local as computers have varying resources.

I would think there would be some things a tiny model would be capable of competently managing and faster. The tiny model's context could be regularly cleared, and only relevant outputs could be sent to the larger model's context.

Re: Claude Advanced Tool Use

#88

Post by jmward01 »

menix wrote: post #35
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…

The latest MCP specifications (2025-06-18+) introduced crucial enhancements like support for Structured Content and the Output Schema. Smolagents makes use of this and handles tool output as objects (e.g. dict). Is this what you are thinking about? Details in a blog post here: https://huggingface.co/blog/llchahn/ai-agents-output-schema

We just need simple language syntax like python and for models to be trained on it (which they already mostly are):

class MyClass(SomeOtherClass):

  def my_func(a:str, b:int) -> int: 

    #Put the description (if needed) in the body for the llm.
That is way more compact than the json schema out there. Then you can have 'available objects' listed like: o1 (MyClass), o2 (SomeOtherClass) as the starting context. Combine this with programatic tool calling and there you go. Much much more compact. Binds well to actual code and very flexible. This is the obvious direction things are going. I just wish Anthropic and OpenAI would realize it and define it/train models to it sooner rather than later.

edit: I should also add that inline response should be part of this too: The model should be able to do `````` and keep executing with only blocking calls requiring it to stop generating until the block frees up. so, for instance, the model could ```r = start_task(some task)``` generate other things ```print(r.value())``` (probably with various awaits and the like here but you all get the point).

Re: Claude Advanced Tool Use

#89

Post by mcpeepants »

awesome_dude wrote: post #65
wrs wrote: post #61

Earlier quoted context omitted.

It is flexible, but you don’t have to let it be infinitely flexible. There’s no practical use case for that. (Well, until LLMs, perhaps!)

I guess that I'm reading your initial post a little more strictly than you're meaning

I think they mean something like (or what I think of as) “RPC calls, but with the flexibility to select a granular subset of the result based on one or more schemas”. This is how I’ve used graphql in the past at least.

Re: Claude Advanced Tool Use

#90

Post by esafak »

_pdp_ wrote: 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…

Can anyone recommend an open source GraphQL-based MCP/tool gateway?
Post reply on HN