Built-In Tools vs Custom Tools in LLM Agents

In an AI agent, a tool is anything the model can ask to use, like a search engine, a database lookup or a shell command. The model does not run the tool itself. It decides which tool would help, requests it with parameters, gets the result back and continues from there.

A custom tool is one you define and run yourself. You give the model a schema for a tool like search_web or get_customer_balance. When the model requests the tool, your application runs the code on your own infrastructure.

A built-in tool runs in the provider's own runtime. The best-known example is hosted web search, which OpenAI and Anthropic both offer in their APIs. ChatGPT, Claude, Codex CLI and Claude Code use it when they search the web. DeepSeek also supports tool calls, but its API has no hosted web search, so you have to bring and run the search tool yourself.

A built-in tool feels more native because the provider runs it for you. So what is the difference between ChatGPT or Codex with built-in web search and DeepSeek with a custom search tool? The basic loop is the same in both cases. The differences come from training, search quality, speed and control, and not all of them favor the provider.

How a custom tool call works

The model never executes your function. It returns a structured request, roughly like this:

{
  "tool": "search_web",
  "arguments": {
    "query": "latest Nvidia earnings"
  }
}

OpenAI's function-calling documentation describes the flow in five steps. You send a request with the tools, receive a tool call, run the code on your side, send the tool output back, and get a final response or more tool calls.

What changes when the provider runs the tool

With hosted search, the loop moves to the provider. From your side, all of it can happen in one API request.

In Anthropic's web search tool, Claude decides when to search. The API runs the searches and gives Claude the results. This can repeat several times in one request before Claude writes its final answer with citations.

OpenAI describes the same pattern for reasoning models and calls it agentic search. The model manages the search, reads the results and decides whether to search again. In the Responses API, each search step shows up as a web_search_call item.

Does the search happen during reasoning?

Conceptually, yes. OpenAI's documentation says a reasoning model can search "as part of its chain of thought". That almost certainly does not mean an HTTP request goes out between two layers of the transformer. A better picture is that generation pauses at a tool call. A runtime outside the model runs the tool, and generation continues with the result in the context. The details, like KV cache handling, worker scheduling or separate inference passes, are internal to each provider.

Seen from outside, the provider runs the same loop you would build for your own agent:

LLM → action → environment → observation → LLM

What differs is who runs the tool and the loop around it.

Why built-in search can work better

The provider controls the model, the search and the loop. That gives it three possible advantages over a custom search tool.

The model may be trained on the tool

Compare a custom search tool:

internet_lookup(
    query,
    search_depth,
    domains,
    freshness
)

with the provider's tool:

web_search(...)

During post-training, the provider can train the model on many search sessions like this one:

question
→ reason
→ web_search
→ inspect
→ reason
→ web_search
→ inspect
→ answer with citation

Training like this teaches the model whether to search, what to search for and when to search again. It also teaches which results to open, which sources to trust, when there is enough evidence and how to cite it. The model learns a tool-use policy, which is much more than the JSON format of a tool call. Anthropic's interleaved thinking, for example, lets Claude reason about each tool result before it decides what to do next.

The model may still handle your own search tool very well, but it has probably not had the same post-training on your particular interface.

The search behind the tool can be better

Suppose your search tool looks like this:

results = search(query)
return results[:10]

The model gets ten results. If your tool returns whole pages instead, the output looks more like this:

{
  "results": [
    { "title": "...", "content": "8,000 tokens..." },
    { "title": "...", "content": "10,000 tokens..." },
    ...
  ]
}

That puts a lot of text into the model's context.

A provider's web_search may be a whole retrieval pipeline behind one tool name. Such a pipeline queries several search backends, fetches the pages and extracts the readable text. It filters out spam and duplicates, reranks the results and trims them to a token budget before anything reaches the model.

Some of this is documented. With Anthropic's web_search_20260209 and later versions, Claude can write and run code that filters the search results before they reach the context window, which cuts token use on search-heavy requests. OpenAI's web search has settings for how much search context the model gets (search_context_size) and how much content the tool returns (return_token_budget). With reasoning models, OpenAI's search can also open a page and search inside it.

Because the provider controls these steps, you often get more useful information per token of context, and that can have a large effect on agent quality. When you compare the provider's web_search with your own mySearchTool(), you may be comparing two very different retrieval systems.

Fewer round trips

In your own loop, each search goes through your application. The model's tool call comes back to your code, which calls a search API and then sends a new request so the model can continue. An agent may repeat this five times for one question.

In a hosted loop, the server that runs the model may call an internal search service and then continue. The provider controls the scheduling, networking and caching in between, so multi-step research can run faster.

When your own tools are better

A hosted tool is not automatically better. Say you are building a coding agent. Instead of generic web search, you give it tools like these, with carefully designed schemas and result formats:

search_github_code()
search_stackoverflow()
search_npm()
fetch_package_docs()
search_internal_docs()
lookup_symbol()

For that job, this set of tools can do much better than generic web search. For a financial agent, tools like these are probably a better choice than searching the open web:

get_sec_filing()
get_realtime_price()
get_earnings_transcript()
query_bloomberg()

With your own tools, you decide how results are ranked and which private sources the agent can reach. You can also log every query and result, set your own security boundaries, control the cost and switch model providers more easily.

Using a model without built-in search

If a model reasons well and handles function calls well but has no web search, you can build the loop around it yourself:

while True:
    response = model(messages, tools=tools)

    if response.tool_call:
        result = run_tool(response.tool_call)
        messages += [response.tool_call, result]
        continue

    return response.text

There is no fundamental reason why such a model could not do excellent web research. How well it does depends on its reasoning and tool-use training, and on your search stack, context management and loop design. Those matter more than whether the provider offers native search.

A model in a search loop, hosted or your own, can seem much smarter because it can look things up when it is unsure. Classic RAG (retrieval-augmented generation) retrieves documents once, before the model starts answering. In an agent loop the model decides what to look up, reads the result and can search again, so gathering information becomes part of its reasoning. Hosted search makes this easy because the provider owns the whole inner loop, but you can build the same pattern yourself.

Models without tool-use training

A model with little or no tool-use training is a different case. You can still give it tools through a text protocol and parse its output:

When you want to search, output:

<search>
query
</search>

Technically this works. But the agent can be much worse if the model has not learned when to act, which tool to use and how to fill in the arguments. The same goes for reading results, recovering from errors, exploring over several steps and knowing when to stop. Models that support tool calls but use them poorly fall somewhere in between. This is one reason agentic models feel different from older LLMs, even though both can output JSON.

Four levels of tool hosting

Tools can run in more than two places. There are roughly four levels:

1. a function in your own client code
2. a remote tool or MCP server
3. a tool hosted by the model provider
4. a full agent environment with a shell, file system, browser and search

At the fourth level you are comparing whole agent systems, and the model is only one part of each.

Side-by-side comparison

Should built-in search decide your provider?

I would not choose an LLM provider only because it has native web search. If a model reasons well and is good at using tools in general, you can build a strong search agent on top of it. For specialized uses, your own agent can do better than the built-in search. Native search matters most when you want strong general-purpose research with little engineering.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com