Kong is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Kong 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 · 90/100Comprehension
55% of score · 96/100What we found
- An agent discovering Kong would land on a best-in-class map: developer.konghq.com serves an llms.txt (133 sections) that indexes every documentation page as an LLM-optimized Markdown link, with a dedicated API Reference section pointing to ~40 publicly downloadable OpenAPI 3.0.3 specs — discovery is effectively frictionless.
- Kong explicitly welcomes AI agents: its docs robots.txt carries a Content-Signal header declaring ai-input=yes and ai-train=yes, and it publishes a genuinely useful AGENTS.md (in Kong/insomnia) plus a dedicated Kong/ai-marketplace repo of packaged agent skills — a rare, deliberate investment in agent-readiness.
- Every documentation page is available as clean Markdown with structured frontmatter and a TL;DR answer-first block; capability pages ship comparison matrices, version gating (min_version, v3.12+ tags), and mermaid decision flowcharts — an agent can reason about what the platform can and cannot do without trial-and-error.
- Task examples are exceptional: each plugin/feature page provides copy-pasteable, realistic examples across five tools at once (decK YAML, Admin API curl, Konnect API curl, Kubernetes KIC, Terraform HCL) with placeholder-substitution guidance — an agent has multiple valid execution paths for the same task.
- The main friction is scale: Kong spans Gateway, Konnect, AI Gateway, Mesh, KIC and 100+ plugins, so an agent must first resolve which product surface a task belongs to before the (otherwise efficient) per-topic docs pay off. Low-level Admin OpenAPI operation descriptions are also terse ('list realms') compared to the richly task-oriented how-to and plugin pages.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an llms-full.txt (currently 404 on both konghq.com and developer.konghq.com). The llms.txt index is excellent, but a single concatenated full-content file would let RAG pipelines ingest core capabilities in one fetch instead of crawling hundreds of per-page .md links.
- 02Publish a .well-known/mcp.json declaring Kong's MCP/agent-gateway tool surface and auth. Kong already ships an MCP Registry product and Agent Gateway, so a machine-discoverable manifest at the well-known path is a natural, high-signal addition that no competitor has.
- 03Enrich the low-level Konnect Admin API OpenAPI descriptions beyond tautologies ('create realm' -> 'Create a consumer realm to centrally manage credentials across multiple control planes'). The plugin/how-to docs are task-oriented; propagate that quality into the raw specs agents parse programmatically.
- 04Add a compact per-product 'core capabilities' overview (<5k tokens each) at the top of the llms.txt so an agent can quickly disambiguate Gateway vs. Konnect vs. AI Gateway vs. Mesh before diving into topic pages, improving token efficiency for first-contact reasoning.
- 05Consolidate error-recovery guidance into a machine-readable section (e.g., document Retry-After behavior and canonical fixes for common 4xx responses on the API reference pages themselves), rather than scattering it across product-specific troubleshooting and failure-mode guides.
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 thoroughly documented. The Konnect management API uses Bearer PAT auth, returns machine-parseable JSON errors with documented BadRequest/NotFound schemas in every OpenAPI spec, and uses cursor pagination (page_size/page_before/page_after). Rate limiting is documented exhaustively as a first-class product capability with concrete window examples. Idempotency keys are not prominently documented for the management API.