YouTube is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the YouTube 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 · 52/100Comprehension
55% of score · 85/100What we found
- An agent that already knows to look on developers.google.com finds excellent, well-structured reference docs — but there is no llms.txt, llms-full.txt, or .well-known/mcp.json on either youtube.com or the docs domain, so an agent gets no LLM-native entry point and must crawl HTML.
- The API is fully machine-readable via Google's public Discovery Document (googleapis.com/discovery/v1/apis/youtube/v3/rest) and a community OpenAPI 3.0 conversion on APIs.guru, so an agent can programmatically enumerate every method, parameter, and schema.
- Comprehension is strong (85/B): endpoint descriptions are task-oriented, naming is consistently camelCase, quota/limits are documented per method, and dedicated implementation guides show real multi-step workflows (e.g. retrieve a channel's uploads playlist, then list its items).
- Error docs list every typed error with a plain-language cause, but stop short of consistent recovery instructions — an agent learns WHAT went wrong (invalidPageToken, quotaExceeded) but rarely an explicit DO-THIS-NEXT fix.
- No official AGENTS.md exists in a Google-owned repo; agent-readiness signals for YouTube today come almost entirely from third-party MCP servers and the APIs.guru mirror, not from the vendor.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at the docs root (developers.google.com/youtube or a YouTube-scoped path) that summarizes core capabilities (search, videos, playlists, channels, comments), links the key reference and guide pages, and points to the Discovery Document — this is the single biggest discovery gap.
- 02Offer an official OpenAPI/Swagger export (or prominently link the Discovery Document from the reference landing page) so agents don't have to rely on the APIs.guru community mirror to get a machine-readable spec.
- 03Add explicit recovery guidance to the errors page: for each common error (quotaExceeded, invalidPageToken, rateLimitExceeded, backendError) state the concrete next action (e.g. exponential backoff with Retry-After, request a quota increase, re-fetch a fresh page token).
- 04Provide a concise LLM-oriented overview (<5,000 tokens) of the resource model and quota system so an agent can grasp core capabilities without parsing the 500KB Discovery Document or many separate HTML pages.
- 05Publish an AGENTS.md in the relevant Google/YouTube API sample repositories with setup, auth, and quota context to give coding agents a canonical, vendor-owned starting point.
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 well-documented (API key for public reads, OAuth 2.0 with granular scopes for user actions). Errors return machine-parseable JSON with typed error codes on a dedicated errors page. A detailed quota system (per-method unit costs, daily limits) covers rate limiting, and pagination is cursor-based via pageToken/nextPageToken. Idempotency keys are not documented.