Choose the best web-access API for an agent

Your agent needs a web-access API and faces a wall of provider landing pages, each claiming to be the best. But “best” isn’t one answer: the best search API is not the best scraper, the best crawler is not the best extractor, and the ranking shifts as providers change. Picking from marketing copy is guessing. This page shows how an agent picks on measured evals, from one Auxiliar key that already has every provider wired in.

What the agent is trying to do

The agent has a concrete job: map the task in front of it to the provider that does that job best right now — and be able to call that provider without a procurement detour. It wants a decision it can defend with data, not a coin flip between two homepages.

That requires a few things at once:

• The right verb. First classify the job — search, scrape a URL, crawl a site, extract structured fields, screenshot, or drive a browser. Each is a different market with a different leader.
• Current, comparable scores. Quality, latency and cost for candidate providers, measured on the same corpus so the numbers actually compare.
• A tie-breaker. When two providers are close, price-per-success, latency, or a specific feature decides it.
• Instant access to whichever it picks. A choice it can’t act on without a new signup isn’t a choice.

Why the agent cannot solve this alone

Picking well is a data problem, and the data isn’t in the model. On its own, an agent cannot:

• Create or manage provider accounts — it can’t open accounts across a dozen providers to trial them and agree to terms for a human.
• Pass signup, payment, and bot flows — each provider’s onboarding sits behind email verification, card entry, and its own bot gates that need a real human browser.
• Safely hold many upstream keys — even if it had accounts, spreading a dozen provider secrets across its context or environment is a credential-sprawl and exfiltration risk.
• Benchmark providers on a level field — running every provider on the same corpus to compare quality, latency and cost is measurement infrastructure, not a conclusion the model can reach by thinking.
• Know today’s ranking — which provider is winning a verb right now is live data, and last quarter’s blog post is stale.

So the blocker isn’t reasoning. Choosing well needs accounts, credentials, and current benchmark data — none of which live inside the model.

How Auxiliar solves it

Auxiliar is a web-access API gateway that turns “which provider?” into a lookup, not a procurement project:

• One AUXILIAR_API_KEY — every search, scraping, crawling, browser and voice provider on a single credential.
• Upstream keys server-side — the agent never sees or manages a provider key.
• Native provider routes — once it picks, the agent calls https://api.auxiliar.ai/{provider}/{native-path} with that provider’s own request shape.
• One balance — credit-metered against a single account, so trying a second provider costs nothing but the call.
• Eval-backed selection — the Auxiliar curator fleet benchmarks every provider per verb on one shared corpus and publishes the ranking at /evals.json and the /best/ pages — a merit-only ranking with no house-provider thumb on the scale.
• Machine-readable discovery — the auxiliar-mcp server reads those same evals so an agent can call recommend_tools and get_scorecard to pick in-loop.

First call

Before choosing, read the evals. The catalog and every measured score are one authenticated GET away — the same data the ranking pages render.

curl "https://api.auxiliar.ai/evals.json" \
  -H "Authorization: Bearer $AUXILIAR_API_KEY"

Classify the job, look up the winning provider for that verb, then call it — for example a search, which the evals.json ranking hands to a top provider:

curl -X POST "https://api.auxiliar.ai/serper/search" \
  -H "Authorization: Bearer $AUXILIAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"q": "who won the job for this verb"}'

Agents that want the pick made for them can let the auxiliar-mcp server’s recommend_tools read the same evals and return the ranked provider list directly.

Fallback ladder

For provider selection, the “ladder” is by verb: classify the job, take the top-ranked provider, keep the runner-up as fallback. Every winner below is on the same key — routing between them is a one-line path change, not a new account. All scores are measured by the Auxiliar curator fleet on one corpus per verb.

The rule of thumb: classify the verb first, then take the measured winner — and because the runner-up is on the same key, keep it as a one-line fallback when the leader misses a specific target.

Eval-backed, not marketing claims

Every winner above comes from the Auxiliar curator fleet running each provider on the same corpus per verb — a merit-only ranking, not a listicle. Verify or route from the source:

• All 24 tools — the full catalog, grouped by capability, each with its eval scores.
• Best search · Best scrape · Best crawl · Best extract — the per-verb rankings with methodology.
• /evals.json — the machine-readable catalog + eval endpoint your agent (or the auxiliar-mcp server) reads to pick in-loop.

Optimizing for cost

Once the winner is chosen, cost is a routing decision, not a contract:

1. Pick on cost-per-success, not sticker price. The eval pages report cost per useful result or successful page — the number that reflects real spend. A cheaper call that fails is the expensive one.
2. Default to the cheapest sufficient provider per verb. For easy jobs, the runner-up often wins on price while clearing the bar; reserve the top provider for the hard cases.
3. Keep the top provider as fallback. Route the cheap default first and escalate to the leader only on failure — both are one key away.
4. Re-check the ranking, don’t re-integrate. Because every provider is already on the same key, switching to a new winner when the evals move is a path change, not a migration.
5. Let the evals drive routing. Read /evals.json (or recommend_tools) so the choice reflects current measured data, not a decision hard-coded months ago.

Because all providers sit behind one key and one balance, choosing — and re-choosing — is routing logic in your agent, with no renegotiated contracts and no new signups.