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

GoCardless is Good to agents.

Discry independently scored how well an AI agent can discover and understand the GoCardless 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 · 71/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.Pass
llms.txt qualityThe llms.txt is focused, current, and well under the size budget.Partial
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.Fail
.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.Pass

Comprehension

55% of score · 87/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.Pass
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.Pass
Naming consistencyConsistent, predictable naming across endpoints.Partial
Heading hierarchyClean heading structure agents can navigate.Pass
Markdown docsDocs available as clean markdown, not JS-rendered HTML only.Pass
Token efficiencyDocs are concise enough to fit an agent context window.Partial

What we found

  • An agent can self-serve the entire API surface without scraping rendered HTML: GoCardless ships a downloadable OpenAPI spec (openapi-schema-public.json) AND a clean Markdown (.md) version of every documentation page, all indexed from a working llms.txt.
  • Every quickstart and guide provides copy-pasteable code in six languages (cURL, PHP, Python, Ruby, Java, Node) with realistic values and task-first framing ('Create your first test payment authorisation in 5 minutes') — an agent can lift working calls directly.
  • No agent-native discovery assets exist: no AGENTS.md in any gocardless GitHub repo, no llms-full.txt, and no .well-known/mcp.json — a coding or runtime agent gets no purpose-built guidance beyond the human docs.
  • The only MCP coverage is a community-built server (jmceleney/gocardless-mcp) listed on Glama; there is no official GoCardless MCP server, so registry-driven agents land on an unofficial integration.
  • GoCardless runs two doc conventions in parallel — the Pro payments API (snake_case JSON, structured error types) and the Bank Account Data API (status abbreviations like CR/GC, PascalCase error names like AccessExpiredError) — forcing an agent to context-switch between products.

What to change

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

  1. 01Publish llms-full.txt by concatenating the core guides and API reference Markdown — you already emit per-page .md, so this is a near-zero-effort fix that clears a failing discovery check.
  2. 02Add an AGENTS.md to the primary client-library repos (gocardless-pro-*) covering auth, sandbox setup, idempotency, and versioning — a rising standard that is currently a hard fail.
  3. 03Enrich llms.txt from a flat link dump into described, product-grouped sections (one-line purpose per link) to move llmsTxtQuality from partial to pass.
  4. 04Ship (or officially endorse) a GoCardless MCP server so registry-driven agents get a maintained integration instead of a community fork.
  5. 05Consolidate explicit 'what to do' error-recovery steps for the core Pro API — mirroring the strong Bank Account Data statuses page — so agents can self-correct across the whole product, not just one surface.

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 access token (Bearer)OAuth 2.0 (partner/connected apps) Error format documented Rate limits documented Pagination documented Idempotency documented

Strong execution documentation: bearer-token auth (plus partner OAuth), machine-parseable JSON errors with typed codes (e.g. validation_failed), idempotency via the Idempotency-Key header, cursor-based pagination (before/after + limit), and per-endpoint rate limits (e.g. 60 req/min; daily caps on the Bank Account Data API). Documented claims only — live behavior requires a full Discry Audit.

See your own Discry Score.

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

Discry your API — free