Adding a search API to an agent is easy. Making the results trustworthy is a different job, and it is mostly judgement: were these results relevant, did we phrase the query the way the page is written, and what does the competition for this query leave unanswered.
Those three judgements are what the search skills in the directory encode — Search Result Eval, Query Expansion, and SERP Gap Analysis. They sit above any API, which is why they are worth understanding separately.
The short answer
Use an API for retrieval and a skill for evaluation. Most search failures are not retrieval failures — they are the agent treating a weak result set as a strong one.
The evaluation gap
A search API returns ranked results with no statement about quality. An agent then summarises them, and the summary inherits the rank order whether or not the results were relevant.
Search Result Eval inserts one step: label each result relevant, partial, or off-topic, then refuse if fewer than two are relevant. The refusal is the feature — a weak result set reported as weak is far less damaging than a confident answer built on forum noise.
The phrasing gap
Users ask questions; pages are written as statements. A literal query often misses the page that answers the question.
Query Expansion produces three queries — literal, synonym-based, and title-oriented — and the discipline is deduplication. Three paraphrases of the same words waste budget without improving recall; three genuinely different phrasings do not.
The competition gap
For content work, the useful question is not 'does this rank' but 'what do the top results leave out'.
SERP Gap Analysis reads the top results and lists the questions they answer poorly, with quotes. A gap is evidence, not demand: a question nobody searches for is still a gap, and still not worth a page.
The comparison
| Fix | API | Skill |
|---|---|---|
| Retrieve results | Yes | No |
| Judge relevance | No | Yes |
| Rephrase the query | Partial | Yes |
| Compare result sets | No | Yes |
| Cost control | Per call | Rule-based |
The table explains why skills do not replace APIs: they operate on what the API returned. What they replace is the agent's default of trusting it.
A worked loop
A question arrives. Query expansion produces three phrasings. The API returns results for each. The evaluation step labels them and finds only one strong result. That is a weak set, and the correct behaviour is to say so — not to write a paragraph around one snippet.
The alternative loop, without skills, produces a confident answer from the same single result. The difference is one evaluation step and a rule about refusing.
Where the skills stop
They cannot tell you whether the page is true. They can tell you whether it was relevant, whether the query reached it, and what it omitted. Truth needs the claim verification step, which is a different skill.
Frequently asked questions
Do these work with any search API? Yes. They read results, not vendor internals, which is why they are portable across Exa, Tavily, and Brave.
Is evaluation just another model call? It is — one with a fixed output shape and a refusal rule. That is what makes it checkable.
What about cost? An extra call per search is cheaper than a wrong answer, and the evaluation can be skipped for non-critical lookups. See giving an agent web search.
Last checked: 11 November 2026.
Related: search APIs for agents, answer engines vs search engines, and search skills.
