◎ Discry Score
luno.com
payments · API
C
0 / 100
DISCOVERY0
COMPREHENSION0
Category leader: 94 (A)
Discry your API →
PAYMENTS · RANK #17 OF 25

luno is Needs Work to agents.

Discry independently scored how well an AI agent can discover and understand the luno API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.

Discry your API — freeView the docs ↗

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 · 62/100
OpenAPI specA machine-readable OpenAPI/Swagger spec agents can parse.Pass
llms.txtAn llms.txt index that points agents to the docs that matter.Fail
llms.txt qualityThe llms.txt is focused, current, and well under the size budget.Fail
llms-full.txtA full-text bundle agents can load in one request.Fail
AGENTS.mdAn AGENTS.md that tells coding agents how to build on the API.Pass
.well-known/mcp.jsonA discoverable MCP manifest at a well-known path.Fail
MCP registryThe API is listed in a public MCP registry.Pass
robots.txt AI directivesrobots.txt allows (or explicitly guides) AI crawlers.Pass
SitemapA sitemap so agents can enumerate the docs surface.Partial

Comprehension

55% of score · 69/100
Task-oriented descriptionsEndpoints described by what they accomplish, not just their shape.Pass
Realistic examplesRunnable, real-world request/response examples.Pass
Multi-step workflowsDocs that chain calls into complete jobs an agent can follow.Fail
Error-recovery guidanceDocumented failure modes and how to recover from them.Partial
Answer-first formatThe answer leads; preamble does not bury it.Pass
Capability boundariesClear limits — what the API can and cannot do.Partial
Naming consistencyConsistent, predictable naming across endpoints.Pass
Heading hierarchyClean heading structure agents can navigate.Pass
Markdown docsDocs available as clean markdown, not JS-rendered HTML only.Partial
Token efficiencyDocs are concise enough to fit an agent context window.Partial

What we found

  • An agent looking to operate the Luno exchange is unusually well-served on tooling: Luno ships an OFFICIAL MCP server (github.com/luno/luno-mcp) advertised on its own API landing page ('Give your AI agent access to the Luno API'), plus community MCP servers and an mcpmarket.com listing — discovery of an agent entry point is a solved problem.
  • A coding agent working in Luno's SDKs finds a high-quality AGENTS.md in luno-python covering project architecture, the request/response flow, auth pattern, error shape, and git workflow — well above the generic-boilerplate norm.
  • Endpoint docs are genuinely task-oriented ('Create account allows users to create accounts for trading') with realistic, copy-pasteable examples in seven languages (Go, Java, Node.js, PHP, Python, Ruby, Haskell) and strictly consistent snake_case naming — an agent can generate correct calls on the first try.
  • The single biggest gap for an autonomous agent is workflow guidance: the reference documents endpoints in isolation with no end-to-end guides (e.g. create key -> fund account -> place order -> poll status), so an agent must infer how to chain operations for a real task.
  • No llms.txt / llms-full.txt and no content-negotiated markdown: the entire reference is one ~100KB Swagger-style HTML page, so an agent pays a large token cost and has no progressive-disclosure entry point despite the content itself being well-structured.

What to change

Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.

  1. 01Add an llms.txt at the site root pointing to the API reference, the Swagger file, the SDK repos, and the MCP server — a cheap discovery win that also unlocks the llms.txt-quality signal (currently both auto-fail).
  2. 02Publish 2-3 multi-step workflow guides (e.g. 'Place and manage your first trade: create key -> check balances -> post order -> poll order status -> handle fills') so agents can chain endpoints without guessing.
  3. 03Expand error documentation into recovery guidance: for the top error_codes, state what an agent should DO (e.g. on 429, back off using the 300/min budget; on ErrUnauthorized, regenerate/scope the API key), not just the code and message.
  4. 04Expose the OpenAPI/Swagger file at a stable, linkable URL (e.g. /en/developers/api/openapi.json) rather than a JS-rendered download button, so agents and tooling can fetch the machine spec directly.
  5. 05Offer the reference as clean markdown (content negotiation or a /llms-full.txt mirror) and add a concise capabilities/limitations overview so core capabilities are graspable in <5K tokens instead of parsing the full single-page reference.

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.

API Key (HTTP Basic Auth, key_id + key_secret) Error format documented Rate limits documented Pagination documented Idempotency documented

Auth is a single, clearly-documented method (HTTP Basic Auth with an API key id/secret). Errors return machine-parseable JSON (e.g. {"error_code":"...","error":"..."}) with named codes. Rate limits are explicit (300 calls/min, HTTP 429 on overage). Pagination uses limit + a `before` cursor parameter. Idempotency keys are not documented.

See your own Discry Score.

Drop your API docs URL. See what an agent sees — in 60 seconds, free.

Discry your API — free