apimatic.io is Good to agents.
Discry independently scored how well an AI agent can discover and understand the apimatic.io 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 · 76/100Comprehension
55% of score · 97/100What we found
- An agent landing on docs.apimatic.io finds a purpose-built agent surface: a comprehensive llms.txt with per-link descriptions, plus clean markdown for ANY page via a .md suffix (e.g. .../pagination.md) — near-ideal for LLM consumption and rare among developer-tool vendors.
- APIMatic explicitly positions itself as a 'Developer and Agent Experience Platform' and backs it up with a dedicated apimatic/skills repo, an apimatic/context-matic context-plugin project for coding agents, and an APIMatic Validator MCP server listed on Glama — an agent looking for tooling would find first-class support.
- The API Transformer troubleshooting page is a standout for self-correcting agents: it quotes exact error strings and prescribes concrete fixes for 15+ failure scenarios (unresolved $ref, YAML mapping errors, missing RAML version comments), turning failures into recoverable steps rather than dead ends.
- Endpoint examples are realistic and multi-language — copy-pasteable cURL with real JSON payloads and idiomatic TypeScript/Go/Java/C#/Python/Ruby responses using plausible values (id '1001', cursor 'id_123') rather than 'string'/'123' placeholders.
- Discovery is held back on the machine-readable front: no /.well-known/mcp.json, no confirmed publicly downloadable raw OpenAPI spec for APIMatic's own Platform API (only an interactive OpenAPI-generated reference), and no literal AGENTS.md — an agent that wants a spec file to load, rather than a portal to read, comes up short.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a raw, publicly downloadable OpenAPI spec for the Platform API at a stable URL (e.g. docs.apimatic.io/platform-api/openapi.json) — as an OpenAPI-tooling company this is the single highest-impact discovery gain (weight 5) and lets agents load the spec directly instead of scraping the interactive reference.
- 02Add a /.well-known/mcp.json declaring the APIMatic Validator (and any hosted MCP servers) with tool and auth metadata, so agents can auto-discover MCP capabilities without a web search.
- 03Add an AGENTS.md to the primary product/SDK repositories that points to the skills repo, context plugins, and Platform API — a literal AGENTS.md is a low-effort, rising-standard signal that complements the strong agent tooling already in place.
- 04Lead the how-to guides (e.g. Create SDK through API) with the raw HTTP method, path, and a request/response example before the UI click-through and screenshots; several guide pages currently bury the machine-actionable call behind dashboard walkthroughs an agent can't follow.
- 05Document rate limits (with header names) and any idempotency-key support for the Platform API, so agents can plan retries and avoid duplicate SDK/transform jobs instead of discovering limits only 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.
The Platform API documents machine-parseable JSON errors surfaced as typed ApiException/ApiError objects, several auth schemes (Auth Key header, Basic, OAuth 2.0 with auto-refresh, custom-header signature), and unusually thorough pagination coverage (cursor/link/number/offset variants across 6 languages). Rate limits and idempotency keys are not clearly documented and would only surface through live testing.