Tavily API Key or One Key: Four Web Search APIs, One Query, Zero URLs in Common

Copy this line to your agent to run one search across four engines.

set up https://monid.ai/SKILL.md and use octen /search, blockrun.ai /api/v1/exa/search and context.dev /web/search for one query

Someone searching for a Tavily API key wants web search inside an agent and is about to sign up for one vendor. Before you do, here is what happened when we sent one query to four search engines on one key in one minute on 2026-09-16. Two of them shared no URLs at all. Two of them returned exactly the same nine pages in exactly the same order, because one of them is Google. And exactly one of the four found our own article on the topic. This guide runs through Monid, the OpenRouter for agent tools.

Do you need a Tavily API key to give an agent web search?

You need a key to some search engine, and the question is whether it should be one vendor's key or one key that reaches several. We do not resell Tavily, so this article cannot tell you how it performs. It can show you what the alternative to a single-vendor key looks like, measured.

What a single-vendor key gives you

One engine, one index, one ranking, one set of fields. Everything your agent knows about the web passes through one company's view of it. That is simpler to set up and it is a real constraint: the four engines below disagreed with each other on a plain question, and an agent on any one of them would never have known.

What one key across engines gives you

The ability to ask the same question twice and notice when the answers differ. On the query below, that difference was total: two engines had zero URLs in common. An agent that can call both has a second opinion for the price of a second call, and the cost of that call on a per-call engine is a fraction of a cent.

The honest cost

A discovery step, and a schema per engine rather than one. The four engines below took four different request bodies and returned four different response shapes, and the first two calls failed on a parameter name before succeeding. That is the tax on choice, and the sections below pay it so you can see what it buys.

📖 See also Octen AI Search API: 78 ms Inside, One Second End to End

Why did four search APIs return three different answers?

Because they are three different products, and only one pair of them shares an index.

The measurement

Query what is an mcp gateway, ten results requested, 2026-09-16:

Two of them are Google

context.dev/web/search returned nine results: Kong, a Reddit thread, TrueFoundry, MCP Manager, Aembit, Speakeasy, Zuplo, Credal, AWS. mrscraper/serp/google returned nine organic results: Kong, the same Reddit thread, TrueFoundry, MCP Manager, Aembit, Speakeasy, Zuplo, Credal, AWS. Same nine URLs, same order.

One index, two envelopes. The context.dev route attaches a markdown field per result, the page's content inlined, and bills per result. The mrscraper route attaches what Google shows around the organic results, four people_also_ask questions, an ai_mode block, an empty sponsored array, and bills per call. If you want Google's ranking with page content, take the first. If you want Google's ranking with the SERP features, take the second. They are not two engines.

Octen and Exa share nothing

octen/search returned Kong, TrueFoundry, Composio, a YouTube explainer, Red Hat docs, Google Cloud, Skywork, and three GitHub repositories. exa/search returned Traefik, Agen, Vynula, monid.ai, Microsoft's GitHub page and its docs site, Tyk, MCP Manager's docs, FutureAGI and WSO2.

Zero URLs in common. One domain in common, github.com, pointing at different pages. Two engines, two indexes, two rankings, and an agent on either one would have called its answer complete.

What the field lists tell you

Octen returned time_published and time_last_crawled on every row, a highlight of query-relevant passages, and an author. Exa returned id, title, url and publishedDate, and a costDollars object saying the call cost 0.007 on its neural index. Context.dev returned a relevance score and inline markdown. Google via mrscraper returned rank and global_rank and the SERP furniture.

Four engines, four ideas of what a search result is. The one that found our page returned the least about it. The comparison of these shapes across the wider search market is in the best web search API for agents.

How do you run one query across four engines on one key?

Four calls, four request bodies, and two of the bodies will be wrong the first time. Here are the ones that worked.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Step 1. The keyword index with dates

The endpoints. octen/search, per call.

monid run -p octen -e /search -i '{"query": "what is an mcp gateway", "count": 10}'

What comes back. Ten rows with two dates each and a highlight. The fastest of the four at 1.1 seconds end to end, and the one whose freshness you can read per result.

Step 2. The neural index

The endpoints. blockrun.ai/api/v1/exa/search, per call, takes query and numResults.

monid run -p blockrun.ai -e /api/v1/exa/search -i '{"query": "what is an mcp gateway", "numResults": 10}'

What comes back. Ten rows with almost no metadata and a costDollars block. The slowest at 4.0 seconds, and the only one that surfaced a page the keyword engines did not.

Step 3. Google, two ways

The endpoints. context.dev/web/search, per result, takes numResults not limit. mrscraper/serp/google, per call, takes query not q.

monid run -p context.dev -e /web/search -i '{"query": "what is an mcp gateway", "numResults": 10}'
monid run -p mrscraper -e /serp/google -i '{"query": "what is an mcp gateway", "region": "us", "language": "en"}'

Both parameter names were wrong on our first attempt and both returned a 400 naming the right one, at no charge. That is the schema tax mentioned above, paid once.

What comes back. The same nine pages from each. Pick by envelope: inline markdown and per-result billing, or SERP features and per-call billing.

Step 4. Diff the URL sets

sets = {name: {normalize(r["url"]) for r in results} for name, results in engines.items()}
shared = set.intersection(*sets.values())
# on 2026-09-16: shared == set()

An empty intersection across four engines is not a bug. It is the finding.

📖 See also Live Web Search Your Agent Can Call

Which engine found the page the others missed?

Exa, and the page it found was ours, which is the one case where we can say with certainty that the other three missed something relevant.

What happened

Our guide What Is an MCP Gateway? Two Products, One Name is an article about exactly this query, published 2026-08-20. Exa returned it at position four. Octen did not return it. Google did not return it on page one, so neither Google-shaped route did either.

Why this is not a complaint about the other three

Google's page one is Google's page one; a young domain not ranking there is the expected state and the subject of our own Domain Rating measurement. Octen's index is a keyword index and ranked ten pages that all answer the question. Neither is wrong.

Why it matters anyway

An agent doing research on one engine sees one engine's view. Exa's neural retrieval found a relevant page that two keyword indexes and Google's ranking did not surface, and on a different query the roles could reverse. A second engine is not redundancy. It is coverage. The same measured divergence between two providers on one query, four posts in common out of seventeen, is what the Reddit scraper comparison found on a different surface.

The cost of the second opinion

On per-call engines, one more call. Octen and Exa together came to a fraction of a cent for this query. The expensive part of a research agent is never the second search; it is the conclusion drawn from the first one.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-09-16. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.

The two Google rows are one index. Choose between them on what you want attached, not on which is "better", because on the ranking they are identical.

When is one search engine the right call?

Four cases.

Your agent needs Google's ranking specifically. SEO tools, rank tracking, "what does a user see" questions. Then you want a Google-shaped route, and the two here return the same pages; the choice is content versus SERP features.

You are building on a vendor's other features. If a single-vendor key comes with a research agent, a crawler and an extraction API you also use, the integration cost of one key may be lower than the coverage gain of several. That is a real trade and the answer depends on what else you call.

Latency dominates. The four engines ran from 1.1 to 4.0 seconds end to end. An interactive agent that cannot wait four seconds should pick the fast index and accept its coverage, and the Octen guide is about exactly what that speed does and does not mean.

You have already measured on your queries. If you ran your own questions through two engines and one consistently returned what you needed, use that one. The point of this article is the measurement, not the number of engines.

And the disclosure: this is Monid's blog and we resell the four engines compared here and not the one in the title. The finding that helps a Tavily user is not "switch"; it is that any single engine, Tavily included, is one view, and the only way to know what it misses is a second call to something else.

Conclusion

A Tavily API key is a key to one engine, and one engine is one view of the web. On 2026-09-16 four engines answered one question with three different result sets: a Google page reached by two routes, a keyword index that shared nothing with a neural index, and the neural index alone surfacing the page we happen to know was relevant. None of them was wrong. Each of them was partial.

What matters more than which engine is whether your agent can ask twice. On one key, the second call to a different index is a fraction of a cent and takes a second, and it is the only mechanism that turns "the search returned ten results" into "two engines agree on these three". Read the response shapes before you build, because the engine that found the most returned the least about it, and the two that looked like competitors were the same nine pages.

Free next step: run monid inspect -p octen -e /search and monid inspect -p blockrun.ai -e /api/v1/exa/search, then send one question you know the answer to through both and diff the URLs. Start at monid.ai.

FAQ

Last updated September 2026.