PagerDuty is Poor to agents.

What we found

• —PagerDuty has the widest gap between comprehension quality (84/B) and discovery (23/F) — excellent docs exist but agents cannot find them through standard discovery channels.
• —The rate limit documentation is exemplary for agents: includes specific numbers (960 req/min), response headers (ratelimit-limit/remaining/reset), 429 response body format, and explicit retry best practices.
• —PagerDuty has a dedicated 'MCP Tooling & Remote Server' documentation page, indicating awareness of agent consumption, yet lacks the standard discovery files (llms.txt, robots.txt, sitemap) that would help agents find it.
• —The developer portal is entirely JS-rendered (Gatsby) with no static alternatives — robots.txt, sitemap.xml, and llms.txt all return empty responses, making the site invisible to crawlers and agents.
• —OpenAPI schemas exist at PagerDuty/api-schema on GitHub but are not linked from a discoverable location on the docs site.

What to change

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

1. 01Fix the Gatsby SSR issue: robots.txt, sitemap.xml must be server-rendered as static files — currently the entire developer portal is invisible to web crawlers and AI bots.
2. 02Add llms.txt with a structured overview of REST API, Events API v2, Webhooks, and key workflows — the content quality is already high, it just needs a discovery layer.
3. 03Add AGENTS.md to the PagerDuty/api-schema or pagerduty-api-python-client repos with authentication setup, common patterns, and integration guidance.
4. 04Create a sitemap.xml that covers all documentation pages — this alone would significantly improve discoverability.
5. 05Publish the OpenAPI spec at a well-known URL on the developer portal (e.g., developer.pagerduty.com/openapi.json) in addition to the GitHub repo.