incwo is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the incwo 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 · 12/100Comprehension
55% of score · 72/100What we found
- An agent CAN reach incwo programmatically today: incwo runs a live JSON-RPC MCP server at /mcp (explicitly allow-listed in robots.txt as 'AUTORISÉS pour les IA') and is listed as an official server on PulseMCP, Smithery, and the io.github.incwo registry namespace — unusually AI-forward for a French SMB ERP.
- Once an agent finds the docs, comprehension is solid: a single REST reference covers authentication, CRUD, universal filters, webhooks, and ~40 business objects with task-oriented endpoint descriptions and realistic copy-pasteable curl/Ruby examples (real-looking IDs, downloadable PHP and Rails sample apps).
- Discovery is the weak link: there is no llms.txt, no sitemap.xml, no .well-known/mcp.json, no AGENTS.md, and no OpenAPI/Swagger spec — an agent doing standard discovery would find nothing machine-readable, and robots.txt's blanket 'Disallow: /' actually blocks a crawler from reaching the developer docs.
- Rate-limit handling is a standout: the docs tell an agent exactly what to do on a 429 (honor Retry-After, back off exponentially, avoid retry-during-block penalties) — but this recovery quality is not extended to the other error codes, which are listed as bare numbers.
- The API is XML-first (.xml endpoints, XML payload examples), with JSON available but secondary — an agent defaulting to JSON must know to append .json, and there is no OpenAPI contract to auto-generate a client from.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an OpenAPI/Swagger spec (highest-weight discovery gap). The field-by-field object docs already exist per resource — exposing them as machine-readable openapi.json would let agents auto-generate typed clients and is worth the single biggest score jump.
- 02Add an llms.txt at incwo.com (and go.incwo.com) that names the product, links to https://www.incwo.com/site/developer, the /mcp endpoint, and the MCP registry entry. This is now table-stakes discovery and directly unblocks agents.
- 03Loosen robots.txt so the developer documentation path is crawlable by AI bots. The current 'Disallow: /' means an agent that finds the docs URL still can't fetch it under robots rules — carve out /site/developer alongside the existing /mcp allow-list.
- 04Add a .well-known/mcp.json pointing at the existing live /mcp server so MCP-aware clients can auto-discover it without relying on third-party registries or robots.txt comments.
- 05Extend the excellent 429 recovery pattern to the other errors: give 404/500 (and validation failures) actionable fix guidance (which field/id was wrong, whether to retry) instead of listing them as bare status codes.
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 HTTP Basic (per-user login/password activated in-app), with the API server address shown in the settings panel and a fixed source-IP range published. Errors are returned as HTTP status codes (200/201/404/429/500); the 429 rate-limit case is exceptionally well documented with a retry_after body field, the standard Retry-After header, and explicit exponential-backoff and progressive-penalty guidance. Rate limits are concrete (8/sec, 240/min, 4800/hr). Pagination is page-number based with a pagination block (current_page/total_pages). Responses are XML-first (.xml) with JSON supported (.json). No idempotency-key mechanism is documented.