Client tools and server tools are the two kinds of tool Anthropic’s Claude API
distinguishes, separated by where the tool’s code actually executes. Anthropic’s
documentation states that tools differ primarily along this axis, and that which side a
tool falls on determines what the calling application is responsible for. Client tools run
in the calling application: the model responds with stop_reason: "tool_use" and one or
more tool_use blocks, the application’s own code executes the operation, and it sends the
outcome back in a tool_result block. Server tools run on Anthropic’s infrastructure, so
the caller sees the results directly without writing any handler — the documentation gives
web search as a minimal example, where the search runs on Anthropic’s side and the cited
results come back in the same response. Google’s Gemini API draws the same
line under different names, as described below.
Usage
Anthropic’s documentation groups the tools it offers into three categories along this
line — two of them client-side, one server-side. Your own tools (user-defined tools) are ones the developer defines by writing a schema, with the
application executing each call; Anthropic’s conceptual guide to tool use says the vast
majority of tool-use traffic is of this kind, and that Claude never sees the implementation,
only the schema and the returned result. Anthropic-schema client tools are ones for which
Anthropic publishes the schema and trains the model on it, while the application still
executes each call and returns the tool_result — among them the memory, bash, text
editor, computer use and browser use tools. The same guide gives the reason to prefer one of these
over a self-defined equivalent: the schemas are trained-in, Claude having been optimized on
thousands of successful trajectories using those exact signatures, so it calls them more reliably
and recovers from errors more gracefully than it would with a custom tool doing the same thing.
Server tools need no handler code at all; the overview lists among them web search, web fetch, code execution, the advisor tool, the tool search tool
and the MCP connector, and the conceptual guide names web search, web fetch, code execution and
tool search as server-executed.
The two sides also differ in who drives the loop. With client tools the application has to run
it: every call is a round trip in which the model asks, the application executes and reports
back, and the model continues, which the guide describes as a while loop that keeps going as
long as stop_reason is "tool_use" and exits on any other stop reason. Server tools run their
own loop inside Anthropic’s infrastructure — one request may trigger several searches or code
executions before a response comes back, with server_tool_use blocks showing what ran — and the
application never constructs a tool_result for them. That internal loop has an iteration limit:
if the model is still iterating when it reaches it, the response comes back with
stop_reason: "pause_turn", and the application re-sends the conversation, including the paused
response, so the model can continue.
The separation is not absolute in one documented case: the documentation notes that a
server tool’s results are returned directly unless the model calls it in the same group
of parallel tool calls as one of the caller’s client tools. The conceptual guide describes what
happens then: the response comes back with stop_reason: "tool_use" and a server_tool_use block
that has no result yet, and the API runs the server tool after the application returns the
client tool results.
Where a tool runs also determines how it is billed. Anthropic states that client-side tools are priced the same as any other API request, while server-side tools can incur additional usage-based charges on top of tokens — its example is web search charging per search performed.
Google’s Gemini API documentation divides its tools into built-in tools managed by Google and
custom tools managed by the developer, and describes a different execution flow for each. For
built-in tools — Google Search, Google Maps, URL Context, File Search and Code Execution — the entire
process happens within one API call: the model decides it needs a tool, executes it on Google’s
servers and returns a final answer grounded in the results. For custom tools, defined through
function calling, the application handles execution: the model returns structured JSON calling a
function, always with a unique id; the application executes it and sends the result back with the
same id; and the model produces a final response or another call. Computer use falls on the
client side in both accounts: Anthropic lists it among its Anthropic-schema client tools, and
Google’s documentation places its Computer Use tool, though listed among the built-in tools, in the
application-executed flow alongside custom tools.
The two accounts also each describe a case where the two kinds meet in one exchange. Anthropic’s is the parallel-call exception above. Google’s is a preview feature for its Gemini 3 series models that combines built-in and custom tools in a single turn, which its documentation calls tool context circulation: the model runs the built-in tools and yields to the application when a client-side function call is generated, and the application returns all parts of the model’s response — including encrypted thought signatures that preserve context — together with its own function results, so the final answer is generated from the combined context.
Related Terms
- Function calling — the general pattern this distinction refines
- Function calling — the request-and-result exchange that client tools are built on
- Computer Use — a tool both accounts place on the client side
- Model Context Protocol — another route by which an agent reaches external tools
- Code Execution MCP — a related approach to running code on an agent’s behalf
- Gemini API — the Google API whose built-in and custom tools draw the same line