I once built a client-side tool just so Claude could run small data calculations, do the arithmetic, transform a list, compute a summary, and I dutifully stood up and maintained a little sandbox to execute it in. Then I found out code execution is a server-side tool I could simply declare, sandbox included, hosted by Anthropic. I had hand-built infrastructure that already existed as a one-line declaration.
That is the core idea of server-side tools: for common needs, you declare the capability and Claude runs it on Anthropic's side, batteries included. This guide covers what exists, code execution, web tools, computer use, how they differ from the client-side tools you run yourself, and how to choose which kind a job wants.
Server-side vs client-side tools
Anthropic hosts server tools such as code execution and web search or fetch. Client tools execute in an environment you provide. Computer use is a client tool capability, not an Anthropic-hosted desktop that appears when you declare it. Choose the execution location, credentials and data path for each tool separately.
The practical consequence is who builds and hosts the machinery. A client-side tool means you own the execution, the credentials, the data path. A server-side tool means Anthropic owns the execution environment, so you get the capability without standing up infrastructure. Neither is better; they are for different jobs, which is the rest of this guide.
- Runs in your environment; you (or Claude Code) execute it Client-side
- Runs on Anthropic's side; Claude calls it directly Server-side
What server-side tools exist
Hosted code execution provides a sandbox for calculations and file work. Web search and web fetch provide current sources. Computer use belongs on the client side: your integration supplies the computer environment and executes the requested actions. I would draw that boundary before deciding which credentials the workflow can reach.
Because the list evolves, treat the docs as the source of truth for exactly what is available and how each behaves. The point to carry is the category: these are powerful, hosted capabilities you switch on by declaring, rather than functions you implement and run.
- Code execution: run calculations, data transforms, and scripts in a hosted sandbox.
- Web search: pull current information from the live web.
- Web fetch: read a specific page or document by URL.
- Computer use: a client capability requiring an execution environment, covered separately below.
You declare them, Claude runs them
Using a server-side tool is a matter of declaring it in your request. You are not writing the function or handling the execution; you are telling Claude this capability is available, and it runs the tool on its side and works the result into its response. Compared to the client-side loop, where you run the tool and return the result, this is a much smaller amount of your code.
That is the appeal and the tradeoff in one. You get the capability with almost no plumbing, and in exchange the execution happens on Anthropic's side rather than in your environment. For a hosted sandbox to run arithmetic, that is exactly what you want. For a query against your private CRM, you want the client-side tool instead.
Code execution: math and data without a sandbox
Code execution is the one I wish I had known about before building my own. Claude can write and run code in a hosted sandbox to do the things language models are otherwise shaky at, precise arithmetic, data transformation, parsing a messy file, computing a real statistic. Instead of hoping the model does the math in its head, it runs actual code and uses the result.
For GTM this quietly fixes a lot. Scoring math that has to be exact, a transformation across a list, a calculation on pipeline numbers, these become reliable because they run as code, not as the model's estimate. And you get it without hosting the sandbox I built by hand, which was the whole lesson.
A concrete GTM example: a scoring job that has to weight several signals into a final number is far more reliable when Claude runs the arithmetic as code than when it estimates it in prose. Ask for the calculation and code execution does it exactly, so a score is computed, not guessed, which is exactly what you want when the number drives who a rep calls first.
Web tools: current info and reading pages
Web search and web fetch give Claude reach beyond its training data. Search finds current information and returns sources; fetch reads a specific page you or Claude points it at. Together they turn a static model into one that can answer about what is happening now and ground a claim in a page it actually read.
For GTM research this is bread and butter. Finding a prospect's recent funding or exec hires, reading a competitor's live pricing page, checking a company's latest news, all of it is the web tools doing the reaching, so your research agent works from the current web rather than a snapshot from training.
Computer use: when the only interface is a UI
Computer use is a client tool capability. Your application supplies the environment and handles actions; it does not become a hosted server tool merely because Anthropic defines the tool interface. Keep this separate from the hosted code sandbox when designing your GTM workflow.
Computer use lets Claude operate a graphical interface, clicking and typing, as a person would. It is the tool of last resort, for when a system has no API and the only way in is the screen. It is powerful and correspondingly slower and more fragile than calling an API, so it fits the gaps rather than the main path.
In a GTM stack, most of what you need has an API or an MCP server, so computer use is for the stubborn tool that has neither, the internal system with no integration, the vendor portal with no API. Reach for it when there is genuinely no other door, and prefer a real API or client-side tool everywhere else.
TipTreat computer use as the last resort, not the default. If a tool has an API or an MCP server, use that; computer use is for the systems that leave you no other way in.
Safety still applies
Scope each tool by what it can read or change. A hosted code sandbox and a client-controlled desktop have different boundaries. For an account brief, authorize the sources needed for the brief; for CRM changes, add a separate review step and verify the resulting record.
The reassurance is that execution being hosted in a sandbox limits some of the blast radius, which is part of why hosting helps. But you still decide which capabilities to hand your agent, and a capable tool in a confused loop is still a capable tool. Grant them deliberately, and watch what they do on early runs.
What server-side tools cost
Tool billing depends on the specific tool and version. Current code execution has no additional execution charge when a qualifying web search or fetch tool is included, beyond token costs; other tool charges can still apply. A client computer environment has its own hosting cost. Cost the actual request rather than assuming every tool has a separate fixed fee.
The way to think about it is that convenience has a price, and it is usually worth paying. Declaring a tool beats building and hosting the equivalent, so the cost buys you the infrastructure you did not build. But on a high-volume job, know what each tool call adds, the same way you would cost any other part of the pipeline, so a research agent that searches the web on every account is a number you chose, not a surprise.
The GTM version
The clean division for a GTM agent: server-side tools for the general capabilities, code execution for exact math, web tools for current research, and client-side tools for your own systems, the CRM, the enrichment provider, the internal data. Claude reaches the web and does the arithmetic on Anthropic's side, and touches your private data through tools you run, so sensitive data stays in your environment.
That split gives you the best of both: hosted convenience where the work is generic, and full control where the data is yours. The sandbox I built by hand became one declared tool, and my agents got web reach and reliable math for free. What have you built or avoided building that is really just a server-side tool you could declare?
How to set it up
Decide which kind of tool the job needs
If the capability is generic, running code, searching the web, reading a page, reach for a server-side tool. If it touches your private systems or data, keep it a client-side tool you run.
Declare the server-side tool
Add the hosted tool to your request. Claude runs it on its side and uses the result, no execution code from you:
Mix in your client-side tools
Combine hosted tools with your own: server-side for web and math, client-side for the CRM and enrichment. Sensitive data stays in your environment while generic work runs on Anthropic's side.
TipKeep anything touching private data as a client-side tool you execute. That is how you get hosted convenience without sending sensitive records through a hosted execution path.
Scope the capable ones deliberately
Grant powerful tools like computer use only when a job needs them, prefer an API or MCP server where one exists, and watch what the tools do on early runs. Hosted execution limits some risk, but a capable tool is still a tool to scope.
Frequently asked questions
What are server-side tools?
Server tools such as code execution and web search or fetch run on Anthropic infrastructure. Computer use is a client capability and requires an execution environment supplied by your integration.
How do they differ from client-side tools?
Client tools execute in an environment you control. Their results may still be sent to Claude for model processing. Server tools use Anthropic-hosted execution. Assess the execution location and data flow separately.
What is code execution good for?
Running actual code for things models are otherwise shaky at: precise arithmetic, data transforms, parsing messy files, real statistics. It runs in a hosted sandbox, so you skip building one.
What do the web tools do?
Web search finds current information and returns sources; web fetch reads a specific page. Together they let Claude answer about current events and ground claims in pages it actually read, which is core to research.
When should I use computer use?
As a last resort, for systems with no API where the only interface is the screen. It is slower and more fragile than an API call, so prefer an API or MCP server wherever one exists.
Do I still need client-side tools?
Use client tools for integrations and environments you need to control. Return only the information Claude needs from CRM or enrichment calls; client execution does not keep all model processing inside your environment.
Are server-side tools safe by default?
Hosting in a sandbox limits some blast radius, but a tool that runs code, fetches pages, or operates a UI is still capable. Grant them deliberately, apply the read-versus-write instinct, and watch early runs.
How do I combine both kinds in one agent?
Declare server-side tools for web and math, and define client-side tools for your CRM and enrichment. Claude does generic work on Anthropic's side and touches your data through the tools you run.
Sources & further reading
- Tool use overview (Anthropic docs)
- Code execution tool (Anthropic docs)
- Current Claude models and API IDs
- Current code execution versions and pricing
- Computer use client implementation
Claude ships fast. This page was last reviewed Sep 22, 2026; verify time-sensitive details against the official docs above before relying on them.