RudderStack is Good to agents.
Discry independently scored how well an AI agent can discover and understand the RudderStack 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 · 67/100Comprehension
55% of score · 87/100What we found
- An agent that finds RudderStack lands in unusually agent-friendly territory: RudderStack ships an official first-party MCP server (mcp.rudderstack.com) documented under /docs/ai-features/ and listed across MCP directories (Cursor Directory, mcpservers.org, Pipedream), plus a dedicated rudder-agent-skills repo with skills for rudder-core, rudder-cli, rudder-mcp, and rudder-terraform.
- Endpoint docs are written for task completion, not just reference: every call leads with a plain-language purpose ("The identify call lets you associate a visiting user to their actions") and method/path at the top, followed by realistic copy-pasteable examples in curl and HTTPie with believable values (alex@example.com, revenue 4.99, ISO-8601 timestamps).
- Discovery is held back by a marketing-flavored llms.txt: it is present, well-structured, and right-sized, but it is a site-wide product/solutions/case-study directory that links to the docs home only once — an agent gets the company pitch, not an API map. No llms-full.txt and no .well-known/mcp.json exist.
- No single formal OpenAPI/Swagger spec is published. The HTTP API points to a public Postman collection and the control-plane APIs (Transformations, Data Catalog, Profiles, etc.) are documented as hand-built HTML pages — readable, but an agent cannot ingest one machine-readable contract for the whole surface.
- Capability boundaries and recovery guidance are partial: hard size limits and behavioral constraints ("a destination can have only one connected transformation", "you cannot change the language") are stated clearly, but rate limits are unquantified and most error codes get a description rather than an explicit fix step.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a documentation-focused llms.txt (or a docs-scoped /docs/llms.txt) that maps the actual API surface — HTTP API, Transformations, Data Catalog, Profiles, Reverse ETL — with one line per capability, instead of the current marketing link directory. This is the single highest-impact discovery fix.
- 02Ship a machine-readable OpenAPI 3.x spec covering the control-plane APIs (api.rudderstack.com) and link it from /docs/api/. A single downloadable contract would move the openApiSpec check (the heaviest discovery weight) from partial to pass and unlock codegen for agents.
- 03Add an llms-full.txt with the concatenated API reference markdown so agents can grab the full surface in one fetch — the Hugo pages already convert cleanly, so this is largely a build-step addition.
- 04Quantify rate limits (requests/sec or /min and the response header names) in the HTTP and control-plane API docs so an agent can implement backoff proactively rather than discovering limits by hitting 429.
- 05Expand error documentation into explicit recovery steps for the top status codes (e.g., "401 → regenerate the source write key", "413 → split the batch below 4MB", "publish failed → validate transformation code against referenced libraries") so agents can self-correct without human intervention.
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 docs are strong on auth (multiple methods with token-permission tables), error format (machine-parseable JSON with a `message` field plus a full HTTP status-code table), and hard size limits (32KB/call, 4MB/batch). Pagination is covered via count/orderBy query params on list endpoints. Gaps: rate limits are acknowledged (429) but never quantified with numbers or header names, and idempotency keys are not documented.