Apillon is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Apillon 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 · 21/100Comprehension
55% of score · 81/100What we found
- An agent cannot resolve the documented API and docs hosts (wiki.apillon.io, sdk-docs.apillon.io, api.apillon.io) from datacenter IPs — DNS resolution failed from every automated route tried (sandbox + Firecrawl US), even though the pages are live and Google-indexed. Any agent attempting to fetch the reference or call the API in real time would fail before reading a single line.
- The documentation itself is genuinely strong for humans: endpoints are described task-first ('triggers deployment of website to a specific environment'), every route ships a copy-pasteable curl request plus a realistic JSON response, and the org publishes multi-language examples (PHP, C#, Python) alongside a first-class TypeScript SDK.
- There is zero machine-readable discovery surface: no OpenAPI/Swagger spec, no llms.txt or llms-full.txt, no /.well-known/mcp.json, and no AGENTS.md in the SDK repo — an agent gets nothing structured to bootstrap from.
- Apillon shipped an official first-party MCP server (announced on their blog, published to GitHub), which is a strong agent-readiness signal — but it is not surfaced in the major MCP registries (Glama, Smithery, PulseMCP), so agents relying on registry discovery won't find it.
- Error semantics are above average: structured codes with the offending property make failures machine-parseable, but there are no explicit recovery steps (e.g. no Retry-After guidance) and rate limits are undocumented, so an agent learns limits only by hitting them.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix agent-facing reachability of wiki.apillon.io / sdk-docs.apillon.io / api.apillon.io — verify DNS resolves from non-residential/datacenter resolvers and that no geo/CDN rule blocks automated clients. This is the single highest-impact fix; well-written docs are worthless to an agent that can't resolve the host.
- 02Publish a machine-readable OpenAPI 3.x spec (highest-weight discovery check at 0/5) covering all REST modules and link it from the docs — this alone unlocks SDK generation, tool schemas, and reliable agent grounding.
- 03Add an llms.txt at the docs root (and ideally llms-full.txt) that summarizes the core modules — API, Storage, Hosting, NFT, RPC, Identity, Computing, Social — with links, giving agents a <5k-token entry point instead of forcing a multi-page crawl.
- 04Add an AGENTS.md to the SDK and MCP-server repos, and submit the official Apillon MCP server to Glama, Smithery, and PulseMCP so registry-based agent discovery surfaces it.
- 05Document rate limits (specific numbers + header names) and add explicit error-recovery guidance to the top error codes so an agent can self-correct rather than discover boundaries by failing.
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 well documented for a hand-written reference: HTTP Basic auth (Base64 of key:secret) is explained up front, errors return a structured JSON object with a unique numeric code, the offending property, and a message (e.g. 40006003 NOT_ENOUGH_STORAGE_SPACE, 40210000 CREDIT_BALANCE_TOO_LOW), and pagination is uniform offset-based (page, limit, orderBy, desc). Rate limits and idempotency keys are not documented anywhere an agent could find them.