EMTECH is Poor to agents.

Item: EMTECH API
Rating: 47
Author: Discry

Discry independently scored how well an AI agent can discover and understand the EMTECH 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 — free View 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 · 12/100

OpenAPI specA machine-readable OpenAPI/Swagger spec agents can parse.Partial

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.Fail

.well-known/mcp.jsonA discoverable MCP manifest at a well-known path.Fail

MCP registryThe API is listed in a public MCP registry.Fail

robots.txt AI directivesrobots.txt allows (or explicitly guides) AI crawlers.Fail

SitemapA sitemap so agents can enumerate the docs surface.Fail

Comprehension

55% of score · 75/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.Partial

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 starting at emtech.com hits a dead end: the site's Developer menu labels 'API Documentation' as COMING SOON and links to '#', so the actual portal at developer.emtech.com is only reachable by guessing the subdomain — discovery signals give the agent no path in.
Once an agent reaches developer.emtech.com, the Beyond Compliance v3 reference is genuinely agent-usable: endpoint pages lead with method + URL + a task-oriented purpose ('Submit remittance transfer reports for regulatory compliance'), list required fields, enums, and realistic examples (TXN-2024-001234, GHS/NGN currencies, Accra/GH locations).
Zero machine-discovery affordances exist: no robots.txt, sitemap.xml, llms.txt, llms-full.txt, .well-known/mcp.json, AGENTS.md, or MCP-registry listing were found on either emtech.com or developer.emtech.com (the developer portal is an Azure Static Web App that 404s all of these).
The docs claim an OpenAPI 3.1.0 spec backs the reference and reference swagger-cli bundling, but no publicly fetchable openapi.json/yaml URL was found — an agent cannot download a machine-readable spec, only scrape the JS-rendered HTML reference.
Error recovery is a bright spot for authentication: a cause-and-fix table covers 400/401/403/415 with concrete remediation, but endpoint-level 429/500 responses lack equivalent 'what to do next' guidance, so an agent hitting a rate limit or server error has no documented recovery path.

What to change

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

01Fix the discovery dead end first: point the emtech.com 'API Documentation' menu item to https://developer.emtech.com (it currently links to '#'), and add cross-links so an agent crawling the marketing site can reach the portal without guessing the subdomain.
02Publish a downloadable OpenAPI 3.1.0 spec at a stable, discoverable URL (e.g. developer.emtech.com/openapi.json) — the spec already exists internally, so exposing it converts a scraped-HTML experience into a machine-consumable contract and upgrades the openApiSpec check from partial to pass.
03Add an llms.txt (and ideally llms-full.txt) at developer.emtech.com summarizing the products, auth flow, base URLs, and links to each API reference — a cheap, high-impact discovery win that lets agents grasp core capabilities in <5K tokens.
04Add a robots.txt and sitemap.xml to the developer portal so AI crawlers can enumerate the reference pages instead of relying on a JS-rendered SPA that exposes only three links to a mapper.
05Extend the excellent auth error table to every endpoint: document what an agent should DO for 429 (honor Retry-After / back off) and 500 (retry with correlationId), so self-correction isn't limited to the authentication step.

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.

OAuth 2.0API key (clientId/clientSecret) token exchangeBearer token via x-sandbox-app-auth header✓ Error format documented✓ Rate limits documented✕ Pagination documented✕ Idempotency documented

The Beyond Compliance v3 API documents an OAuth 2.0-inspired flow: exchange clientId/clientSecret at POST /integration/v1/auth/token for an accessToken passed via the custom x-sandbox-app-auth: Bearer header (v3 also references OAuth 2.0 with scopes compliance:read/write, reports:submit/read). Error responses are machine-parseable with documented status codes (400/401/403/415/429/500) and correlation IDs, and the auth page includes a cause + recommended-action table. Built-in rate limiting with quota management is stated but specific numeric limits and header names are not published. Batch processing (up to 100 items, all-or-nothing) is documented, but no cursor/offset pagination and no idempotency-key support are described. These are 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