jina is Good to agents.
Discry independently scored how well an AI agent can discover and understand the jina 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 · 60/100Comprehension
55% of score · 96/100What we found
- An agent lands in an ideal state: docs.jina.ai serves clean LLM-friendly markdown for EVERY path (a catch-all), and its llms.txt is a purpose-built 25KB (~6K token) agent brief covering all four APIs — endpoints, request schemas, model specs, and explicit code-generation rules — so an agent can understand the entire product without scraping HTML.
- A complete, versioned OpenAPI 3.1 spec is publicly reachable at api.jina.ai/openapi.json (175KB, dated 2026-06-29), with per-endpoint descriptions, realistic request examples, a full error-code table, and tiered rate limits — an agent can generate a working client directly from it.
- Discovery is the weak dimension: jina.ai has no robots.txt (404) and no .well-known/mcp.json, and no AGENTS.md exists in any jina-ai GitHub repo — so agents relying on those conventional discovery entry points come up empty.
- The sitemap only covers jina.ai marketing/product pages (api-dashboard, news, product) — the actual API docs at docs.jina.ai are absent and that host serves no real sitemap, so a crawler mapping the site never reaches the reference material.
- Jina is heavily present in the MCP ecosystem — an official jina-ai/MCP remote server plus numerous community listings across Smithery, Glama, and PulseMCP — so an agent searching MCP registries for Jina tooling finds abundant, ready-to-use options.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add a robots.txt at jina.ai (and docs.jina.ai) that explicitly allows GPTBot, ClaudeBot, Google-Extended, and CCBot and points to the sitemap — this is a near-zero-effort fix that currently scores a full fail on a weight-3 discovery check.
- 02Publish a real sitemap.xml for docs.jina.ai (or add the docs.jina.ai reference/llms.txt URLs to the jina.ai sitemap) so crawlers can discover the API documentation, not just marketing pages.
- 03Add an AGENTS.md to the primary repos (jina-ai/MCP, jina-ai/reader) with setup, auth, and usage context for coding agents — a rising standard (weight 3) that Jina currently misses entirely.
- 04Serve a .well-known/mcp.json advertising the official Jina MCP server's tools and auth, giving agents a standards-based discovery path to the MCP endpoint that already exists.
- 05Strengthen per-error recovery guidance: pair each documented error code with an explicit action (e.g., 'on 429 RATE_REQUEST_LIMIT_EXCEEDED, back off and retry after the window; on INPUT_TOKEN_LIMIT_EXCEEDED, chunk input below the model max') to move error-recovery from partial to pass.
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.
Execution characteristics are documented with unusual rigor for a scan-tier API. The OpenAPI spec includes a full error-code table (INPUT_*, AUTH_*, RATE_* with 400/401/403/429/500/503 statuses), tiered rate limits (RPM/TPM/concurrency by plan) plus named rate-limit headers (X-RateLimit-Remaining-Requests/Tokens), Bearer-token auth, and SERP-style pagination (page/num) for the search reader. Idempotency keys are not mentioned. These are documented claims — live behavior requires a full Discry Audit.