Web search is a server tool: it runs on Anthropic's infrastructure, not yours. You add it to a request's tools array, and when Claude decides current information would help, it issues searches, reads the results, and folds them into its answer — all within one API round trip from your perspective. You never receive a "please run this search" callback the way you do with client tools; the results simply appear in the response, with the search activity visible in the returned content blocks.
Versions: 2025 basic vs 2026 dynamic filtering
Two generations of the tool exist. The earlier web_search_20250305 is the basic variant. The current web_search_20260209 adds dynamic filtering: Claude filters and processes search results in code before they ever reach the model's context window, which keeps low-value result text from inflating your input tokens. No separate beta header is needed for either. One dependency to know: the _20260209 web tools require code_execution_20260120 or later as their companion code execution version, since the filtering runs in that sandbox — and helpfully, code execution is free when used alongside the current web tools.
Controlling how much searching happens
Server tools run in a server-side loop with a default limit of 10 iterations. If a research-heavy question hits that ceiling, the API returns stop_reason: "pause_turn"; you re-send the conversation (user message plus the assistant response) and the server resumes where it left off — no extra "continue" message needed. Beyond that, dynamic filtering is your main lever over how much result content reaches context, and ordinary prompting ("search at most twice, then answer") steers search frequency well. The tool accepts additional configuration options; check the official documentation for the current parameter list rather than relying on secondhand summaries, as the options have changed between versions.
Availability: the biggest 3P difference in this series
Web search is where the four platforms diverge most sharply, so it deserves a table:
| Platform | Web search support |
|---|---|
| Claude API (1P) | Generally available, both versions |
| Claude Platform on AWS | Generally available — same-day parity with 1P |
| Amazon Bedrock | Not available |
| Google Vertex AI | Basic web_search_20250305 only — no dynamic filtering |
| Microsoft Foundry | Beta |
If your workload genuinely needs live search and your organization is AWS-committed, Claude Platform on AWS (Anthropic-operated, running inside AWS) is the natural route rather than Bedrock. On Bedrock, teams typically wire up their own search: call a search API themselves and hand Claude the results as a client tool. On Vertex AI, the basic variant works, but you give up the token savings of dynamic filtering.
A minimal example
from anthropic import AnthropicAWS # Claude Platform on AWS
client = AnthropicAWS() # uses AWS_REGION +
# ANTHROPIC_AWS_WORKSPACE_ID
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=2048,
tools=[
{"type": "web_search_20260209", "name": "web_search"},
{"type": "code_execution_20260120", "name": "code_execution"},
],
messages=[{"role": "user",
"content": "What changed in this week's EU AI Act guidance?"}],
)Governance notes
Because searches leave your environment and reach the public internet, treat retrieved content as untrusted input: pages can contain text designed to manipulate the model. Keep web search out of workflows that also hold sensitive credentials or can take consequential actions without review, and log which requests enabled it.
Where to go next
If you already know the URL you need, the web fetch tool is cheaper and more precise. The feature matrix shows the full availability picture across platforms.