Exa vs SerpApi

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Exa✓fullprobed9/10

   Exa hosts a real llms.txt (verified live at exa.ai/llms.txt, HTTP 200) plus a full documentation index at /docs/llms.txt, and its docs pages have .md variants (e.g. search-api-guide.md) explicitly designed for agent consumption, with agent-skills.md teaching coding agents to use Exa's APIs. This is corroborated by a live probe, not just vendor claims. Missing for 10: independent third-party confirmation that agents actually consume/parse these files successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://exa.ai/llms.txt # Exa > Exa is a real-time knowledge index and retrieval platform built for AI agents. …”
   • [probe] “PROBE docs-md: HTTP 200 at https://exa.ai/docs/reference/search-api-guide.md > ## Documentation Index > Fetch the complete documentation ind…”
   • [claimed-docs] “Return query-relevant excerpts from Exa Search results while controlling context size and latency.”
   • [claimed-docs] “Use iterative search, reasoning, and grounded synthesis for complex research tasks.”
   • [claimed-docs] “Exa skills teach coding agents how to search, retrieve content, and build with Exa's APIs.”

   proof ↗⚑ flag

   SerpApi✓fullprobed9/10

   Probe confirms llms.txt exists at serpapi.com/llms.txt (HTTP 200) and per-page markdown docs (.md suffix) are available, plus explicit docs pages describing markdown output optimized for LLMs/agents and MCP integration. missing for 10: no independent/community confirmation of an agent actually consuming llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [probe] “PROBE docs-md: HTTP 200 at https://serpapi.com/search-api.md --- title: "Google Search Engine Results API" description: "Scrape Google searc…”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”
   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to SerpApi
   Exa✓fullprobed7/10

   Exa is an API-first product (exa-js SDK, REST endpoints, webhooks, streaming) that is naturally callable headlessly from scripts/CI without any UI, and supports async batch operations like Websets and deep research suited to automation pipelines. missing for 10: no explicit CI/CD example (e.g., GitHub Actions), no dedicated 'headless/automation' documentation section, and no independent report confirming CI usage.

   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [github] “Search streaming is available via `streamSearch(...)`, which yields OpenAI-style chat completion chunks.”
   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [claimed-docs] “A single command creates an Exa account and syncs an API key into your project.”
   • [probe] “PROBE docs-md: HTTP 200 at https://exa.ai/docs/reference/search-api-guide.md > ## Documentation Index > Fetch the complete documentation ind…”

   proof ↗⚑ flag

   SerpApi✓fullprobed8/10

   SerpApi is a pure REST API with API-key auth and official SDKs (Python, etc.) enabling non-interactive scripted calls with no browser/UI, suitable for CI/automation; docs also show an async submission mode for background/batch jobs. Missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions workflow) or dedicated docs describing running in CI.

   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [claimed-docs] “Parameter defines the way you want to submit your search to SerpApi. It can be set to `false` (default) to open an HTTP connection and keep …”
   • [github] “SerpApi provides a script builder to get you started quickly.”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”
   • [probe] “PROBE docs-md: HTTP 200 at https://serpapi.com/search-api.md --- title: "Google Search Engine Results API" description: "Scrape Google searc…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Exa
   Exa✓fullprobed9/10

   Exa ships a well-documented official MCP server with setup guides for Claude Desktop, Cursor, VS Code, ChatGPT, Codex, Grok and any MCP client, exposing web search, fetching, Exa Agent, and Exa Connect tools; it's open source and requires no API key to start. This is a first-party, dedicated server product (not an agent-client scenario), directly satisfying the story. Missing for 10: independent hands-on community verification of the MCP server specifically (community evidence covers the web/search product but not MCP integration experience).

   • [claimed-docs] “Complete setup guide for Exa MCP Server. Connect Claude Desktop, Cursor, VS Code, and 10+ AI assistants to Exa's web search, fetching, Exa A…”
   • [claimed-docs] “Exa MCP connects AI assistants to Exa’s search capabilities, including web search, code search, Exa Agent, and Exa Connect.”
   • [claimed-docs] “Connect Claude Desktop, Cursor, VS Code, and 10+ AI assistants to Exa's web search, fetching, Exa Agent, and Exa Connect tools.”
   • [claimed-docs] “Connect ChatGPT, Codex, Claude, Grok, Cursor, and any other MCP client to Exa's web search, page fetching, Exa Agent, and Exa Connect tools.”
   • [claimed-docs] “No API key is required to get started. Exa MCP is open source and available on GitHub.”
   • [probe] “official MCP server documented at https://exa.ai/docs/reference/exa-mcp”

   proof ↗⚑ flag

   SerpApi✓fullprobed7/10

   SerpApi documents an official MCP integration letting MCP-compatible agents (Claude, ChatGPT, Cursor) use it as a web search tool, and a dedicated serpapi-mcp GitHub repo confirms a first-party MCP server implementation. Missing for 10: independent/hands-on community corroboration of the MCP server working in practice, and detailed setup/config docs beyond the brief integration blurb.

   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Exa—none0/10

   Evidence covers Exa's SDKs (exa-js), MCP server, dashboard, and API docs, but no official CLI tool is mentioned anywhere in the pack. Since API-first companies commonly ship a CLI, the axis applies, but there's no evidence Exa offers one.

   ⚑ flag

   SerpApi—none0/10

   SerpApi ships client libraries, an MCP server, and a script builder, but there is no evidence of an official CLI tool for interacting with the API.

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Exa
   Exa✓fullprobed9/10

   Exa provides a well-documented public API (search, answer, websets, structured extraction) plus official SDKs (exa-js) with concrete code examples for driving it programmatically, corroborated by llms.txt/docs probes and community hands-on trial usage. missing for 10: no discoverable OpenAPI/swagger spec (404s on all probed paths), which would round out machine-readable API documentation.

   • [claimed-docs] “from ~250 ms instant search to 12-40 second deep-reasoning search”
   • [claimed-docs] “Use `output_schema` with any search type to extract structured JSON from search results”
   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [github] “const { answer } = await exa.answer("What is the capital of France?");”
   • [claimed-docs] “Our API endpoints have default rate limits to ensure reliable performance for all users.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://exa.ai/llms.txt # Exa > Exa is a real-time knowledge index and retrieval platform built for AI agents. …”
   • [probe] “PROBE docs-md: HTTP 200 at https://exa.ai/docs/reference/search-api-guide.md > ## Documentation Index > Fetch the complete documentation ind…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://exa.ai/openapi.json, https://exa.ai/swagger.json, https://exa.ai/api/openapi.json, https://e…”
   • [community] “Signed up for a trial account and I'm pretty impressed with the search API (haven't used Websets yet but looks cool). Suggested adding a 'cr…”

   proof ↗⚑ flag

   SerpApi✓fullprobed8/10

   SerpApi is fundamentally an API product with extensive documented endpoints (Search, News, Ads, Flights, etc.), official client libraries in multiple languages, markdown/JSON output modes for LLM consumption, llms.txt and .md doc endpoints for AI agents, and an official MCP server, all confirmed by live probes and docs. missing for 10: no discoverable OpenAPI/Swagger spec (probe found 404s across candidate paths), and independent hands-on confirmation is limited to community commentary rather than a full third-party integration review.

   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”
   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [probe] “PROBE docs-md: HTTP 200 at https://serpapi.com/search-api.md --- title: "Google Search Engine Results API" description: "Scrape Google searc…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Exa—none0/10

   No evidence of scoped or least-privilege API key/credential issuance—docs mention API key sync into a project and rate limits, but nothing about granular permissions, scopes, or restricted-access tokens for agents.

   • [claimed-docs] “A single command creates an Exa account and syncs an API key into your project.”
   • [claimed-docs] “Our API endpoints have default rate limits to ensure reliable performance for all users.”

   proof ↗⚑ flag

   SerpApi—none0/10

   Evidence shows only a single API key mechanism (used directly in requests) with no mention of scoped, role-based, or least-privilege sub-keys/tokens for agents; community feedback even flags that embedding the secret key in the URL complicates secret management, suggesting no finer-grained credentialing exists.

   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [community] “Embedding the API key (secret) in the URL complicates secret management. Please move that to a header and allow setting via env var.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Exa
   Exa✓fullclaimed8/10

   Exa ships an official JS/TS SDK (exa-js) on GitHub with documented methods like webSearch(), streamSearch(), answer(), and schema-constrained search, directly supporting AI-native SDK-based integration into agent loops. missing for 10: independent/hands-on community validation of SDK quality, and evidence of official SDKs beyond JS/TS (e.g., Python) are not shown in the pack.

   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [github] “Search streaming is available via `streamSearch(...)`, which yields OpenAI-style chat completion chunks.”
   • [github] “const { answer } = await exa.answer("What is the capital of France?");”
   • [github] “For type: "object", search currently enforces: max nesting depth: 2, max total properties: 10”
   • [github] “Search streaming is available via streamSearch(...), which yields OpenAI-style chat completion chunks.”
   • [github] “Get answers with citations const { answer } = await exa.answer("What is the capital of France?");”
   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”
   • [claimed-docs] “Use `output_schema` with any search type to extract structured JSON from search results”

   proof ↗⚑ flag

   SerpApi✓fullprobed7/10

   SerpApi ships official SDKs (e.g., the Python client, with docs pointing to installing 'the library for your language') and explicitly supports AI-native workflows via LLM-optimized markdown output and an official MCP server for AI agents. The one caveat is that the flagship Python package is being deprecated in favor of a newer implementation, showing SDK churn. missing for 10: independent/hands-on validation of SDK quality across multiple languages, and clarity on the full breadth of language coverage beyond Python.

   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [github] “This package will soon be **deprecated** in favor of [serpapi-python](https://github.com/serpapi/serpapi-python). We recommend migrating to …”
   • [github] “This Python package is meant to scrape and parse search results from Google, Bing, Baidu, Yandex, Yahoo, Home Depot, eBay and more”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”
   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Exa
   Exa~partialclaimed6/10

   Exa's Websets API documents real-time HTTP callbacks ('webhooks') as items are added or enriched, giving AI-native users a way to subscribe to search/enrichment events rather than polling. However, this is scoped specifically to Websets and no broader webhook infrastructure (e.g., event types, signing/security docs, retries) is evidenced for other Exa products like plain search or Agent API. Missing for 10: platform-wide webhook documentation covering multiple event types, security/verification details, and independent/hands-on confirmation of webhook reliability.

   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [claimed-docs] “A Webset starts with a natural-language query and a target item count. Add criteria that every result must satisfy and enrichment fields to …”
   • [claimed-docs] “Find anything on the web, no matter how complex. Websets searches, verifies, and enriches results automatically.”

   proof ↗⚑ flag

   SerpApi—none0/10

   The evidence shows async search submission and a Searches Archive API for polling results, but no mention anywhere of webhook subscriptions or event push notifications. Missing for 10: any documented webhook endpoint, event subscription mechanism, or push-notification callback feature.

   • [claimed-docs] “Parameter defines the way you want to submit your search to SerpApi. It can be set to `false` (default) to open an HTTP connection and keep …”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Exa
   Exa~partialcommunity4/10

   Websets can enrich and verify search results with AI-generated additional data points (exa-docs-8, exa-docs-15, exa-docs-21), which is the closest analog to 'insights from data' in Exa's product, but this is about web search results rather than a user's own stored data/dashboard, and independent evidence shows enrichment is unreliable (exa-comm-2 shows failed data enrichment for price). Missing for 10: evidence of insight generation over a user's own uploaded/proprietary data set, dashboard-style analytics, or reliable enrichment accuracy corroborated independently.

   • [claimed-docs] “Give it a query like "agtech companies in the US that raised Series A" and it will search, verify each result against your criteria, and enr…”
   • [claimed-docs] “Find anything on the web, no matter how complex. Websets searches, verifies, and enriches results automatically.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [community] “Searched 'lucid air touring models available for sale under 20,000 miles' and tried to add a 'sale price' column, but did not get the price …”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi's evidence shows it as a raw search-data API/scraper with use-case pages suggesting users feed results into external AI/RAG pipelines, but there's no evidence the product itself generates AI insights or suggestions from a user's own data inside a dashboard or interface. The AI-SEO/GEO use case describes monitoring brand visibility manually, not built-in AI-generated insights.

   • [claimed-docs] “Find out how your content is being used in AI-generated answers on Google AI Mode. Monitor your brand's visibility and optimize your SEO str…”
   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Exa
   Exa~partialclaimed5/10

   Exa offers scheduled/monitoring searches ('Scheduled searches that surface new events on the web') and async webhook callbacks for Websets enrichment, which enable background automation for search/data-gathering tasks, but there's no evidence of a general-purpose automation/agent scheduler, workflow builder, or broader autonomous task execution beyond search/websets. missing for 10: details on automation setup UI/API, retry/monitoring controls, broader task types beyond search/enrichment, and independent confirmation these scheduled jobs run reliably.

   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [claimed-docs] “Find anything on the web, no matter how complex. Websets searches, verifies, and enriches results automatically.”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi offers an async request mode (submit now, retrieve later) and account-level 'Automatic Early Renewal', but there is no evidence of a scheduling/cron engine, webhooks, or any mechanism for users to configure recurring searches that run autonomously in the background without manual polling. missing for 10: scheduled/recurring search jobs, webhook/callback delivery, any 'automation' or monitoring dashboard for background runs.

   • [claimed-docs] “Parameter defines the way you want to submit your search to SerpApi. It can be set to `false` (default) to open an HTTP connection and keep …”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”
   • [claimed-docs] “You can set your plan to Automatic Early Renewal. It will trigger an early renewal once you've used all your searches.”

   proof ↗⚑ flag

3. ai-native userOperate the product with natural-language commands

   weight 2 · round to Exa
   Exa✓fullcommunity8/10

   Exa's core search API accepts natural-language queries directly (e.g. 'agtech companies in the US that raised Series A'), Websets are built from a natural-language query plus criteria, and Exa's MCP server lets AI assistants like Claude/Cursor/ChatGPT operate it purely via NL commands without code. This is well documented across docs and GitHub examples. missing for 10: independent hands-on verification that NL commands reliably map to correct results (community reports show mixed accuracy, e.g. missed price enrichment and slow/stuck verification), and no first-party benchmark of NL-command success rate.

   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [claimed-docs] “A Webset starts with a natural-language query and a target item count. Add criteria that every result must satisfy and enrichment fields to …”
   • [claimed-docs] “Give it a query like "agtech companies in the US that raised Series A" and it will search, verify each result against your criteria, and enr…”
   • [claimed-docs] “Complete setup guide for Exa MCP Server. Connect Claude Desktop, Cursor, VS Code, and 10+ AI assistants to Exa's web search, fetching, Exa A…”
   • [claimed-docs] “Connect ChatGPT, Codex, Claude, Grok, Cursor, and any other MCP client to Exa's web search, page fetching, Exa Agent, and Exa Connect tools.”
   • [github] “Find engineering leaders at AI infrastructure companies that raised a Series A or B in the last 6 months.”
   • [community] “Searched 'lucid air touring models available for sale under 20,000 miles' and tried to add a 'sale price' column, but did not get the price …”
   • [community] “I gave it a try and my first search got one match, 14 misses, and all other results are 'Verifying...' but it seems stuck (been minutes)... …”

   proof ↗⚑ flag

   SerpApi~partialprobed5/10

   SerpApi itself is a structured JSON API driven by explicit parameters (q, location, engine, etc.), not a natural-language command console, but its documented MCP server integration lets MCP-compatible AI agents (Claude, ChatGPT, Cursor) invoke it as a tool, effectively letting an AI-native user issue natural-language requests that the agent translates into SerpApi calls. Missing for 10: no first-party natural-language CLI/chat interface for the API itself, and no independent hands-on evidence of the MCP server's real-world reliability.

   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”
   • [claimed-docs] “You can use anything that you would use in a regular Google search. e.g. `inurl:`, `site:`, `intitle:`.”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to SerpApi
   Exa!disputedcontradicted4/10

   Exa's docs claim a 'Get Code' feature that generates a 'complete, tested integration snippet' in under a minute (exa-docs-11), and the JS SDK provides runnable code examples (exa-gh-1-5), but there's no evidence of a true interactive API reference (OpenAPI/Swagger endpoints all 404'd per exa-probe-3), and a hands-on reviewer found the generated cURL example in 'Get Code' to be 'demonstrably wrong' (exa-comm-4), directly contradicting the 'tested' claim. missing for 10: a genuine try-it-out API console, working/tested generated snippets, independent confirmation the code examples run correctly.

   • [claimed-docs] “it generates a complete, tested integration snippet tailored to your exact stack and use case in under a minute”
   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [community] “Tried the GitHub repo search feature: it was about 30/70 on finding the things I asked for. The cURL example in 'Get Code' was demonstrably …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://exa.ai/openapi.json, https://exa.ai/swagger.json, https://exa.ai/api/openapi.json, https://e…”

   proof ↗⚑ flag

   SerpApi~partialprobed5/10

   SerpApi has extensive documentation pages with parameter descriptions and code snippets (e.g., Python examples, script builder mentioned in serpapi-gh-7) and markdown-formatted docs for LLMs, but there is no evidence of an interactive, runnable API reference (e.g., a live 'try it' console or Swagger/OpenAPI explorer) — the openapi probe returned 404s across all candidate paths. missing for 10: an interactive in-browser API console/playground with runnable requests, an OpenAPI/Swagger spec, and independent confirmation that examples can be executed directly from the docs.

   • [github] “SerpApi provides a script builder to get you started quickly.”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”
   • [probe] “PROBE docs-md: HTTP 200 at https://serpapi.com/search-api.md --- title: "Google Search Engine Results API" description: "Scrape Google searc…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Exa—none0/10

   A direct probe for an OpenAPI/Swagger spec at all standard locations (openapi.json, swagger.json, etc.) returned 404s, and while Exa offers llms.txt and markdown doc indexes, these are documentation aids, not a machine-readable API schema (endpoints/params/types) that a buyer could import into tooling like Postman or codegen.

   • [probe] “PROBE openapi: all candidate paths 404 (https://exa.ai/openapi.json, https://exa.ai/swagger.json, https://exa.ai/api/openapi.json, https://e…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://exa.ai/llms.txt # Exa > Exa is a real-time knowledge index and retrieval platform built for AI agents. …”
   • [probe] “PROBE docs-md: HTTP 200 at https://exa.ai/docs/reference/search-api-guide.md > ## Documentation Index > Fetch the complete documentation ind…”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi provides docs in markdown (.md) and an llms.txt file for LLM consumption, but a direct probe for standard OpenAPI/Swagger spec locations (openapi.json, swagger.json, etc.) returned 404 on all candidates, and no other evidence pack item references a downloadable OpenAPI/Swagger spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [probe] “PROBE docs-md: HTTP 200 at https://serpapi.com/search-api.md --- title: "Google Search Engine Results API" description: "Scrape Google searc…”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Exa—none0/10

   No evidence pack item mentions API versioning scheme (e.g., v1/v2 endpoints) or any documented deprecation policy for older API versions; docs cover rate limits, pricing, and features but not version lifecycle management.

   ⚑ flag

   SerpApi—none0/10

   Evidence shows a client library (google-search-results-python) being deprecated in favor of a newer package, but there is no documentation of API versioning (e.g., v1/v2 endpoints) or a formal deprecation policy for the SerpApi service/API itself; an OpenAPI spec probe returned 404s. This is an applicable axis for an API product, but no evidence supports it being delivered.

   • [github] “This package will soon be **deprecated** in favor of [serpapi-python](https://github.com/serpapi/serpapi-python). We recommend migrating to …”
   • [github] “We recommend migrating to the newer implementation to ensure continued support and access to the latest features and improvements.”
   • [github] “This package will soon be deprecated in favor of serpapi-python. We recommend migrating to the newer implementation to ensure continued supp…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Exa
   Exa~partialcommunity7/10

   Exa's Websets product is explicitly built for bulk operations — 'build large lists', verify and enrich every match against criteria, async list building/enrichment, and scheduled searches for new items (exa-docs-7,8,9,10,15,28). However, hands-on community reports show real gaps: missing enrichment data (price columns), 'Verifying...' stuck states, and inconsistent match rates (exa-comm-2,3,4), indicating the bulk pipeline doesn't always complete reliably at scale. Missing for 10: independent benchmarks confirming reliability at large scale, and resolution of the noted enrichment/verification failures.

   • [claimed-docs] “You can also build websets visually in the [Dashboard](/docs/websets/dashboard/get-started), no code required.”
   • [claimed-docs] “Give it a query like "agtech companies in the US that raised Series A" and it will search, verify each result against your criteria, and enr…”
   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [claimed-docs] “Find anything on the web, no matter how complex. Websets searches, verifies, and enriches results automatically.”
   • [claimed-docs] “A Webset starts with a natural-language query and a target item count. Add criteria that every result must satisfy and enrichment fields to …”
   • [community] “Searched 'lucid air touring models available for sale under 20,000 miles' and tried to add a 'sale price' column, but did not get the price …”
   • [community] “I gave it a try and my first search got one match, 14 misses, and all other results are 'Verifying...' but it seems stuck (been minutes)... …”
   • [community] “Tried the GitHub repo search feature: it was about 30/70 on finding the things I asked for. The cURL example in 'Get Code' was demonstrably …”

   proof ↗⚑ flag

   SerpApi—none0/10

   The evidence pack covers single-search parameters, formats, caching, and archive retrieval, but nothing indicates a bulk/batch API endpoint for submitting or processing many search items at once. Bulk operations are a plausible feature for a search-API product, but no documentation or examples confirm this capability exists.

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Exa
   Exa~partialclaimed5/10

   Exa's Websets support scheduled searches that surface new events and real-time HTTP callbacks (webhooks) when items are added or enriched, which functions as a basic event-triggered automation mechanism. However, there's no evidence of a full rule-definition system (conditional logic, multi-step actions, or an automation builder) — missing for 10: user-defined conditional rules, multi-action workflows, and any hands-on/independent confirmation that scheduled searches or webhooks work reliably in practice.

   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [claimed-docs] “Async deep research, list building, and enrichment.”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi's evidence pack shows only search scraping APIs, caching, and plan billing automation (Automatic Early Renewal), none of which let a user define custom rules that trigger arbitrary actions on events. No webhook, alerting, or rule-engine capability is documented.

   • [claimed-docs] “You can set your plan to Automatic Early Renewal. It will trigger an early renewal once you've used all your searches.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Exa
   Exa~partialclaimed5/10

   Exa's pricing docs explicitly mention "Scheduled searches that surface new events on the web" and "Async deep research, list building, and enrichment," indicating recurring/scheduled job capability tied to Websets, but there is no detailed documentation of how to configure recurrence, cron-like scheduling, or workflow orchestration, and no independent/hands-on evidence confirming this works reliably. missing for 10: detailed docs on setting up recurring schedules, examples of scheduled workflow configuration, independent verification of scheduled jobs working as claimed.

   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”

   proof ↗⚑ flag

   SerpApi—none0/10

   No evidence of any scheduling, cron-like, or recurring job/workflow feature in SerpApi's docs or integrations—only ad-hoc synchronous/async single searches and a temporary results cache/archive API are documented.

   • [claimed-docs] “Parameter defines the way you want to submit your search to SerpApi. It can be set to `false` (default) to open an HTTP connection and keep …”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”
   • [github] “The search results are stored in a temporary cache. The previous search can be retrieved from the cache for free.”

   proof ↗⚑ flag

Citation fidelity

1. developerRely on results carrying canonical URLs, titles, and published dates so my app can cite sources accurately

   weight 3 · round to Exa
   Exa~partialclaimed5/10

   Exa's API supports date filtering (startPublishedDate) and domain/path targeting, and its answer/citation feature returns sourced URLs, implying results carry URLs and dates, but no evidence pack item explicitly documents the search result schema (title, canonical url, publishedDate fields) or addresses duplicate/canonicalization handling for citation accuracy. Missing for 10: explicit schema documentation showing title/url/publishedDate fields returned per result, evidence of canonical URL deduplication, and independent confirmation that dates/titles are consistently accurate.

   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”
   • [github] “Get answers with citations const { answer } = await exa.answer("What is the capital of France?");”
   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [claimed-docs] “Exa Contents returns clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically.”

   proof ↗⚑ flag

   SerpApi—none0/10

   The evidence pack describes SerpApi's general search/JSON output, formats, and MCP integration, but never documents the structure of returned result fields (e.g., canonical URL, title, published date) that a developer would rely on for citations. Missing for 10: explicit schema documentation of link/title/date fields, examples showing these fields populated, or independent verification of their accuracy/canonicality.

   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”
   • [claimed-docs] “Our Google News API allows you to scrape results from the Google News search page.”
   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”

   proof ↗⚑ flag

2. data engineerRead a documented stance on robots.txt, content licensing, and permitted use of results

   weight 2 · round to SerpApi
   Exa—none0/10

   No first-party documentation addresses robots.txt policy, content licensing, or permitted use of search results; the only related evidence is a community tweet alleging Exa ignores robots.txt when indexing (exa-comm-9), which is a complaint, not a documented policy. Since Exa never publishes an explicit stance, this is an unmet, applicable axis rather than a vendor claim being disputed.

   • [community] “Exa.ai is indexing personal site data ignoring robots.txt”

   proof ↗⚑ flag

   SerpApi~partialcommunity5/10

   SerpApi publishes a clear stance on legality of scraping/parsing via its 'U.S. Legal Shield' (covering use of data as long as it's not illegal, with $2M coverage on Production plans), and community discussion corroborates this legal defense framing. However, there is no explicit documented stance on robots.txt compliance or content licensing/copyright of scraped results—only the broad legality/permitted-use angle is covered. Missing for 10: explicit robots.txt policy statement, explicit content-licensing/copyright guidance, independent verification of legal shield's real-world enforceability.

   • [claimed-docs] “Our U.S. Legal Shield covers the scraping and parsing of search engine data, as long as your use of the data or service is not illegal.”
   • [claimed-docs] “Included with the Production Plan and above, with up to $2 million in coverage.”
   • [community] “I used Serp via API many moons ago. The most interesting part of the company imo is their legal defense of different plans... 'Our U.S. Lega…”
   • [community] “I'm not sure of the legality but I definitely appreciate their product. From what I see SerpApi is really just providing a machine interface…”

   proof ↗⚑ flag

Ai consumption

1. ai-native userHave an agent run a multi-step research flow — search, extract contents, and synthesize — through one API

   weight 2 · round to Exa
   Exa✓fullcommunity8/10

   Exa's Agent API and Contents/Answer endpoints explicitly support a single-API multi-step flow: search, extract clean content, and synthesize a grounded answer with citations (exa-docs-25, exa-docs-26, exa-docs-24, exa-gh-3/8), and the search endpoint can even return contents inline (exa-docs-22, exa-docs-35). Community feedback shows mixed real-world reliability (e.g., stuck verification, incomplete enrichment) which tempers confidence. Missing for 10: independent hands-on validation of the full search→extract→synthesize loop working end-to-end without manual chaining, and clearer benchmarking of synthesis quality.

   • [claimed-docs] “Use iterative search, reasoning, and grounded synthesis for complex research tasks.”
   • [claimed-docs] “Enrich entities, build large lists, and run deep research from a single API with built in structured results and web citation”
   • [claimed-docs] “Exa Contents returns clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically.”
   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [github] “const { answer } = await exa.answer("What is the capital of France?");”
   • [github] “Get answers with citations const { answer } = await exa.answer("What is the capital of France?");”
   • [claimed-docs] “All contents features are also available in Exa Search for returned URLs, at no extra charge up to 10 results per search”
   • [community] “I gave it a try and my first search got one match, 14 misses, and all other results are 'Verifying...' but it seems stuck (been minutes)... …”

   proof ↗⚑ flag

   SerpApi~partialprobed5/10

   SerpApi provides search results (JSON/markdown) and an MCP integration so agents can call it as a search tool, plus RAG use-case docs showing search data feeding into AI pipelines, but it is fundamentally a single-purpose search-scraping API — it does not itself perform multi-step 'extract full page contents' or 'synthesize' steps within one API call; those would need to be orchestrated by the agent/other tools. missing for 10: evidence of a single API call or endpoint that chains search + full-content extraction + synthesis, native content-extraction (beyond search snippets) capability, and independent hands-on proof of a full multi-step research flow working end-to-end.

   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”
   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”

   proof ↗⚑ flag

Page contents

1. developerRetrieve full page text or markdown for results, not just snippets

   weight 3 · round to Exa
   Exa✓fullclaimed7/10

   Exa's Contents API explicitly returns 'clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically,' and this full-content extraction is also bundled into Search results (up to 10 per search) rather than being limited to snippets, with a token-efficient full-text mode described as '10x token efficient extracts.' Missing for 10: explicit documentation of markdown as an output format option, and independent/hands-on developer confirmation of full-text/markdown extraction quality.

   • [claimed-docs] “Exa Contents returns clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically.”
   • [claimed-docs] “All contents features are also available in Exa Search for returned URLs, at no extra charge up to 10 results per search”
   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [claimed-docs] “10x token efficient extracts of only the relevant tokens from a webpage. 4000 characters recommended.”
   • [claimed-docs] “Specialized model trained to extract the most relevant excerpts from the web”

   proof ↗⚑ flag

   SerpApi~partialclaimed6/10

   SerpApi supports an `md` output format that returns markdown-formatted search results optimized for LLMs/AI agents, and a dedicated markdown-output feature serving any search result as clean markdown, plus raw HTML output — but this is markdown/HTML of the SERP results themselves, not full page text extraction of the underlying linked pages. missing for 10: evidence of extracting full text/markdown of the destination web pages (not just search result snippets/HTML/markdown), and independent hands-on verification of markdown output quality.

   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”
   • [claimed-docs] “output to `json` (default)... `html` to get the raw HTML retrieved, or `md` to get a markdown-formatted version optimized for LLMs and AI ag…”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

2. developerGet structured output matching a JSON schema I define

   weight 2 · round to Exa
   Exa✓fullclaimed7/10

   Exa's docs explicitly describe an `output_schema` parameter usable with any search type to extract structured JSON from results, and the GitHub SDK documents concrete schema constraints (max nesting depth 2, max 10 properties) confirming real enforcement of a JSON schema. Missing for 10: independent/hands-on confirmation that schema-constrained output works reliably in practice and richer documentation of schema validation/error handling.

   • [claimed-docs] “Use `output_schema` with any search type to extract structured JSON from search results”
   • [github] “For type: "object", search currently enforces: max nesting depth: 2, max total properties: 10”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi returns structured JSON per endpoint and lets developers pick output format (json/html/md) or filter fields, but there is no evidence of a mechanism to supply a custom JSON schema that the response is validated/shaped against.

   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”
   • [claimed-docs] “Parameter defines the fields you want to include in the output, reducing payload size for faster response.”
   • [claimed-docs] “output to `json` (default)... `html` to get the raw HTML retrieved, or `md` to get a markdown-formatted version optimized for LLMs and AI ag…”

   proof ↗⚑ flag

3. data engineerCrawl subpages or entire sites starting from a search result

   weight 1 · round to Exa
   Exa~partialclaimed5/10

   Exa's Contents API and domain-scoping options (includeDomains/excludeDomains with path prefixes, 'limit results to an entire domain or a specific section of a site') let engineers restrict search/content retrieval to a site or subsection, and Exa Contents cleanly extracts page content including JS-rendered pages and PDFs, which supports basic multi-page extraction from a domain. However there is no explicit documentation of a dedicated 'crawl subpages from a search result' or recursive site-crawl parameter, and no hands-on evidence of crawling an entire site tree. Missing for 10: explicit subpage/recursive-crawl API parameter, and independent verification that full-site crawling from a single result works reliably.

   • [claimed-docs] “Limit results to an entire domain or a specific section of a site.”
   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes such”
   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes”
   • [claimed-docs] “Exa Contents returns clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically.”
   • [claimed-docs] “All contents features are also available in Exa Search for returned URLs, at no extra charge up to 10 results per search”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi's documented capability is restricted to scraping structured search engine results pages (Google, Bing, News, Ads, Flights, etc.); there is no evidence of any subpage/site-crawling capability that would follow a search result link to fetch and traverse the destination site's pages. All docs and GitHub references describe SERP scraping only, not general web crawling. Missing for 10: any documentation or code showing SerpApi fetching/crawling pages beyond the search results themselves, a crawl depth/breadth parameter, or site-wide crawling feature.

   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”
   • [claimed-docs] “Our Google News API allows you to scrape results from the Google News search page.”
   • [github] “This Python package is meant to scrape and parse search results from Google, Bing, Baidu, Yandex, Yahoo, Home Depot, eBay and more”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

Query filters

1. developerRestrict or exclude specific domains from my search results

   weight 2 · round to Exa
   Exa✓fullclaimed9/10

   Exa's API explicitly supports both includeDomains and excludeDomains parameters (accepting domains and path prefixes), documented in the search API guide and demonstrated in the exa-js GitHub README with a concrete includeDomains example. This directly delivers domain restriction/exclusion for developers via a first-party, well-documented parameter with SDK code example. Missing for 10: no independent/hands-on confirmation specifically of excludeDomains behavior in practice.

   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes such”
   • [claimed-docs] “Limit results to an entire domain or a specific section of a site.”
   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes”
   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”

   proof ↗⚑ flag

   SerpApi~partialclaimed5/10

   SerpApi supports Google search operators like 'site:' which can be used to include or exclude specific domains (e.g., site:example.com or -site:example.com), giving developers a workaround to restrict/exclude domains, but there's no dedicated first-class parameter or documented feature specifically for domain inclusion/exclusion filtering. missing for 10: a documented dedicated domain-restrict/exclude parameter, explicit examples of exclude-domain usage, and independent confirmation this works reliably across engines.

   • [claimed-docs] “You can use anything that you would use in a regular Google search. e.g. `inurl:`, `site:`, `intitle:`.”

   proof ↗⚑ flag

2. developerRead per-result relevance scores to threshold what enters my pipeline

   weight 1 · round drawn
   Exa—none0/10

   No evidence pack item mentions a per-result relevance/similarity score field, score-based thresholding, or any API parameter to filter/sort results by a numeric relevance score. This is a reasonable axis for a search API, but nothing in docs, SDK, or community evidence documents such a score being returned or usable for pipeline thresholding.

   ⚑ flag

   SerpApi—none0/10

   No evidence in the pack mentions relevance scores or a scoring/confidence field on results that a developer could threshold on; SerpApi's docs describe fields like format, topic tokens, and result fields but nothing about per-result relevance scoring for pipeline filtering.

   ⚑ flag

Freshness

1. data engineerGet fresh results with date-range and recency filters backed by a frequently updated index

   weight 3 · round to Exa
   Exa✓fullprobed7/10

   Exa's API supports date-range filtering (startPublishedDate/endPublishedDate) as shown in the JS SDK example, and Exa positions itself as a 'real-time knowledge index' with scheduled searches that surface new events on the web, indicating recency-focused indexing and monitoring capabilities. missing for 10: explicit documentation of crawl/index refresh frequency or independent benchmarks validating recency/freshness claims beyond marketing language.

   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://exa.ai/llms.txt # Exa > Exa is a real-time knowledge index and retrieval platform built for AI agents. …”
   • [claimed-docs] “Async deep research, list building, and enrichment.”

   proof ↗⚑ flag

   SerpApi—none0/10

   The evidence shows SerpApi is a real-time scraping API with caching (1h cache) and mentions of 'real-time JSON API' claims, but nothing in the pack documents explicit date-range or recency filter parameters (e.g., time-window search flags) or describes how frequently the underlying index itself is refreshed. Without concrete documentation of such filters, the axis is unaddressed by the evidence provided.

   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [claimed-docs] “Cache expires after 1h. Cached searches are free, and are not counted towards your searches per month.”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”

   proof ↗⚑ flag

2. data engineerQuery dedicated verticals like news, images, or finance through specific endpoints or category filters

   weight 2 · round to SerpApi
   Exa~partialclaimed4/10

   Exa's docs mention custom indexes for people, companies, and publications and domain/date filtering (includeDomains, startPublishedDate), suggesting some vertical-style filtering, but there is no explicit evidence of dedicated endpoints or category filters for news, images, or finance specifically. Missing for 10: explicit 'category' parameter documentation covering news/images/finance verticals, examples of querying these specific verticals, and independent confirmation of vertical-specific accuracy.

   • [claimed-docs] “Exa has custom indexes of 1B+ people, 50M+ companies, 350M+ publications (research papers, preprints, and more), and more.”
   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”
   • [claimed-docs] “Limit results to an entire domain or a specific section of a site.”

   proof ↗⚑ flag

   SerpApi✓fullclaimed9/10

   SerpApi ships dedicated endpoints for specific verticals such as Google News (with topic_token category filters) and other specialized APIs like Google Flights and Google Ads Transparency Center, alongside the core search API; images vertical is implied by the broader engine family though not explicitly documented in this pack. Evidence includes first-party docs for parameters and topic filtering plus API listings confirming multiple vertical-specific endpoints. Missing for 10: explicit documentation/example of an Images-specific endpoint and independent hands-on confirmation of vertical query results.

   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”
   • [claimed-docs] “Parameter defines the Google News topic token. It is used for accessing the news results for a specific topic (e.g., "World", "Business", "T…”
   • [claimed-docs] “Parameter defines the Google News topic token. It is used for accessing the news results for a specific topic”
   • [claimed-docs] “Our Google News API allows you to scrape results from the Google News search page.”
   • [claimed-docs] “Use SerpApi's Google Flights API to scrape Google Flights information.”
   • [claimed-docs] “Use SerpApi's Google Ads Transparency Center API to scrape Ads information display on Google.”
   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”

   proof ↗⚑ flag

Targeting

1. data engineerLocalize results by country, language, or location parameters

   weight 2 · round to SerpApi
   Exa—none0/10

   The evidence pack documents domain include/exclude filters and date filters (e.g., includeDomains, startPublishedDate) but contains no mention of country, language, or geographic location search parameters anywhere in Exa's API or docs. Missing for 10: any documented country/locale/language filter parameter, geo-targeting options, or localization examples.

   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes such”
   • [claimed-docs] “Limit results to an entire domain or a specific section of a site.”
   • [claimed-docs] “Both `includeDomains` and `excludeDomains` accept domains, path prefixes”
   • [github] “includeDomains: ["nasa.gov", "space.com"], startPublishedDate: "2024-01-01",”

   proof ↗⚑ flag

   SerpApi✓fullclaimed8/10

   SerpApi docs and SDK examples show explicit location/language parameters (e.g. 'location' recommended at city level, 'gl'/search origin parameter) and a code example passing 'location':'Austin,Texas' with a helper to disambiguate locations. This directly supports localization by country/language/location for a data engineer's search queries. Missing for 10: explicit documentation/example of the 'hl' (language) and 'gl' (country) parameters together with independent hands-on confirmation of localized result differences.

   • [claimed-docs] “It is recommended to specify location at the city level in order to simulate a real user’s search.”
   • [claimed-docs] “Parameter defines from where you want the search to originate.”
   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [github] “This prints the first 3 locations matching Austin (Texas, Texas, Rochester).”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Exa~partialprobed5/10

   Exa's docs show that Websets, its dashboard feature, can be built visually with 'no code required' (exa-docs-7/29) and that the same functionality is exposed via the Websets API (exa-docs-8/15/28), suggesting rough UI/API parity for that feature, and search/contents/answer are all API-first with UI as a thin layer (exa-comm-7). However there is no explicit documentation stating full feature parity between the dashboard and API, and no OpenAPI spec was found (exa-probe-3) to verify completeness. Missing for 10: an explicit parity statement or changelog showing every UI capability (e.g. dashboard analytics, billing controls, websets monitoring UI) is mirrored in the API, and independent confirmation that no UI-only features exist.

   • [claimed-docs] “You can also build websets visually in the [Dashboard](/docs/websets/dashboard/get-started), no code required.”
   • [claimed-docs] “Give it a query like "agtech companies in the US that raised Series A" and it will search, verify each result against your criteria, and enr…”
   • [claimed-docs] “Find anything on the web, no matter how complex. Websets searches, verifies, and enriches results automatically.”
   • [claimed-docs] “A Webset starts with a natural-language query and a target item count. Add criteria that every result must satisfy and enrichment fields to …”
   • [claimed-docs] “You can also build websets visually in the Dashboard, no code required.”
   • [community] “Exa was originally just a search engine. They try to hide it these days to promote Websets, but you can still use it at exa.ai/search.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://exa.ai/openapi.json, https://exa.ai/swagger.json, https://exa.ai/api/openapi.json, https://e…”

   proof ↗⚑ flag

   SerpApi~partialprobed5/10

   Evidence strongly documents that SerpApi's core scraping functionality (Google, News, Ads, Flights, etc.) and output formats (json/html/md) are fully accessible via the API and various language libraries, and even account-level settings like ZeroTrace Mode and Automatic Early Renewal are described as configurable in docs. However, there is no evidence of an API/endpoint for programmatically managing billing, plan changes, or dashboard analytics (api-metrics page appears to be a UI-only dashboard), and no OpenAPI spec was found (404s), leaving unclear whether account/administrative actions in the UI have full API parity. missing for 10: API endpoints for billing/plan management, confirmation that dashboard-only features (api-metrics, account settings) have API equivalents, and independent verification of full UI-API parity.

   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”
   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”
   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”
   • [claimed-docs] “You can set your plan to Automatic Early Renewal. It will trigger an early renewal once you've used all your searches.”
   • [claimed-docs] “Monitor SerpApi's live API success rates and response times.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to SerpApi
   Exa—none0/10

   Exa's docs describe search, contents, websets, and MCP integration, but nowhere is there evidence of a data export feature (e.g., bulk export of websets/results in open formats like CSV/JSON) or account data portability for users to 'take their data and leave'. This is a fair axis for a data platform, but no evidence supports it.

   ⚑ flag

   SerpApi~partialclaimed3/10

   SerpApi's outputs (search results) are always available in open formats—JSON, HTML, or markdown—and a Searches Archive API lets users retrieve past results, while ZeroTrace mode means the vendor doesn't retain data at all. But there is no documented bulk 'export all my account data and leave' feature, account-data portability tool, or data-deletion/export workflow beyond retrieving individual past search results. missing for 10: a documented bulk account-data export mechanism, explicit data portability/deletion tooling, and independent confirmation that users can fully extract historical usage/account data before leaving.

   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”
   • [claimed-docs] “output to `json` (default)... `html` to get the raw HTML retrieved, or `md` to get a markdown-formatted version optimized for LLMs and AI ag…”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”
   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Exa
   Exa~partialclaimed3/10

   Exa's core search/retrieval engine and backend are proprietary SaaS; only peripheral components are open — the Exa MCP server is explicitly stated to be 'open source and available on GitHub' (exa-docs-31) and the JS client SDK lives on GitHub (exa-gh-1), but these are thin client/integration layers, not the product's actual search index or ranking source. missing for 10: no open license for the core search engine/index itself, no repository or license file covering the main product, no independent confirmation of license terms for the open pieces.

   • [claimed-docs] “No API key is required to get started. Exa MCP is open source and available on GitHub.”
   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [claimed-docs] “Exa MCP connects AI assistants to Exa’s search capabilities, including web search, code search, Exa Agent, and Exa Connect.”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi is a closed, paid SaaS API; only client-side SDK wrappers (e.g. google-search-results-python) are on GitHub, and there is no evidence the core search/scraping service or API source is released under an open license — the wrappers are thin API clients, not 'the product' itself.

   • [github] “This Python package is meant to scrape and parse search results from Google, Bing, Baidu, Yandex, Yahoo, Home Depot, eBay and more”
   • [github] “This Python package is meant to scrape and parse search results from Google, Bing, Baidu, Yandex, Yahoo, Home Depot, eBay and more, using Se…”
   • [github] “This package will soon be **deprecated** in favor of [serpapi-python](https://github.com/serpapi/serpapi-python). We recommend migrating to …”

   proof ↗⚑ flag

Pricing clarity

1. developerRead documented rate limits and concurrency caps with a self-serve upgrade path

   weight 2 · round to SerpApi
   Exa~partialclaimed4/10

   Exa has a dedicated rate-limits doc page (exa-docs-16) confirming default per-endpoint limits exist, and self-serve signup/API-key provisioning with credits is documented (exa-docs-33, exa-docs-34), implying a self-serve path to get and fund an account. However, no evidence shows actual numeric rate limits, concurrency caps, or a documented tier-based upgrade mechanism (e.g., paid plan comparison unlocking higher throughput). Missing for 10: concrete rate-limit/concurrency numbers, documented upgrade tiers and how limits scale with them, and any independent confirmation of these limits in practice.

   • [claimed-docs] “Our API endpoints have default rate limits to ensure reliable performance for all users.”
   • [claimed-docs] “A single command creates an Exa account and syncs an API key into your project.”
   • [claimed-docs] “$20 credits on sign-up with $10 credits every month. No payment method required”

   proof ↗⚑ flag

   SerpApi~partialclaimed5/10

   Pricing page shows tiered plans with searches-per-month caps (e.g., 250/month free tier) and a self-serve 'Automatic Early Renewal' upgrade mechanism triggered once searches are used up, giving a self-serve path to more capacity. However, there is no explicit documentation of concurrency caps (simultaneous request limits) or per-second/per-minute rate limits, which developers typically need for building resilient clients. Missing for 10: explicit concurrency/rate-limit numbers (requests per second/minute), documented error/backoff behavior when limits are hit, and independent confirmation of self-serve upgrade flow beyond pricing page claims.

   • [claimed-docs] “Free $ 0 / month 250 searches per month”
   • [claimed-docs] “You can set your plan to Automatic Early Renewal. It will trigger an early renewal once you've used all your searches.”
   • [claimed-docs] “Included with the Production Plan and above, with up to $2 million in coverage.”

   proof ↗⚑ flag

2. developerPrototype against the API on a free tier or free credits

   weight 2 · round drawn
   Exa✓fullcommunity8/10

   Exa's pricing docs explicitly state $20 free credits on sign-up plus $10/month recurring credits with no payment method required, directly enabling free prototyping, and community evidence confirms users signing up for trial accounts and testing the API without payment friction (exa-comm-1). missing for 10: no independent long-term verification of ongoing $10/month credit renewal or explicit free-tier rate limits beyond generic rate-limit doc.

   • [claimed-docs] “$20 credits on sign-up with $10 credits every month. No payment method required”
   • [claimed-docs] “A single command creates an Exa account and syncs an API key into your project.”
   • [community] “Signed up for a trial account and I'm pretty impressed with the search API (haven't used Websets yet but looks cool). Suggested adding a 'cr…”
   • [claimed-docs] “Our API endpoints have default rate limits to ensure reliable performance for all users.”

   proof ↗⚑ flag

   SerpApi✓fullclaimed8/10

   SerpApi's pricing page explicitly documents a free tier of 250 searches/month at $0, and cached searches are also free and don't count against quota, giving developers a clear path to prototype without payment; the free plan is easy to sign up for via API key per the docs/GitHub examples. Missing for 10: no independent/community confirmation of the free-tier signup experience or its limitations in practice.

   • [claimed-docs] “Free $ 0 / month 250 searches per month”
   • [claimed-docs] “Cache expires after 1h. Cached searches are free, and are not counted towards your searches per month.”
   • [github] “search = GoogleSearch({"q": "coffee", "location": "Austin,Texas", "api_key": "<your secret api key>"}) result = search.get_dict()”
   • [claimed-docs] “Install the library for your language and use your API key to start searching”

   proof ↗⚑ flag

3. developerSee clear per-request or per-credit pricing without talking to sales

   weight 3 · round to SerpApi
   Exa~partialclaimed6/10

   Exa's pricing page (exa-docs-34) shows self-serve credit-based pricing ($20 signup credit, $10/month, no payment method required) and a dedicated /docs/reference/pricing page exists (exa-docs-9, exa-docs-10) listing feature tiers, indicating pricing is public and requires no sales contact. However, the evidence pack doesn't show a detailed per-endpoint/per-request cost table or explicit dollar-per-call rates, so the granularity a developer needs to estimate exact costs is unclear. Missing for 10: explicit per-request/per-token cost breakdown, confirmation that all endpoints (websets, agent, MCP) are covered in the same public pricing page, independent confirmation that pricing is fully self-serve without enterprise gating.

   • [claimed-docs] “$20 credits on sign-up with $10 credits every month. No payment method required”
   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”

   proof ↗⚑ flag

   SerpApi✓fullcommunity7/10

   SerpApi publishes a public pricing page with a free tier (250 searches/month), paid plans, and automatic early renewal, all discoverable without sales contact (serpapi-docs-6, serpapi-docs-26). Community discussion on HN also references SerpApi's plan structure without any indication of a sales-gated model. Missing for 10: a full per-request/credit cost table across all paid tiers and confirmation that no enterprise tier requires contacting sales.

   • [claimed-docs] “Free $ 0 / month 250 searches per month”
   • [claimed-docs] “You can set your plan to Automatic Early Renewal. It will trigger an early renewal once you've used all your searches.”
   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”
   • [community] “I used Serp via API many moons ago. The most interesting part of the company imo is their legal defense of different plans... 'Our U.S. Lega…”

   proof ↗⚑ flag

Scale throughput

1. data engineerSubmit batched or asynchronous jobs for high-volume query workloads

   weight 2 · round to Exa
   Exa✓fullclaimed7/10

   Exa's docs describe Websets for async list-building/enrichment at scale, async deep research, scheduled searches, and webhook callbacks for job status — directly supporting asynchronous high-volume workloads, backed by rate-limit documentation for query volume management. Missing for 10: an explicit bulk/batch query submission endpoint (vs. Websets-specific async jobs), and independent/hands-on benchmarks confirming reliable performance at high volume.

   • [claimed-docs] “Async deep research, list building, and enrichment.”
   • [claimed-docs] “Scheduled searches that surface new events on the web.”
   • [claimed-docs] “Get real-time HTTP callbacks as items are added or enriched”
   • [claimed-docs] “A Webset starts with a natural-language query and a target item count. Add criteria that every result must satisfy and enrichment fields to …”
   • [claimed-docs] “Our API endpoints have default rate limits to ensure reliable performance for all users.”

   proof ↗⚑ flag

   SerpApi~partialclaimed7/10

   SerpApi explicitly supports async submission via the `async` parameter (submit now, retrieve later) plus a Searches Archive API to fetch async results later, which directly enables asynchronous high-volume workflows [serpapi-docs-9][serpapi-docs-14]. However, there is no explicit documentation of a dedicated batch-job endpoint or bulk-submission API for large query sets. Missing for 10: dedicated batch/bulk submission endpoint documentation, rate/throughput guarantees for high-volume async workloads, and independent confirmation of async reliability at scale.

   • [claimed-docs] “Parameter defines the way you want to submit your search to SerpApi. It can be set to `false` (default) to open an HTTP connection and keep …”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Exa—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location options for Exa's API, MCP server, or Websets; this is an applicable privacy axis for an AI-native data/search platform but no documentation addresses it.

   ⚑ flag

   SerpApi—none0/10

   No evidence SerpApi offers region/residency choice for data storage; there's a ZeroTrace Mode that avoids storing data at all, but nothing about selecting a storage region or jurisdiction for retained data.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round to SerpApi
   Exa—none0/10

   The evidence pack contains no documentation, policy statement, or setting related to opting out of data being used for AI model training; the only tangential item concerns Exa scraping third-party websites (ignoring robots.txt), not user-submitted data protection. No opt-out mechanism, privacy policy language, or enterprise data-handling guarantee is present.

   ⚑ flag

   SerpApi~partialclaimed4/10

   SerpApi doesn't explicitly address AI-training use of customer data, but its ZeroTrace Mode claims that once a search completes, no search parameters/files/data are stored, which would preclude such data being used to train models — an indirect but relevant privacy control. missing for 10: explicit AI-training data-use policy/statement, opt-out mechanism specifically for AI training, and independent verification of ZeroTrace Mode's scope.

   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to SerpApi
   Exa—none0/10

   No evidence pack items address data retention policies, deletion controls, or privacy/data-handling settings for user data or query history; one community post alleges Exa ignores robots.txt when indexing web content, which is unrelated to user data retention controls. Missing for 10: any documentation of data retention periods, user-initiated deletion/export mechanisms, or privacy controls over stored queries/results.

   ⚑ flag

   SerpApi~partialclaimed5/10

   SerpApi documents a 'ZeroTrace Mode' that stops storage of search parameters/files/data, giving users some control over data retention, and mentions a temporary 1h cache and a Searches Archive API for retrieving stored results. However, there's no documentation of a general data-deletion mechanism, retention policy for non-ZeroTrace plans, or user-initiated deletion of historical searches/account data. missing for 10: explicit deletion/export controls for stored account data, retention policy details for standard (non-ZeroTrace) plans, independent confirmation that ZeroTrace behaves as claimed.

   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”
   • [claimed-docs] “Cache expires after 1h. Cached searches are free, and are not counted towards your searches per month.”
   • [claimed-docs] “you'll need to use our Searches Archive API to retrieve your results”
   • [github] “The search results are stored in a temporary cache. The previous search can be retrieved from the cache for free.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round to SerpApi
   Exa—none0/10

   No evidence in the pack addresses telemetry, usage tracking, or opt-out settings for Exa; there's even a community report of Exa itself indexing data disregarding robots.txt, but nothing about the product providing an opt-out for tracking of its own users.

   ⚑ flag

   SerpApi~partialclaimed4/10

   SerpApi's ZeroTrace Mode lets users prevent storage of search parameters/data ('once a search completes, it's as if it never happened'), which is adjacent to a telemetry/usage-tracking opt-out but is framed around search data retention rather than explicit telemetry or usage analytics collection. No documentation addresses opting out of product usage telemetry (e.g., client library analytics, dashboard tracking) specifically. Missing for 10: explicit telemetry/usage-tracking opt-out documentation, evidence covering the SDK/API client's own telemetry behavior, and independent confirmation that ZeroTrace disables all tracking beyond search data.

   • [claimed-docs] “With ZeroTrace Mode enabled, we don't store your search parameters, files, or data. Once a search completes, it's as if it never happened.”

   proof ↗⚑ flag

Ai consumption

1. ai-native userPlug the API into an agent as a ready-made tool, with function-calling schemas and agent-framework integrations designed for direct tool-call consumption

   weight 3 · round drawn
   Exa✓fullprobed8/10

   Exa ships an official JS/TS SDK with `webSearch()` designed explicitly for use as a tool in OpenAI/Anthropic agent loops, plus an open-source MCP server connecting Claude Desktop, Cursor, VS Code, ChatGPT, Codex, Grok and other MCP clients, and structured output_schema/JSON extraction for direct tool-call consumption. missing for 10: no official OpenAI/Anthropic function-calling JSON schema published directly (only inferred via SDK helper), no independent hands-on validation of agent-framework integration reliability, and no public OpenAPI spec (probe returned 404s).

   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop. Call `webSearch()` with no arguments to get Exa's recommended settings for ag…”
   • [github] “Use Exa as a `web_search` tool in an OpenAI or Anthropic loop.”
   • [claimed-docs] “Complete setup guide for Exa MCP Server. Connect Claude Desktop, Cursor, VS Code, and 10+ AI assistants to Exa's web search, fetching, Exa A…”
   • [claimed-docs] “Exa MCP connects AI assistants to Exa’s search capabilities, including web search, code search, Exa Agent, and Exa Connect.”
   • [claimed-docs] “Connect ChatGPT, Codex, Claude, Grok, Cursor, and any other MCP client to Exa's web search, page fetching, Exa Agent, and Exa Connect tools.”
   • [claimed-docs] “No API key is required to get started. Exa MCP is open source and available on GitHub.”
   • [claimed-docs] “Use `output_schema` with any search type to extract structured JSON from search results”
   • [github] “For type: "object", search currently enforces: max nesting depth: 2, max total properties: 10”
   • [probe] “official MCP server documented at https://exa.ai/docs/reference/exa-mcp”
   • [claimed-docs] “Exa skills teach coding agents how to search, retrieve content, and build with Exa's APIs.”

   proof ↗⚑ flag

   SerpApi✓fullprobed8/10

   SerpApi documents an official MCP server (serpapi-mcp) enabling any MCP-compatible agent (Claude, ChatGPT, Cursor) to call it as a web search tool, plus markdown-optimized output designed for LLM/agent consumption and llms.txt/docs.md endpoints for agent discoverability. missing for 10: no published OpenAPI/function-calling JSON schema (openapi.json probes 404), and no independent hands-on report of agent-framework integration success beyond vendor docs.

   • [claimed-docs] “The MCP integration allows any MCP-compatible AI agent (Claude, ChatGPT, Cursor, etc.) to use SerpApi as a web search tool.”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://serpapi.com/openapi.json, https://serpapi.com/swagger.json, https://serpapi.com/api/openapi.…”
   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”

   proof ↗⚑ flag

Llm ready results

1. developerGet a sourced, LLM-generated answer to a query in a single API call

   weight 2 · round to Exa
   Exa✓fullclaimed8/10

   Exa's `/answer` endpoint (exposed via exa-js `exa.answer()`) returns an LLM-generated answer with citations in a single call, as shown in exa-gh-3 and exa-gh-8 ("Get answers with citations"). This is backed by first-party SDK code, though there's no independent hands-on validation of answer quality specifically for this endpoint. Missing for 10: independent/community verification of the answer API's accuracy and citation quality, and deeper docs beyond SDK snippets.

   • [github] “const { answer } = await exa.answer("What is the capital of France?");”
   • [github] “Get answers with citations const { answer } = await exa.answer("What is the capital of France?");”
   • [claimed-docs] “Enrich entities, build large lists, and run deep research from a single API with built in structured results and web citation”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi's evidence shows it returns structured/markdown search results (including Google AI Overview scraping and RAG use-case framing) meant to be fed into a separate LLM pipeline, not a single-call endpoint that itself returns an LLM-generated, sourced answer. No endpoint or docs describe SerpApi generating the answer itself.

   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”
   • [claimed-docs] “Find out how your content is being used in AI-generated answers on Google AI Mode. Monitor your brand's visibility and optimize your SEO str…”
   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”

   proof ↗⚑ flag

2. developerGet results sized and ranked for direct use as LLM context in a RAG pipeline

   weight 3 · round drawn
   Exa✓fullcommunity8/10

   Exa's docs explicitly target RAG-context sizing: '10x token efficient extracts' with a recommended 4000-character cap, `output_schema` for structured JSON, clean page content extraction handling JS/PDFs, and citation-backed `answer()` calls — all clearly aimed at feeding LLM pipelines directly. Community feedback (exa-comm-1, exa-comm-8) corroborates the RAG-focused design ('SERP is not the right way to let an LLM interact with the web'), though one user requested a 'cruft cleaner' suggesting content isn't always perfectly trimmed. Missing for 10: independent benchmarks quantifying token-efficiency/relevance gains, and no evidence addressing edge cases like very large result sets consistently staying within context budgets.

   • [claimed-docs] “10x token efficient extracts of only the relevant tokens from a webpage. 4000 characters recommended.”
   • [claimed-docs] “Use `output_schema` with any search type to extract structured JSON from search results”
   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [claimed-docs] “Return query-relevant excerpts from Exa Search results while controlling context size and latency.”
   • [claimed-docs] “Exa Contents returns clean page content from URLs, handling JavaScript-rendered pages, PDFs, and complex layouts automatically.”
   • [github] “const { answer } = await exa.answer("What is the capital of France?");”
   • [community] “Signed up for a trial account and I'm pretty impressed with the search API (haven't used Websets yet but looks cool). Suggested adding a 'cr…”
   • [community] “I am a BIG Exa fan. NewsCatcher and Exa aren't direct competitors but share the same insight — SERP is not the right way to let an LLM inter…”

   proof ↗⚑ flag

   SerpApi✓fullprobed8/10

   SerpApi explicitly supports markdown output 'optimized for LLMs and AI agents' with roughly half the token size of JSON, a field-selection parameter to reduce payload size, and explicitly markets a RAG use case ('Feed search data into AI pipelines to minimize hallucinations'), plus an llms.txt and MCP server for agent consumption. missing for 10: independent/hands-on evidence confirming markdown output quality and ranking relevance in a real RAG pipeline, and no benchmark showing token/size reduction claims validated externally.

   • [claimed-docs] “Serve any SerpApi search result as clean markdown. Same data as JSON, zero configuration, roughly half the tokens. Works with every API.”
   • [claimed-docs] “Parameter defines the fields you want to include in the output, reducing payload size for faster response.”
   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://serpapi.com/llms.txt # SerpApi > SerpApi provides a real-time JSON API for accessing structured search …”
   • [probe] “official MCP server documented at https://github.com/serpapi/serpapi-mcp”
   • [claimed-docs] “Parameter defines the format of the result. It can be set to `json` (default) to get a structured JSON of the results, `html` to get the raw…”

   proof ↗⚑ flag

Retrieval modes

1. developerFind pages similar to a URL I already have

   weight 1 · round drawn
   Exa—none0/10

   The evidence pack covers Exa's keyword/neural search, contents extraction, Websets, MCP integration, and agent tooling, but nowhere mentions a 'find similar' or URL-based similarity search endpoint. No documentation, GitHub snippet, or community report in this pack references finding pages similar to a given URL.

   ⚑ flag

   SerpApi—none0/10

   SerpApi's docs only mention support for generic Google search operators like inurl:, site:, and intitle: — there is no evidence of support for the 'related:' operator or any dedicated 'find similar pages' feature that would let a developer discover pages similar to a given URL.

   • [claimed-docs] “You can use anything that you would use in a regular Google search. e.g. `inurl:`, `site:`, `intitle:`.”
   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”

   proof ↗⚑ flag

2. developerRun meaning-based semantic search that finds results keyword engines miss

   weight 3 · round to Exa
   Exa!disputedcontradicted5/10

   Exa's docs describe a purpose-built neural/semantic search model that returns 'clean, relevant page content' in natural language rather than keyword matching, and one HN commenter explicitly notes Exa's insight that 'SERP is not the right way to let an LLM interact with the web.' However, hands-on community reports contradict the quality claim: one user got '1 match, 14 misses' with results stuck 'Verifying...', and another found GitHub repo search only '30/70' accurate at finding requested items. Missing for 10: independent benchmark comparisons against keyword search, resolution of the reported miss-rate issues, and broader corroboration of search accuracy beyond a single anecdotal thread.

   • [claimed-docs] “Search the web in natural language and get clean, relevant page content in one request.”
   • [claimed-docs] “Specialized model trained to extract the most relevant excerpts from the web”
   • [claimed-docs] “Exa has custom search types with appropriate latency-quality profiles, from ~250 ms instant search to 12-40 second deep-reasoning search.”
   • [community] “I am a BIG Exa fan. NewsCatcher and Exa aren't direct competitors but share the same insight — SERP is not the right way to let an LLM inter…”
   • [community] “I gave it a try and my first search got one match, 14 misses, and all other results are 'Verifying...' but it seems stuck (been minutes)... …”
   • [community] “Tried the GitHub repo search feature: it was about 30/70 on finding the things I asked for. The cURL example in 'Get Code' was demonstrably …”

   proof ↗⚑ flag

   SerpApi—none0/10

   SerpApi's evidence describes scraping keyword-based results from Google, Bing, etc. (serpapi-docs-1, serpapi-gh-6) and provides RAG/feed-to-LLM use cases (serpapi-docs-25), but nothing indicates it performs meaning-based/semantic search or surfaces results that keyword engines would miss — it merely mirrors the underlying search engine's keyword results. No vector search, embeddings, or semantic ranking capability is mentioned anywhere in the pack.

   • [claimed-docs] “Our Google Search API allows you to scrape results from the Google search page.”
   • [github] “This Python package is meant to scrape and parse search results from Google, Bing, Baidu, Yandex, Yahoo, Home Depot, eBay and more”
   • [claimed-docs] “Retrieval-Augmented Generation (RAG): Feed search data into AI pipelines to minimize hallucinations.”

   proof ↗⚑ flag