Pexels is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Pexels 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 · 17/100Comprehension
55% of score · 79/100What we found
- An agent using a plain HTTP client is blocked before it starts: Pexels returns 403 to non-browser fetchers and its robots.txt disallows training crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended, PerplexityBot) with Disallow: / — though it notably allows real-time agent fetchers (Claude-User, Claude-SearchBot, Perplexity-User).
- Positive: once an agent reaches the docs, comprehension is strong (79/B). Endpoint descriptions are task-oriented ('search Pexels for any topic'), examples use realistic values across four languages (curl, JavaScript, Ruby, .NET), and consistent snake_case naming lets an agent build a correct request on the first try.
- No machine-readable discovery surface exists — no llms.txt, no OpenAPI/Swagger spec, and no .well-known/mcp.json — so an agent cannot programmatically enumerate the API and must scrape a single JS-rendered HTML docs page.
- Error handling is a blind spot: the docs contain zero error codes, no error-response schema, and no recovery steps beyond a passing note about 429. An agent hitting a 401/400/429 would have to discover the fix by trial and error.
- Discovery is effectively carried by the community: Pexels is well-listed across MCP registries (Glama, Smithery, and an 'official' PulseMCP listing), so an agent is more likely to find a pre-built Pexels MCP tool than to locate and parse the raw API.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an OpenAPI/Swagger spec at a stable URL — this is the single highest-weighted missing discovery signal (weight 5) and would let agents enumerate endpoints, parameters, and response shapes programmatically instead of scraping HTML.
- 02Add an llms.txt (and ideally llms-full.txt) pointing to the API docs — a low-effort discovery win that gives agents a clean, API-focused entry point.
- 03Add an error reference with recovery guidance: document 401/400/429 responses, their JSON shape, and the corrective action (e.g., 'on 429, wait until X-Ratelimit-Reset'). This is the largest comprehension gap.
- 04Add at least one end-to-end workflow guide (e.g., authenticate → search → paginate → get a photo → apply required attribution) rather than only isolated endpoint references.
- 05Reconsider the aggressive 403 bot-blocking on the docs domain or add markdown content negotiation, so agents can retrieve clean documentation without a headless browser.
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.
Read-only RESTful JSON API authenticated via a single API key in the Authorization header. Rate limits are clearly documented (200 req/hour, 20,000 req/month, exposed via X-Ratelimit-Limit/Remaining/Reset headers) and pagination is well-specified (page/per_page params, next_page/prev_page response URLs, max 80 per page). No error-response format or status-code catalog is documented, and idempotency is not addressed (moot for a GET-only API).