LottieFiles is Good to agents.
Discry independently scored how well an AI agent can discover and understand the LottieFiles 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 · 96/100What we found
- An agent looking for LottieFiles would find it easily and understand it fast: robots.txt allows all major AI crawlers and both a root llms.txt and a purpose-built developer-portal llms.txt (plus a comprehensive llms-full.txt) give a clean, right-sized map of the platform — the developer llms.txt even splits into per-topic files (web players, mobile players, dotLottie-JS, reLottie).
- Comprehension is near-exemplary: every SDK is documented with task-oriented descriptions, realistic copy-pasteable examples using real lottie.host URLs, and coverage across seven languages/frameworks (JS, React, Vue, Svelte, Web Component, iOS/Swift, Android/Kotlin, React Native) — an agent could integrate a player without guessing.
- Error recovery is genuinely agent-usable: docs include numbered troubleshooting flows ('Animation Not Loading → check src path → inspect for 404/CORS → attach a loadError listener'), which is rare and separates these docs from human-only reference.
- The biggest discovery gap is the absence of any publicly accessible OpenAPI/Swagger spec (the heaviest-weighted signal): LottieFiles is SDK-first and its underlying search/retrieve REST API is not published with a machine-readable spec, so an agent cannot auto-generate a client for the service layer.
- No AGENTS.md and no .well-known/mcp.json exist, and the developer subdomain has no sitemap — but MCP coverage is strong via third-party listings on Smithery, PulseMCP, and Glama plus an official Lottie Creator MCP, so agents can still discover a tool interface.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a machine-readable OpenAPI/Swagger spec for the animation search/retrieve REST API (the layer the community MCP already wraps) at a discoverable path — this is the single highest-impact fix and directly lifts the heaviest discovery signal.
- 02Add a sitemap.xml for developers.lottiefiles.com (currently 404) and reference the developer-portal docs pages from the root sitemap so crawlers can enumerate the API/SDK documentation, not just marketing pages.
- 03Add an AGENTS.md to the primary GitHub repos (LottieFiles org, e.g. dotlottie-rs / player repos) with setup, build, and integration context for coding agents — a rising standard and an easy win.
- 04Publish a .well-known/mcp.json declaring the official Lottie Creator MCP and any hosted animation-search MCP with tool declarations and auth info, so agents can auto-discover the tool surface without relying on third-party registries.
- 05Document service-level execution characteristics (REST API auth scheme, rate limits + header names, pagination, and lottie.host quotas) so agents integrating the search/hosting API know the boundaries before failing at runtime.
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.
LottieFiles ships client SDKs/players rather than a conventional authenticated REST API, so execution docs are SDK-centric: playback lifecycle, event emitters (load, play, loadError), and resource cleanup are documented thoroughly. The players require no auth to render public/hosted animations. Service-level execution characteristics for the underlying REST/hosting API (auth scheme, rate limits, pagination, idempotency) are largely undocumented publicly — the community built an MCP server to wrap the search/retrieve API rather than reference an official spec.