emnify is Good to agents.
Discry independently scored how well an AI agent can discover and understand the emnify 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 · 62/100Comprehension
55% of score · 96/100What we found
- An agent arriving at docs.emnify.com is handed an explicit machine-readable welcome: an 'Instructions for AI Agents' block tells it to append '.md' to any URL for clean markdown, fetch per-section llms.txt indexes, and connect to a first-party MCP server at docs.emnify.com/_mcp/server. This is unusually agent-native and drives the A-grade comprehension.
- Comprehension is outstanding (96/A): the 510-page reference is OpenAPI(OAS3)-generated with task-oriented summaries, realistic JSON examples (real ICCIDs, IMSIs, IPs, timestamps), multi-language code samples (curl, Python, JavaScript, Go), and dedicated guideline pages for errors, rate limits, and pagination — an agent can understand and call the API with almost no guessing.
- Capability boundaries are documented with rare specificity: dedicated pages cover rate limits (2,000/IP/5min, 10M/account/month, per-path caps), the JSON error model with a full error-code catalog, and pagination semantics (page/per_page + Link/X-Total-* headers) — an agent rarely has to discover a limit by failing.
- Discovery is dragged to a C by machine-readable gaps despite the agent-friendly surface: no AGENTS.md in the emnify GitHub org, no .well-known/mcp.json, no listing in Glama/Smithery/PulseMCP, and llms-full.txt is just a byte-identical copy of the llms.txt index rather than a full content dump.
- The raw OpenAPI spec is not publicly downloadable: the interactive reference is fully browsable and OAS3-derived, but the spec file itself sits behind auth (cdn.emnify.net returns 'Missing Authentication Token') and docs.emnify.com/openapi.json returns the app shell — an agent cannot fetch a canonical spec to auto-generate a client.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a single canonical OpenAPI 3.x spec at a stable, unauthenticated URL (e.g. docs.emnify.com/openapi.yaml or a raw file in the emnify/doc repo) and link it from llms.txt. The docs are already OAS-generated — exposing the source spec flips the highest-weighted discovery check (openApiSpec, weight 5) from partial to pass and lets agents load the whole surface in one request.
- 02Add an AGENTS.md to the docs root and primary public repos (emnify-sdk-python, emnify-sdk-java, doc) pointing to docs.emnify.com, the .md/llms.txt conventions, the base URL, and the MCP server. This is a weight-3 discovery win and a rising standard for coding agents.
- 03List the existing first-party MCP server (docs.emnify.com/_mcp/server) in Glama, Smithery, and PulseMCP, and add a .well-known/mcp.json manifest at the docs root. emnify already runs the server — registering it converts two failing discovery checks (mcpRegistry, wellKnownMcp).
- 04Make llms-full.txt a genuine full-content dump (inline auth, errors, rate limits, pagination, and core concepts) instead of a copy of the llms.txt index, so agents can load complete context in a single fetch.
- 05Surface per-endpoint error-recovery guidance in the auto-generated reference pages (or link each page to the central errors and rate-limits guides), so an agent hitting a specific endpoint's error gets recovery steps in place rather than only in the guidelines section.
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.
Execution characteristics are documented thoroughly on dedicated API-guidelines pages. Auth is JWT-based (recommended application tokens for M2M, plus user credentials and MFA/OTP). Errors return a machine-parseable JSON body (error_code, error_token, message) with nested field-level validation errors and a catalogued error-code list. Rate limits are documented precisely (2,000 calls/IP/5min, 10M/account/month, plus per-path limits) with an explicit 429 + exponential-backoff / 100ms-delay recovery example. Pagination is fully documented (page/per_page query params with Link, X-Total-Count and X-Total-Pages response headers). Idempotency keys are not documented. Base URL is https://cdn.emnify.net.