Gravitee is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Gravitee 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 · 76/100What we found
- An agent looking for Gravitee would find it easily: gravitee.io ships a deliberately agent-oriented llms.txt (with per-link priorities, tags, descriptions, and a machine-readable corpus pointer) alongside a separate docs-focused llms.txt on GitBook — one of the more intentional discovery setups seen in this cohort.
- Gravitee publishes a real AGENTS.md in its primary repo (gravitee-io/gravitee-api-management) with structured, stack-aware guidance (.agent-rules/, nested per-module rules) for coding agents — a rising standard most APIs still lack.
- Docs are natively agent-consumable: every GitBook page exposes a .md version via content negotiation and the docs robots.txt explicitly signals 'ai-train=yes, search=yes, ai-input=yes', so an agent can ingest clean markdown without scraping rendered HTML.
- The core gap is the API contract itself: there is no publicly hosted OpenAPI spec at a canonical URL (the Management API self-documents only on a running instance) and no /.well-known/mcp.json, so an agent cannot machine-discover the endpoint contract without deploying Gravitee.
- Content skews to marketing: the 897KB llms-full.txt corpus leads with positioning statements and buyer messages rather than API usage patterns, and code examples are config-format (JSON/YAML) rather than multi-language, copy-pasteable request snippets.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish the Management API OpenAPI spec at a stable public URL (e.g., documentation.gravitee.io/openapi.json) so an agent can retrieve the endpoint contract without standing up a Gravitee instance — the single biggest discovery gap.
- 02Add /.well-known/mcp.json declaring Gravitee's MCP-related capabilities and list a Gravitee entry on a major MCP registry (Glama, Smithery, or PulseMCP) to capture agent-registry discovery.
- 03Rebalance llms-full.txt toward API usage patterns (auth flows, endpoint examples, error handling) rather than positioning and buyer messaging, so the ingested corpus teaches an agent how to use the API rather than how it is sold.
- 04Add multi-language, copy-pasteable request examples (curl plus one or two SDKs) with realistic values on endpoint and policy pages to lift the realistic-examples and endpoint-description signals.
- 05Expand error tables with explicit recovery steps (what to change on a 400 OAS_VALIDATION_ERROR, how to react to a 429) to convert human-readable error docs into agent-actionable self-correction guidance.
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.
Gravitee documents multiple auth schemes as consumer 'plans' (API Key, OAuth2, JWT, Basic, Keyless) and its Management API uses bearer tokens. Policy pages carry structured error tables (phase, HTTP code, error key, description) and rate limiting is documented extensively via dedicated Rate Limit and AI Token Rate Limit policies. Pagination and idempotency for the Management REST API are not prominently documented. These are documented claims — live behavior requires a full Discry Audit.