Activepieces is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Activepieces 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 · 90/100Comprehension
55% of score · 69/100What we found
- An agent discovering Activepieces lands well: the docs are fully OpenAPI 3.1.0-backed (the machine-readable spec is embedded in every endpoint page and in llms-full.txt), and both llms.txt and a 625KB llms-full.txt are published at the docs root — discovery surface is near best-in-class.
- Activepieces is one of the few APIs with a genuine AGENTS.md in its primary repo (activepieces/activepieces, packages/web/AGENTS.md) plus an official MCP server listed on PulseMCP and Glama — strong signals for both coding agents and runtime agents.
- Comprehension is the weak link: auto-generated request examples use schema placeholders ('string') rather than realistic values, so an agent gets shape but not plausible inputs to copy-paste.
- Error recovery is essentially undocumented for the REST API — endpoint responses list only success codes with no error catalog or fix guidance, so an agent would discover failure modes only by failing.
- robots.txt allows all crawlers (Allow: /) and the docs are served as clean markdown (.md endpoints + llms files), so agent ingestion is frictionless.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add realistic example values to the OpenAPI schemas (e.g. displayName: 'My Lead Sync', a real-looking projectId) so Mintlify renders copy-pasteable, plausible requests instead of 'string' placeholders.
- 02Document API error responses: add an error-code reference with HTTP statuses, machine-parseable error bodies, and explicit recovery steps (what to do on 401/403/429/400) — currently endpoints only show success responses.
- 03Document REST API rate limits and idempotency for API consumers (limit headers, retry guidance, idempotency keys) — today rate-limit/concurrency docs are framed around self-hosting and pieces, not API callers.
- 04Publish a single consolidated OpenAPI spec at a discoverable path (e.g. /docs/openapi.json) and link it from the API overview — the spec is currently only reconstructable per-endpoint.
- 05Expand endpoint descriptions to be consistently task-oriented (several, like Update Project, have no description) and include the docs pages in the marketing sitemap.xml so the full doc set is crawlable from one index.
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.
REST API auth is a Bearer API key (Platform/Enterprise editions); the hosted MCP server uses OAuth. Seek/cursor pagination is clearly documented with a standard data/next/previous envelope. API-level error formats, rate limits, and idempotency are not documented for API consumers — the OpenAPI reference shows mostly success responses ('Default Response') with no error-code catalog.