Choosing a search tool your agent can actually work with

A search tool that serves people well can still fail an agent. A person skims a results page, opens a few tabs and ignores the junk. An agent receives whatever the tool returns as text in its context, decides what to believe and what to call next, and does this many times in one task. Choosing search for an agent is therefore less about which results look best on a screen and more about the contract between the tool and the agent's loop. This guide covers what that contract needs, the integration paths you will meet, and a checklist for comparing options on your own tasks. For the wider comparison of web search providers by index, terms and pricing model, see how to choose a web search API.

How an agent actually uses search

Inside an agent loop, search is a tool call. The model writes a query, the tool returns results, and the model reads them and chooses: answer, refine the query, fetch a page, or call another tool. Four consequences follow.

• A model writes the queries. They tend to be longer and more specific than what people type, and sometimes oddly phrased. The tool has to cope with full questions as well as keyword strings.
• Everything returned gets read. Results consume context and steer the next step. An irrelevant result is not simply skipped; it can mislead.
• Search repeats. A research task may issue many queries as the agent narrows down, so small delays and costs multiply.
• The agent sees only what the tool extracts. If the answer sits in a table, a PDF or a page rendered by scripts, the tool's extraction decides whether the agent ever sees it.

Agentic search describes this loop and its variations in more detail.

Machine-readable results

The response should be structured data with a documented, stable schema, not markup the agent has to untangle. Look for these properties:

• One record per result with consistent fields: title, URL, the text you will pass to the model, and dates.
• A clear line between source text and generated text. If the provider adds a summary, it should be labelled as generated rather than blended into the page content.
• Predictable size. Parameters for the number of results and the amount of text per result let you manage the context budget instead of truncating blindly.
• Errors as data. Rate limiting, timeouts, blocked pages and empty results should come back as distinct, documented states your code can branch on.

{
  "query": "warehouse robot safety standard revision",
  "status": "ok",
  "results": [
    {
      "url": "https://example.org/standards/revision-notes",
      "title": "Revision notes for the standard",
      "published": null,
      "retrieved": "set at run time",
      "passages": ["the exact text the agent will read"],
      "generated_summary": null
    }
  ]
}

Field names differ between providers. What matters is that every field the agent relies on has a name, and that a missing publication date can be represented as missing rather than quietly filled in.

Passages, full pages or answers

Agents usually do best with query-focused passages: enough text to support a claim, little enough to leave room in the context for reasoning and other tools. Full page content earns its cost when the agent has to extract structured data or read a long document closely. Synthesized answers are quick, but they place another system's reasoning between your agent and the source. If you use them, keep the underlying sources and treat the answer as a lead rather than a fact.

A pattern that works well is two-stage. Search returns passages for many candidates, the agent picks the few that matter, and a separate fetch or extraction tool retrieves full content only for those. The expensive step stays narrow, and the agent's context stays readable.

Citations and provenance

If someone will rely on what your agent produces, every claim needs a path back to its source, and the search tool decides whether that path exists. Check that each result carries a canonical URL, a title and ideally the exact passage the agent saw. Check that dates separate when a page was published or updated from when the provider fetched it.

Then check the agent as well as the tool. A model can attach a real URL to a claim the page never makes. Spot-check by opening the source and finding the supporting sentence. Part of this can be automated: a test can confirm that any passage the agent quotes actually appears in the text the tool returned. Citations that hold up goes further into what a usable citation looks like.

Freshness and coverage where you need them

Freshness matters unevenly. An agent answering questions about prices, regulations, software releases or news needs recent pages; an agent explaining established concepts mostly does not. Identify which of your tasks are time-sensitive and test those specifically, using questions whose answers appeared on the web only recently.

Coverage works the same way. If your users ask in Turkish, about local companies or about a niche technical field, test exactly that. A tool that handles general English questions well tells you little about the questions your agent will actually face.

Fit with tool calling

How search reaches your agent affects reliability as much as result quality does.

For the MCP route specifically, see choosing a web search MCP server. Whichever path you take, write the tool description with care, because the model decides when to search from that text alone. Say what the tool is for, what it returns and when not to use it, for example “not for questions about the user's own files”.

Where GoCux fits

GoCux is not a search API and does not crawl or read the open web, so it is not one of the options on your list. Its Knowledge search works on a different corpus: the documents of a single project. A question goes in, and passages come back with their citations. An empty result counts as a valid answer, and “unavailable” is reported separately from “nothing found”, which is the same distinction the checklist below asks of any search tool.

GoCux is useful around the agent's tools rather than as one of them. MCP tools run in your own compatible client, a server you have configured is not thereby allowed in every task, and read-only access is the sensible place to begin; start agents read-only explains why. Findings backed by a quotation are kept apart from questions that no source answered, so a reviewer can see what was supported and what was not.

A comparison you run on your own tasks

Generic benchmarks test search in isolation. What you need to know is whether your agent finishes its tasks correctly with each option. Run the comparison end to end:

1. Pick 20 to 40 real tasks your agent should handle, including a few where the right outcome is “I could not find this”.
2. Write the expected outcome for each task before running anything.
3. Swap only the search tool. Keep the model, prompt and other tools fixed.
4. Record for each task: correct or not, number of search calls, tokens consumed, wall time, and whether each citation supports its claim.
5. Repeat the run on another day to see how stable the results are.

Alongside the run, ask each option these questions:

• Is the response structured, documented and stable across versions?
• Can you control result count and text length per result?
• Are passages returned, and is any generated text labelled as such?
• Does every result carry a URL and dates that separate published from retrieved?
• Are empty results, errors and rate limits distinct states?
• Does it cover your languages, regions and domain?
• Does it fit your integration path without losing fields?
• Do the terms allow your storage and display, and what happens to the queries your agent sends?

For grading retrieval quality more rigorously, see judging recall and accuracy of AI search and the docs page on evaluating search.