SubDownload is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the SubDownload 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 · 29/100Comprehension
55% of score · 91/100What we found
- An agent that reaches SubDownload's docs finds a genuinely agent-native product — a hosted MCP server (13 tools, OAuth 2.1 + DCR), a one-command Agent Skill (npx @subdown/skill), and a REST API with SDKs in 6 languages — all documented in clean, task-oriented markdown that scores an A on comprehension.
- Discovery is the weak dimension: robots.txt explicitly Disallows ClaudeBot, GPTBot, Google-Extended, CCBot, Amazonbot and more, so a training/indexing crawler is turned away even though the product is built for AI agents.
- The OpenAPI spec is advertised in llms.txt (manage.subdownload.com/openapi.yaml) but every candidate path — that URL plus api/root openapi.json and openapi.yaml — returns 404, so an agent that follows the pointer hits a dead link instead of a machine-readable contract.
- Error recovery is a standout: the billing page pairs each status code with an action (429 → wait Retry-After seconds, 402 → upgrade, 404 no-captions → fall back to ASR), and the async ASR flow hands agents next_poll_after_seconds pacing so they self-correct without guessing.
- SubDownload is listed and quality-scored (A) on the Glama MCP registry, so an agent hunting for a YouTube-transcript tool can discover it through the registry channel even though sitemap.xml, llms-full.txt, .well-known/mcp.json and AGENTS.md are all absent.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix or publish the OpenAPI spec: the llms.txt already promises manage.subdownload.com/openapi.yaml, but it 404s. Serving a valid spec there (the single highest-weighted discovery check) would move the biggest needle on the score.
- 02Stop blocking agent user-agents in robots.txt. At minimum allow ClaudeBot and GPTBot (or scope the Disallow to ai-train only); blocking the very crawlers that power the assistants you're courting is self-defeating and is the second-biggest discovery loss.
- 03Add a sitemap.xml listing the /docs/* and /kb/v/* pages so crawlers and agents can enumerate the documentation and knowledge base surfaces.
- 04Publish an AGENTS.md in the subdownload-mcp (or api-sdk) repo giving coding agents setup context — install command, auth flow, tool list — to capture the rising agents.md standard.
- 05Add 2-3 dedicated end-to-end task recipes (e.g. 'build a searchable knowledge base: transcribe → summarize → save_to_library → search') to lift multi-step-workflow coverage beyond the auth/setup quick-start.
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 unusually well documented for a scan-tier API: machine-parseable JSON errors ({error:{code,message}}), a concrete 200 req/min rate limit with X-RateLimit-* and Retry-After headers, and cursor/continuation-token pagination. Auth covers both static Bearer keys and OAuth 2.1 with DCR. No idempotency keys are documented, though async ASR cache-coalescing and library upserts provide de-facto replay safety.