Server Tools: Web Search, Code Execution, Computer Use

Beyond custom tools you define, the platform offers a family of tools Anthropic has designed: some execute on Anthropic's infrastructure and return results inside the same response, others define a schema the model knows well but leave execution to you. Mixing up which is which is a common design error. This lesson sorts them and sets out the governance each needs.

Who executes what

Tool	Executes	What it gives you	Main control points
Web search	Anthropic server	Live search results with citations	max_uses, allowed or blocked domains, user location
Web fetch	Anthropic server	Content of URLs already present in the conversation	Domain lists, content token caps, citations
Code execution	Anthropic sandbox	Python and shell in a container; files in and out via the Files API; Agent Skills	Container lifetime, which files are mounted
Tool search	Anthropic server	Discovers deferred tools from a large catalogue	At least one tool must remain non-deferred
Memory	Your backend	Anthropic-defined file-style schema; you store the data	Scope per user; review writes
Text editor and bash	Your environment	Anthropic-defined schemas the model uses fluently	Sandboxing, path and command policy
Computer use	Your environment	Screenshot and action schema; you run the VM	Isolated VM, no credentials, human checkpoints

Server tools are declared in tools like any other; results come back as typed result blocks. Server-tool failures do not raise HTTP errors: the result block contains an error object, so your code must inspect the block. Long server-tool turns can end with stop_reason of pause_turn; continue by sending the response back as the next request.

Tool type strings are versioned and vary by model and platform; the docs list current variants. Design so the version string is configuration.

Web search and fetch

Web search gives agents current information with citations; web fetch retrieves full pages for URLs the conversation already contains. Governance concerns: cost per use on top of tokens, unbounded browsing, and prompt injection from web content. Controls:

• Set max_uses to bound both cost and runaway research.
• Use domain allowlists for regulated contexts (approved sources only) or blocklists to exclude known-bad or irrelevant domains; the two are mutually exclusive on a tool.
• Treat fetched content as untrusted input. An instruction on a web page is data, never a command.
• Cite. Citations let humans verify and let your evaluators check grounding.

Availability of web tools and which versions exist differs across cloud platforms.

Code execution and Agent Skills

Code execution runs model-written code in an Anthropic-managed sandbox, returning stdout, stderr, exit codes and any files produced. It makes analysis, charting and document generation reliable because arithmetic and formatting are done by code rather than by token prediction. Agent Skills build on it: packaged instructions and scripts for tasks such as producing spreadsheets, presentations or documents, loaded on demand.

Design points: the data to be processed must be sent to the sandbox, so classification rules apply; sandboxes have no arbitrary network access; outputs return via the Files API and should be scanned like any uploaded file; and the sandbox is priced by usage. For sensitive data that cannot leave your estate, run a local code tool instead and accept operating the sandbox yourself.

Programmatic tool calling, where the model calls your custom tools from inside code execution, reduces round trips for loops over many items but has compatibility limits with other features; check the docs.

Computer use

Computer use lets the model operate a desktop through screenshots and mouse and keyboard actions. You run the environment, usually a disposable VM, and execute the actions it requests. It is powerful for legacy applications with no API and dangerous in equal measure: the model can be misled by content on screen, and a mis-click on a real system is a real action.

Non-negotiable controls: an isolated VM with no production credentials, allowlisted network access, a human confirmation step before irreversible actions, logging of every screenshot and action, and a kill switch. Prefer an API or MCP integration whenever one exists; computer use is the integration of last resort.

Memory, editor and bash

These are Anthropic-defined schemas that you implement. The benefit is that the model has been trained on the exact tool shape, so it uses them well. The responsibility is that every file read, write and command executes in your environment, under your sandboxing and path policies. The memory tool in particular needs per-user scoping and a review process for what gets written, since memory contents are read back as context in later sessions.

Cost model

Server tools incur a per-use fee plus the tokens of their inputs and results, and results stay in context for subsequent turns. Cap uses, clear stale results with context editing where supported, and attribute tool costs per route in your telemetry.

Exam focus

• Distinguish server-executed tools (web search, web fetch, code execution, tool search) from Anthropic-defined but client-executed tools (memory, text editor, bash, computer use).
• Server-tool errors arrive inside result blocks, not as HTTP errors; pause_turn means continue the turn.
• Bound web tools with max_uses and domain lists; treat fetched content as untrusted input.
• Code execution sends data to an Anthropic sandbox and returns files via the Files API; use a local tool when data must not leave your estate.
• Computer use requires an isolated VM, no credentials, human checkpoints and full logging; it is the last resort when no API exists.
• Tool type strings are versioned per model and platform; keep them in configuration and verify in the docs.