Built-in tools: web search, code and file search

What they areCopy Anchor Link

A server-side tool is executed by the provider. You switch it on in the request, and the model decides when to use it. Common ones are web search, code execution in a sandbox, file search over uploaded documents and computer use. The results come back in the same response, often with citations.

When to use themCopy Anchor Link

Web search for facts after the model's cutoff or anything that changes. Code execution for exact math, data analysis and charts. File search for quick retrieval without building your own index. They are fast to add and cost extra per use. Your own tools are better when you need control over data, permissions or ranking.

CautionsCopy Anchor Link

Web pages are untrusted content, so search results can contain injected instructions. Keep sensitive tools away from an agent that also browses. Show citations so a user can check claims. Log tool usage for cost and for debugging.

A worked example: choosing between built-in and your ownCopy Anchor Link

Question: "What did the central bank announce today?" Built-in web search fits: current facts, public sources. Question: "How many open tickets does customer 4412 have?" Your own tool fits: private data, your permissions, your database. Many apps use both.

Watch the cost and the trustCopy Anchor Link

Each search or code run can add charges. Search results can contain hidden instructions written by strangers, so do not combine web search with tools that can send emails or move money without a human check.

How a server-side tool runsCopy Anchor Link

1. You switch the tool on in the request.
2. The model decides it needs a search and writes a query.
3. The provider runs the search on its own servers and feeds the results to the model.
4. The model may search again, then writes its answer.
5. You receive one response containing the answer, usually with citations and often a record of the searches made.

The difference from your own tools is that you never run the loop. That saves work and also means you control less.

A second example: where it fails or is not neededCopy Anchor Link

You ask "What is 4,817 x 3,296?" A model guessing digits can slip. Code execution computes it exactly: 15,876,832. Web search would be pointless here. Now ask about your company's internal wiki. Web search cannot see it, so the model either says it cannot find anything or, worse, guesses. The right choice is file search over your own documents or a tool of your own.

What goes wrongCopy Anchor Link

A citation does not support the claim next to it. Symptom: a confident answer with a link whose page says something different. To confirm, open the link and find the sentence.

The sources are weak: a forum post or an out-of-date page. The model rarely judges source quality well, so show the source name to the user.

The cost climbs because one question triggered many searches. Check your usage logs for tool counts per answer.

A page contains hidden instructions. See the caution above and keep write-capable tools away from browsing.

How to tell it is workingCopy Anchor Link

Prepare five questions: three about recent events and two timeless ones, such as "What is a prime number?" The search tool should fire for the first three and stay quiet for the others. Open every cited link and look for the exact claim. Expect to find at least one weak citation, which is why checking matters.

Common mistakeCopy Anchor Link

Presenting search-backed answers without showing the sources. Users should be able to check.