apigee.local is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the apigee.local 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 · 43/100Comprehension
55% of score · 91/100What we found
- An agent that already knows Apigee exists can consume it cleanly: docs convert to tidy markdown, endpoint pages lead with the method, HTTP path and a task-oriented purpose, and a public machine-readable Google Discovery Document (OpenAPI-equivalent) is served at apigee.googleapis.com/$discovery/rest — comprehension scored an A (91).
- An agent trying to DISCOVER Apigee via agent-native signals finds almost nothing: no llms.txt, no llms-full.txt, no .well-known/mcp.json, no AGENTS.md in the github.com/apigee org, and no dedicated Apigee MCP server in Glama/Smithery/PulseMCP — discovery scored a D (43).
- Naming and structure are exemplary: fields follow Google AIP conventions (consistent camelCase, cursor pagination, resource-oriented paths), so an agent can predict field and parameter shapes it hasn't seen yet.
- Capability boundaries are explicit — a dedicated Apigee limits page plus documented quotas mean an agent learns constraints from the docs rather than by hitting 429s at runtime.
- Discoverability signals belong to the shared cloud.google.com domain, not Apigee specifically: robots.txt permits AI crawlers and a sitemap exists, but there is no Apigee-scoped agent entry point, so an agent has no compact, product-specific map to start from.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an Apigee-scoped llms.txt (e.g. under the /apigee/docs path or a product llms.txt) that links the get-started guide, the REST reference, the limits page, and the error/troubleshooting docs — the single highest-impact discovery fix given comprehension is already strong.
- 02Add an AGENTS.md to the primary public repos (github.com/apigee, GoogleCloudPlatform/apigee-samples) so coding agents get proxy-development context directly in-repo.
- 03Ship or register an official Apigee MCP server (or list an existing one) in Glama/Smithery/PulseMCP so agents can find and invoke Apigee management operations through a standard tool interface.
- 04Surface error-recovery guidance inline on the REST reference method pages (common failure codes + the fix), not only in separate troubleshooting playbooks, so an agent can self-correct without leaving the endpoint doc.
- 05Add a concise agent-oriented overview (or llms-full.txt) that compresses core management-API capabilities to <5,000 tokens; today an agent must stitch context across the large multi-product docs set.
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 is well documented: the management API uses OAuth 2.0 bearer tokens (gcloud/service-account), returns the standard machine-parseable Google JSON error model (google.rpc.Status with code/message/details), publishes explicit quotas and a dedicated Apigee limits page, and uses cursor-based pagination (pageToken/pageSize per Google AIP conventions). Idempotency keys are not explicitly documented for the management API.