Bright Data is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Bright Data 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 · 74/100Comprehension
55% of score · 96/100What we found
- An agent discovering Bright Data lands in an exceptionally agent-native docs surface: robots.txt uses explicit Content-Signal (ai-train=yes, ai-input=yes), a 99KB llms.txt indexes every page with .md mirrors, a 5.3MB llms-full.txt provides the full corpus as markdown, and a valid /.well-known/mcp.json points to a live docs MCP server.
- Comprehension is near-best-in-class: endpoint descriptions are task-oriented (collect-by-url vs discover-by-keyword), examples ship in cURL/Python/Node with realistic values, and every endpoint family documents limits, 429 behavior, and explicit retry/backoff recovery code — an agent can self-correct without human help.
- Bright Data is deeply embedded in the agent ecosystem: the production brightdata-mcp server is listed across MCP registries (LobeHub and others), and a dedicated brightdata/skills repo plus /ai/for-agents docs onboard coding agents directly.
- The main discovery gap is the OpenAPI spec: an agent cannot grab one unified machine-readable spec — specs exist only per-product (SERP, Web Unlocker) and via blog posts / third-party mirrors, so programmatic client generation is fragmented.
- No literal AGENTS.md file exists in the primary repos; agent onboarding is served instead through SKILL.md files and /ai/for-agents docs, so tools scanning specifically for AGENTS.md would miss it.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a single unified, versioned OpenAPI spec at a discoverable path (e.g. docs.brightdata.com/openapi.json) covering the core Web Access APIs — this is the highest-impact discovery fix and would lift the openApiSpec check from partial to pass.
- 02Add an AGENTS.md at the root of brightdata-mcp and brightdata/skills that points to the for-agents docs and skills — cheap to add and captured by the growing set of tools that scan for that exact filename.
- 03Trim the llms.txt (currently ~99KB) to an API-focused index under 50KB, or split product/marketing links out, so it stays right-sized for agent context windows (fixes llmsTxtQuality and improves token efficiency).
- 04Add explicit tool declarations to /.well-known/mcp.json (currently just a server pointer) so agents can enumerate available capabilities without connecting.
- 05Provide a concise <5,000-token 'core capabilities' overview (one page) so an agent can understand the platform's surface without traversing the 5.3MB full corpus.
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.
Strong execution documentation. Bearer-token auth is documented consistently, errors return machine-parseable JSON with codes/messages plus x-brd-error-code headers, rate limits are explicit (100 req/min trial, HTTP 429 with Retry-After) and pagination is covered (search_after cursor for Dataset Search, next_page_start for SERP). Idempotency keys are not documented.