What Actually Differs Across Search APIs Built for Agents

TL;DR

• Raw search mode is the least interesting axis. Exa, Perplexity, Parallel, and AgentCore all return usable results for a basic query — the differences show up in filters, content budgets, page-fetch, and transport, not in whether search works.
• Three of four providers had working domain and date filters when I tested them; the fourth’s gap was in my own adapter, not the vendor, and closed within a day once I found it.
• Page-fetch is where “same data” stops being true: fetching the same PostgreSQL release page through two providers returned two different version numbers, because one provider’s cached copy was stale.
• MCP as a transport is uneven across vendors — one ships an authenticated remote MCP server with real billing, one is a documentation-only claim I never connected, and one is the same Gateway path the raw API already uses.
• None of this shows up in a vendor’s own docs page. It only shows up once you run the same 30 queries through all four and compare what came back.

Every vendor’s search-API docs page reads the same: send a query, get ranked results, ground your agent. Run the same 30 queries through four of them — Exa, Perplexity Search API, Parallel, and Amazon Bedrock AgentCore Web Search — and the docs page stops being the interesting part. What actually differs is filters, content budgets, page-fetch behavior, and transport.

Raw search: all four work, at different prices

All four returned successful results across ten queries per mode in my own test run. The pricing spread is real, but it’s the smallest difference on this list.

Domain and date filters: three worked, one didn’t — for a reason that had nothing to do with the vendor

AgentCore’s row looked like a missing vendor feature the day I first tested it. It wasn’t. AWS shipped runtime domain and date filtering for Web Search as connector version 1.2.0 three weeks before I ran that test — my own Gateway target was still pinned to 1.1.0, and my adapter only forwarded query text and result count. A version-only update to the target and a small client change closed it the next day. Parallel’s 12 missing dates are a different kind of gap: the filter works, but publication metadata is sometimes absent from what the API returns, which the filter can’t fix.

Content budgets: same idea, three different units

Every provider lets you cap how much text comes back per result, and every provider uses a different unit for it. Parallel takes a flat character limit per result. Exa separates “highlights” from full page text and caps the latter with an optional text.maxCharacters parameter, documented in its API reference. Perplexity sets a per-page token limit that multiplies by requested result count into a total budget, per its Search quickstart. AgentCore’s content shape isn’t configurable in the exposed connector at all — you get its native snippet format or nothing.

None of these numbers are comparable directly. “2,000 characters” and “500 tokens per page” aren’t the same currency, and a side-by-side comparison that treats them as interchangeable is measuring the wrong thing.

Page-fetch: this is where “the same data” stops being true

Parallel Extract ($1 per 1,000 URLs) and Exa Contents ($1 per 1,000 pages) both fetch a specific URL and return its text, capped at 10,000 characters. I fetched the same four URLs through both. Every fetch succeeded and returned nonempty text — and one of those four URLs still returned two different answers.

The URL was a PostgreSQL release page. Exa’s fetched copy showed version 18.4. Parallel’s fetched copy — and the live page itself — showed 18.6. Same URL, same provider category, one stale cache. Neither provider’s fetch failed by any check I ran; the page text was there, nonempty, under the character cap. The content was wrong in one case, and nothing in the API response flagged that.

MCP transport: three different stories under one protocol name

“Supports MCP” turns out to mean three different things:

• Parallel ships an official remote search MCP server with an anonymous, server-managed tier and an authenticated tier with its own billing. I connected and searched through the anonymous tier; the authenticated tier’s cost is a separate, unestablished number.
• AgentCore doesn’t have a second MCP option — the Gateway’s MCP endpoint is the API. There’s no raw-HTTP alternative to compare it against.
• Exa documents a hosted MCP server with search, fetch, and advanced-search tools. I never connected it. Its rate or free-tier billing is not something I can state, because I have no live evidence for it — only the documentation page.

Three vendors, three answers to “does this have an MCP option,” and none of the three answers is comparable to the others without saying which kind of MCP you mean.

What’s missing

Brave Search and Brave’s LLM Context API remain a placeholder in my own testing — I have pricing from Brave’s documentation but no live search evidence, and no filter behavior established either way. The generated-answer and managed-research products each vendor also sells — Perplexity’s Agent API, Parallel’s Task API, Exa’s Deep and Agent modes — are a different comparison with a different pricing unit, and nothing in this post’s numbers transfers to them. And every live-tested row above is a snapshot: it’s accurate as of when I ran it, not a permanent fact about the vendor, which is exactly what the AgentCore filter row already proved once.

So what

If you’re picking between these four for an agent, the mode you choose and the price per 1,000 queries are the least differentiating facts on the page. The differences that actually change what you can build are whether a filter parameter is honored server-side or dropped, whether the content budget unit matches how much your prompt window can afford, and whether a fetched page is actually current. Test those four things against your own queries before trusting a vendor’s feature-availability page — including this one, which is a snapshot from a specific week, not a permanent spec.

Part 2 of the Search for Agents series. ← Part 1: Search for agents is becoming its own market