Statsig is Agent-Ready to agents.

What we found

• —An agent discovering Statsig would land softly: docs.statsig.com ships llms.txt, a 2.8MB llms-full.txt (792 pages), a versioned public OpenAPI spec, a sitemap, and a robots.txt that explicitly allows every major AI crawler (GPTBot, ClaudeBot, anthropic-ai, PerplexityBot, Google-Extended, CCBot and more) — blocking only internal /api/ utility routes.
• —Statsig is one of the most MCP-forward APIs scanned: it runs BOTH a public read-only Docs MCP server (get_page / list_pages / search_docs at docs.statsig.com/api/mcp) AND an authenticated Console MCP server (api.statsig.com/v1/mcp) with OAuth, and is listed as an official server on PulseMCP and Glama. An agent can manage gates and experiments via MCP with no scraping at all.
• —Comprehension is strong across the board: endpoint summaries are task-oriented, curl examples use realistic values, every concept is offered as clean markdown (via llms.txt, content negotiation, and the Docs MCP), and multi-step implementation guides walk an agent through end-to-end flows like 'Implement an Experiment'.
• —The one discovery gap is .well-known/mcp.json (404) — but it's effectively moot since Statsig advertises its MCP endpoints through the docs and registries instead, so an agent still finds them.
• —Token efficiency is the weakest comprehension signal: the surface area is large (feature flags + experiments + analytics + warehouse-native across 792 pages) and the llms.txt is ~140KB, so an agent narrowing to one capability must wade through more than the ideal <5K-token overview.

What to change

Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.

1. 01Trim or split llms.txt: at ~140KB it exceeds the agent-friendly size guideline. Publish a lean, API-focused index (Console API + SDK quickstarts) separate from the full product link dump so agents can load core capabilities in <12K tokens.
2. 02Add error-recovery guidance to the Console API reference: error codes (400/403) carry descriptions, but few document the concrete fix ('which parameter was invalid', 'retry after N seconds'). Pairing each common 4xx with an actionable recovery step would push error handling from partial to pass.
3. 03Document idempotency for mutating Console API endpoints (POST/PATCH/DELETE), or state explicitly that retries are safe/unsafe — agents chaining operations need this to recover from network failures without duplicating writes.
4. 04Add a .well-known/mcp.json manifest pointing at the existing Docs and Console MCP servers — a cheap, standards-based discovery hook that complements the registry listings already in place.
5. 05Broaden AGENTS.md coverage: it exists and is genuinely useful in statsig-kit (Apple SDK), but adding equivalents to the primary docs and high-traffic SDK repos would give coding agents consistent build/test context across the org.