Mercury is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Mercury 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 · 76/100Comprehension
55% of score · 87/100What we found
- An agent discovering Mercury lands on a first-class llms.txt: an API-focused, well-described index linking every guide, endpoint (as clean .md), recipe, and changelog entry — one of the strongest discovery surfaces a fintech API can present.
- Every API reference page ships a full inline OpenAPI 3.0.0 definition inside the .md variant (schemas, paths, security schemes), so an agent can extract a machine-readable contract per endpoint without hunting for a separate spec file.
- Task-oriented endpoint descriptions plus six end-to-end recipes (e.g. send-an-ACH: list accounts -> list recipients -> POST transaction -> idempotency key) give an agent real workflow chaining, not isolated endpoint stubs, in Ruby/Python/cURL/Node with realistic UUIDs and amounts.
- No consolidated OpenAPI file exists at conventional paths (/openapi.json 404) and no AGENTS.md is present in Mercury's GitHub org — an agent must reconstruct the full spec by walking per-page fragments, and coding-agent onboarding context is absent.
- Capability boundaries are unusually explicit for payments (acceptable-use restrictions, token permission tiers, IP-whitelist requirements, 1-1000 pagination limits, duplicate-transaction 24h rule) but no numeric rate limits or 429 recovery guidance are published, so an agent learns throttling limits only by hitting them.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a single consolidated OpenAPI spec at a conventional path (e.g. https://docs.mercury.com/openapi.json) so agents can load the whole contract in one fetch instead of stitching per-endpoint fragments — this is the largest remaining discovery gap.
- 02Add an AGENTS.md to the primary MercuryTechnologies GitHub repos with auth setup, base URL, token scopes, and idempotency conventions so coding agents get canonical build/integration context.
- 03Document rate limits explicitly — publish numeric limits, the rate-limit header names, and a 429 recovery pattern (respect Retry-After, back off) so agents can self-correct on throttling instead of failing blind.
- 04Standardize casing across the API surface: response and body fields are camelCase but query parameters use snake_case (start_after, end_before). Documenting this split prominently (or aligning it) prevents agent trial-and-error on parameter names.
- 05Expand per-error recovery guidance beyond idempotency: pair each documented 400 with which parameter failed and valid values, so agents can fix a rejected request without re-reading the whole schema.
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.
Mercury documents Basic/Bearer API-token auth plus an OAuth2 web flow, cursor-based pagination (limit/order/start_after/end_before), and a strong idempotency-key model with explicit retry semantics (409 on duplicate key). Error responses are documented per endpoint via inline OpenAPI (400/404) with contextual notes, but no numeric rate limits or rate-limit header names are published. These are documented claims only; live behavior is unverified in scan mode.