Amazon Bedrock in Practice

Adding Live Web Search to Claude on Bedrock Without Built-In Web Tools

Anthropic's server-side web search and web fetch tools are not available on Bedrock. Tool use is — and that is all you need to build search-augmented generation you fully control.

Claude 3P 101 · Updated July 2026 · Unofficial guide

On Anthropic's first-party API, you can hand Claude a server-side web search tool and let Anthropic's infrastructure run the searches. On Amazon Bedrock, none of the server-side web tools exist: web search, web fetch, and code execution are all unsupported there. What Bedrock does fully support is standard tool use (sometimes called function calling) — the mechanism where you describe a tool in your request, Claude decides when to call it, and your code executes the call and returns the result. That is the entire basis of the workaround: bring your own search backend and expose it to Claude as a tool.

The architecture in one paragraph

Your application defines a web_search tool with a simple input schema (a query string). When a user asks something that needs fresh information, Claude responds with a tool-use request instead of an answer. Your code runs the query against a search backend you operate or subscribe to — a commercial search API, an internal index, or both — then sends the results back as a tool result. Claude reads them and writes the final answer, grounded in what the search returned. Nothing about this requires Bedrock-specific features beyond ordinary tool use.

A minimal implementation

from anthropic import AnthropicBedrockMantle

client = AnthropicBedrockMantle(aws_region="us-east-1")
tools = [{
    "name": "web_search",
    "description": "Search the web for current information.",
    "input_schema": {"type": "object",
                     "properties": {"query": {"type": "string"}},
                     "required": ["query"]},
}]
messages = [{"role": "user", "content": "What changed in our industry this week?"}]
response = client.messages.create(model="anthropic.claude-sonnet-5",
                                  max_tokens=2048, tools=tools,
                                  messages=messages)
# If response.stop_reason == "tool_use": run the search yourself,
# append a tool_result message with the findings, and call again.

The loop after the comment is the part you own: extract the tool-use block, call your search backend, and append a tool_result content block with the findings before invoking the model again. Most production versions run this loop until Claude stops asking for tools.

Feeding results back well

Result formatting matters more than backend choice. Return a handful of results with title, URL, and a text snippet — enough for Claude to judge relevance and cite sources, not entire raw pages. Claude on Bedrock supports search-results content blocks and citations, which let you return results in a structured form and get answers that attribute claims to specific sources; that combination is worth using if verifiable answers are a requirement. If you need full-page content, fetch and extract the text in your own code first, and trim it — every character you return is input tokens you pay for.

What you take on by self-managing

ConcernWho handles it in this pattern
Search quality and coverageYour chosen backend and your query handling
Search cost and rate limitsYour contract with the search provider
Fetching and sanitizing page contentYour code — treat fetched text as untrusted input
Compliance and egress reviewYour security team; searches leave your boundary to whatever backend you pick

The last two rows deserve emphasis. Content retrieved from the open web can contain adversarial instructions aimed at your model (prompt injection), so treat search results as data, never as trusted instructions — constrain what actions Claude can take based on them, and prefer read-only tools in this loop. And because your application, not the model platform, calls the search provider, that egress is a new data flow for your security review: what queries leave, to whom, and what gets logged.

Rule of thumb: the model decides when to search; your code decides what actually happens. Keep every side effect on your side of the tool boundary.

One more option check before you build: if your organization also runs Claude Platform on AWS (Anthropic-operated, inside AWS), the server-side web search and web fetch tools are available there. For teams committed to Bedrock proper, the tool-use pattern above is the supported path.

Where to go next

See the Bedrock feature availability matrix for the full list of gaps, prompt injection 101 before you wire untrusted web content into prompts, and web tools on Claude Platform on AWS if you want the managed alternative.

Sources