Server-side tools: code execution, computer use, web

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

Every tool Claude can use is one of two kinds, and the difference is where it runs. Client-side tools are the ones from the tool-use guide: you define them, and your code executes them, so a CRM query or a file edit runs in your environment and your data stays with you. Server-side tools are hosted by Anthropic: you declare them in the request, and Claude runs them on its side.

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.

What server-side tools exist

The set grows, but the workhorses are code execution, web search, web fetch, and computer use. Code execution runs code in a hosted sandbox. Web search finds current information, and web fetch reads a specific page. Computer use lets Claude operate a graphical interface. Each is a capability that would be real work to build yourself and is a declaration to use.

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: operate a graphical interface when there is no API to call.

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 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.

Safety still applies

Hosted does not mean consequence-free. A server-side tool that runs code, fetches arbitrary pages, or operates a UI is still capable of doing things you should think about, so the read-versus-write instinct carries over. Reading a page or running a calculation is low risk; anything that could act in the wider world deserves the same scoping and caution as a client-side write tool.

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

Hosted does not mean free. Server-side tools carry their own usage cost on top of the model call, because Anthropic is running real infrastructure, a sandbox, a search, a browser, on your behalf. Code execution, web search, and computer use each add to the bill when Claude uses them, so they are a capability to reach for deliberately, not to leave on by reflex.

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

Frequently asked questions

Sources & further reading

• Tool use overview (Anthropic docs)
• Code execution tool (Anthropic docs)

Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.