serpapi is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the serpapi API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 57/100Comprehension
55% of score · 85/100What we found
- An agent can consume SerpApi's docs natively: every documentation page is served as clean Markdown at a .md URL (e.g. serpapi.com/search-api.md), and a well-structured llms.txt indexes 100+ engine APIs with per-link descriptions — this is the strongest comprehension signal in the scan.
- SerpApi is unusually agent-forward for discovery: it maintains a dedicated serpapi/skills GitHub repo with a comprehensive AGENTS.md, ships an official MCP integration (hosted at mcp.serpapi.com), and is listed in the Glama MCP registry — so an agent looking to wire up SerpApi finds first-party tooling, not just a REST endpoint.
- The biggest discovery gap is the missing OpenAPI spec (weighted 5 — the single heaviest discovery check): no machine-readable spec is published at standard paths, so an agent cannot auto-generate a typed client or tool schema without hand-parsing the Markdown.
- Endpoint docs are strongly task-oriented and lead answer-first — each page opens with a concrete GET example and a parameters table using realistic values (q=Coffee) and real JSON response samples across 12 official SDK languages.
- sitemap.xml, llms-full.txt, and .well-known/mcp.json all return 404, and error-recovery guidance stops at describing the JSON error format rather than telling an agent what to DO on a 429 or a failed search — an agent would learn recovery behavior only by failing.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a machine-readable OpenAPI spec at a discoverable path (e.g. serpapi.com/openapi.json) and link it from llms.txt — this is the highest-impact discovery fix (weight 5) and would let agents auto-generate typed clients and tool schemas.
- 02Add a serpapi.com/sitemap.xml that enumerates the API documentation pages (a quick, near-zero-cost fix worth 2 discovery points) and reference it from robots.txt.
- 03Add explicit error-recovery guidance to the docs: for the top error scenarios (rate-limit / 429, invalid api_key, empty results, geo/uule conflicts) document the exact recovery step an agent should take, not just the error shape.
- 04Consolidate capability boundaries into one agent-readable place — surface the monthly search quota, concurrency limit, and per-engine constraints inside llms.txt or a limits.md instead of only on the pricing page.
- 05Publish a serpapi.com/llms-full.txt with the full concatenated Markdown of core engines so an agent can pull complete API knowledge in a single fetch rather than crawling dozens of .md pages.
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Auth is a single API key passed as the api_key query parameter. Errors return as JSON with an error key, and pagination is well documented via serpapi_pagination (next_link) plus native start/offset params. Rate limits are plan/account-based (monthly search quota + concurrency) documented on the pricing page rather than per-endpoint. Idempotency keys are not documented (search is a read-only GET, so mutation idempotency is not applicable).