The whole thing is one request

A search API takes a query and returns results as structured data: for each result a title, a link, a snippet and sometimes a date. The agent's code hands that list to the model, the model picks which pages look promising, the code fetches them, and the model writes an answer with citations.

Everything interesting is in the details: which index was searched, how fresh it is, and how much of each page the model actually saw.

Three kinds of search API

  • Independent indexes: services that crawl the web themselves and sell access to their own index.
  • Results from the big engines: official programmable search products, with quotas and restrictions, and third-party services that collect results pages for you.
  • AI-native search: APIs built for language models, which return cleaned page text or ready-made summaries instead of ten blue links.

The market shifted in 2025

For years many products were built on Microsoft's Bing Search APIs. Microsoft retired them in August 2025 and pointed developers to a grounding service inside its AI platform instead. That pushed many teams toward independent and AI-native providers, and it is a reminder to keep your search provider behind an interface you can swap.

What to compare

  • Index size and freshness: can it find a page published this morning?
  • Content: links only, snippets, or cleaned full text ready for a model.
  • Filters: date, site, language, country, and whether you can sort by date.
  • Cost per thousand queries, and whether failed requests are billed.
  • Rate limits and latency. An agent that makes five searches per answer multiplies both.
  • Terms: what you may store, cache and show to users.

Why agents struggle with API keys

A key means an account, a billing page and a secret to keep safe. That is fine for a company and awkward for an agent running on someone's laptop. It is one reason keyless and free tiers are popular for prototypes. They come with strict rate limits and no guarantees, so plan to move to a paid plan once people depend on your product.

Tools and MCP

Models call search through tool definitions: a name, a description and a list of parameters. The Model Context Protocol standardises that packaging, so one search server can be plugged into many assistants. A good search tool exposes few parameters, returns compact results and has a separate tool for fetching a page.

The failure modes

  • Prompt injection: a web page can contain text addressed to the model, such as "ignore your instructions". Treat fetched content as data, never as instructions, and don't let a search agent take actions on its own authority.
  • Stale results: an index a week behind will confidently miss yesterday.
  • Spam: pages written to rank, not to inform. Prefer sources with a reputation to lose.
  • Truncation: the model may have read only the first part of a long page.
  • Circular sourcing: several results repeating one original claim are still one source.

Recipes worth copying

  • Search, then fetch: get ten results, read the top three in full, answer with links.
  • Query rewriting: have the model turn a vague question into two or three precise searches.
  • Date-bounded research: restrict to the last week for news and to a year for technical topics.
  • Cross-check: run the same question through a second provider when the answer matters.
  • Domain allow-lists for medical, legal and financial questions.

Who actually needs this

If you are building an assistant, a research tool or a monitoring job, you need a search API. If you just want answers with sources, you don't. Use an assistant that already has search wired in.

UncutGPT offers this through its chat workspace. It has 220+ models, and supported ones can search the web when you turn web search on. We also offer an OpenAI-compatible model API for developers; the API reference describes its supported operations. In the chat workspace, you can compare the same search-backed question across several models.