Kanta is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Kanta 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 · 50/100Comprehension
55% of score · 90/100What we found
- An agent that reaches the docs is exceptionally well served: kanta.readme.io ships a structured ~11KB llms.txt indexing every guide and all ~55 endpoints with task-oriented descriptions, plus a clean .md twin for every page and per-endpoint OpenAPI 3.0.0 definitions — comprehension scored 90/100 (A).
- But an agent trying to CRAWL Kanta hits a wall: the docs subdomain robots.txt returns 'User-agent: * / Disallow: /', blocking every bot (GPTBot, ClaudeBot, CCBot, Google-Extended) from the entire developer portal — a ReadMe default that directly contradicts the site's own 'For AI agents: visit llms.txt' banner. (The marketing site www.kanta.fr allows all, but the API docs are not hosted there.)
- Kanta ships an official first-party MCP server (Kanta-Inc/kanta-mcp-server, exposing API v1.1), listed on Glama, MCP Market and LobeHub — an agent looking for a ready-made Kanta tool would find one immediately.
- Endpoint docs are unusually agent-friendly: realistic multi-language examples (Shell/Node/Ruby/PHP/Python/Java/C#), env-var key handling, consistent snake_case, and explicit capability boundaries (120 req/min, 100-item page cap, metadata limits of 50 keys x 40/500 chars, deletable-state rules, 'Kanta templates cannot be deleted').
- No single downloadable OpenAPI file exists at standard paths (openapi.json/yaml and swagger.json all 404); the spec is fragmented across per-endpoint .md pages, so an agent must stitch it together rather than ingest one canonical contract.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix robots.txt on kanta.readme.io — replace the blanket 'Disallow: /' with rules that allow AI crawlers (GPTBot, ClaudeBot, CCBot, Google-Extended) to reach the docs. This is the single highest-impact discovery fix and would immediately lift the Discovery grade out of D.
- 02Publish a single canonical OpenAPI 3.0 spec at a stable URL (e.g. https://app.kanta.fr/api/v1/openapi.json) and link it from llms.txt — the per-endpoint definitions already exist, so consolidating them turns a PARTIAL into a PASS and lets agents ingest the whole contract in one fetch.
- 03Add 2-3 end-to-end workflow guides (e.g. 'Onboard a client: create customer by SIREN -> list recommended diligences -> attach & formalize -> download risk report') so agents can chain the excellent individual endpoints into real KYC/LCB-FT tasks.
- 04Expand error-recovery guidance beyond 401/403/429: document the top 400/422 validation failures per resource with the specific parameter at fault and how to correct it, plus a Retry-After header for 429, so agents can self-correct instead of guessing.
- 05Ship an AGENTS.md in the kanta-mcp-server repo (and/or a /.well-known/mcp.json on app.kanta.fr) to complete the agent-discovery surface now that a first-party MCP server already exists.
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 API-key model via the X-API-Key header, with documented 401/403/429 JSON error envelopes ({ error: { code, message } }). Rate limit is explicit (120 requests/minute per key, 429 on breach). Pagination is offset/page-based (page + per_page, max 100) and consistently returned in list envelopes (total_data, per_page, current_page, total_page). No idempotency keys are documented; some write operations note atomicity (e.g. bulk assignment is all-or-nothing) but there is no client-supplied idempotency mechanism.