Wrapping tool calls in code together with using the benefits of the MCP output schema was implemented in smolagents for some time.
Think that’s even one step further conceptually.
https://huggingface.co/blog/llchahn/ai-agents-output-schema
Claude Advanced Tool Use
31–40 of 280 posts
Re: Claude Advanced Tool Use
#32Our 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…
I do think that using graphql will solve a lot of problems for people but it's super surprising how many people absolutely hate it.
GraphQL is just a typed schema (good) with a server capable of serving any subset of the entire schema at a time (pain in the ass).
Re: Claude Advanced Tool Use
#33I cannot believe all these months and years people have been loading all of the tool JSON schemas upfront. This is such a waste of context window and something that was already solved three years ago.
Solved how?
Re: Claude Advanced Tool Use
#34These meta features are nice, but I feel they create new issues. Like debugging.
Since this tool search feature is completely opaque, the wrong tool might not get selected. Then you'll have to figure out if it was the search, and if it was how you can push the right tool to the top.
Re: Claude Advanced Tool Use
#35The 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
Re: Claude Advanced Tool Use
#36Earlier quoted context omitted.
I do think that using graphql will solve a lot of problems for people but it's super surprising how many people absolutely hate it.
GraphQL is just a typed schema (good) with a server capable of serving any subset of the entire schema at a time (pain in the ass).
No.
It's a way to transmit a program from client to server. It then executes that program on the server side.
Re: Claude Advanced Tool Use
#37Earlier quoted context omitted.
Security nightmare inbound... The example given by Anthropic of tools filling valuable context space is a result of bad design. If you pass the tools below to your agent, you don't need "search tool" tool, you need good old fashion architecture: limit your tools based on the state of your agent, custom tool wrappers to limit MCP tools, routing to sub-agents, etc. Ref: GitHub: 35 tools (~26K tokens) Slack: 11 tools (~…
Don't see whats wrong in letting llm decide which tool to call based on a search on long list of tools (or a binary tree of lists in case the list becomes too long, which is essentially what you eluded to with sub-agents)
I was referring to letting LLM's search github and run tools from there. That's like randomly searching the internet for code snippets and blindly running them on your production machine.
Re: Claude Advanced Tool Use
#38The "Tool Search Tool" is like a clever addition that could easily be added yourself to other models / providers. I did something similar with a couple of agents I wrote. First LLM Call: only pass the "search tool" tool. The output of that tool is a list of suitable tools the LLM searched for. Second LLM Call: pass the additional tools that were returned by the "search tool" tool.
Since its a tool itself, I dont see the benefit of relying on Anthropic for this. if anything it now becomes vendor lock in.
Re: Claude Advanced Tool Use
#39Okay so this is just the `apropos` and `whatis` command¥ to search through available man pages. Then `man` command to discover how the tools work. Followed by tool execution? Really. We should be treating Claude code more like a shell session. No need for MCPs
Some have been saying this since MCP appeared.
Re: Claude Advanced Tool Use
#40Earlier quoted context omitted.
Hmm the Gemini API doesn’t need MCP for tool-use if I understand correctly. It just needs registered functions
I don't think any of the mainstream vendor APIs require MCP for tool use - they all supported functions (generally defined using a chunk of OpenAPI JSON schema) before the MCP spec gained widespread acceptance and continue to do so today.
Yep, the Anthropic API supported tool use well before an MCP-related construct was added to the API (MCP connector in May of this year).
While it's not an API, Anthropic's Agent SDK does require MCP to use custom tools.