api2cart.com is Good to agents.
Discry independently scored how well an AI agent can discover and understand the api2cart.com 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 · 71/100Comprehension
55% of score · 87/100What we found
- An agent can fully machine-read this API: the interactive docs link directly to a public OpenAPI spec at app.api2cart.com/openapi/openapi.json (HTTP 200, application/json), so an agent can ingest the entire 100+ method surface without scraping HTML.
- The llms.txt is present and genuinely useful — a compact, API-focused manifest with title, description, llm-allowed:all, and direct links to docs/FAQ/pricing — so an AI crawler is explicitly welcomed and pointed at the right pages.
- Error handling is agent-ready: the Recommendations-for-Developers page documents each concurrency/limit error code (7, 10, 14, 110, 107) with an explicit recovery action ('wait for a request to complete', 'contact us to upgrade', 'whitelist the IP'), so an agent knows what to DO on failure, not just that it failed.
- Capability boundaries are unusually honest — the docs state upfront what API2Cart does NOT do (no high-level tax/pricing logic), flag that method/parameter support varies per platform, and provide a platform comparison tool, so an agent won't assume a method works everywhere.
- The core reference is a JavaScript-rendered Swagger UI: an agent that can't execute JS or fetch the OpenAPI JSON sees an almost-empty page, and there is no AGENTS.md, llms-full.txt, .well-known/mcp.json, or MCP-registry listing to fall back on.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms-full.txt (or a static markdown mirror of the method reference) so agents that only fetch flat text — not the JS Swagger UI — still get the full endpoint catalogue; this is the single biggest discovery gap.
- 02List an official API2Cart MCP server on Glama, Smithery, and PulseMCP. A unified 60+ platform commerce API is a natural MCP tool, and a registry listing is how agent runtimes discover it today.
- 03Add an AGENTS.md to the primary GitHub repos (api2cart/php-sdk, cs-sdk, code samples) so coding agents get build/usage context; the org has active SDK repos but no agent instructions file.
- 04Ensure the OpenAPI spec is prominently linked from the docs landing page text (not only inside the Swagger widget) and referenced in llms.txt, so agents discover the machine-readable spec without rendering the interactive UI.
- 05Add a short 'core concepts in 5 minutes' overview (auth → connect store → first product.list → handle errors) to tighten token efficiency; today an agent must assemble that from several FAQ and recommendations pages.
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.
Auth is a single 32-character API key (api_key), plus a per-store store_key for connected carts; documented clearly in the getting-started FAQ and enforced as a Swagger securityScheme. Errors return a numeric return_code with a message, catalogued on a dedicated Response Status Codes page. Rate limits are explicit (10 parallel calls/account, 5 concurrent/store, 250 max list elements) with named error codes (7, 10, 14, 110). Pagination is offset-based via start/count. Idempotency keys are not mentioned.