Search
4 results for “function-calling”
Search results
Tool Use & Agents
How a tool call actually completes as a round trip, a tool_use block your code executes and a tool_result you send back, and why every tool definition you provide adds real tokens to every request whether or not it's ever called.
Walk through what actually happens end to end when a model decides to call a tool you defined.
You send a request with a `tools` array describing each tool's name, description, and input schema; the model decides a tool fits the request and responds not with plain text but with a specific stop reason indicating tool use, plus one or more blocks naming the tool and its arguments (matching your schema). Your application code, not the model, actually executes that call, a real function, API request, or command, then sends a follow-up request containing the result in a block referencing the original tool-call's ID. Only after that round trip does the model produce its final answer, incorporating the tool's actual result rather than a guess.
What is the difference between a client tool and a server tool, and why does that distinction matter for what your application has to do?
A client tool executes in your own application, the model only returns the structured request to call it; your code is responsible for actually running it (hitting your database, calling your API) and returning the result. A server tool, like a web search or code execution tool a provider offers, executes on the provider's own infrastructure, so your application sees the final result directly without ever writing execution code for it. The distinction determines how much you have to build: every client tool needs your own execution and error-handling code, while server tools need none, just declaring them in the request.
Why does simply including a tool definition in a request add cost even on a turn where the model never actually calls it?
Every tool's name, description, and input schema in the `tools` parameter counts as real input tokens on every single request, and using tools at all triggers an additional fixed system-prompt token overhead that varies by model, regardless of whether the model ends up calling any tool that turn. This means a large library of rarely-used tool definitions has a real, continuous token cost across every request that includes them, which is exactly why techniques like on-demand tool discovery (only loading the tool definitions actually relevant to the current task) exist as a mitigation for applications with many available tools.