◎ Discry Score
sonarsource.com
devtools · API
A
0 / 100
DISCOVERY0
COMPREHENSION0
Category leader: 96 (A)
Discry your API →
DEVTOOLS · RANK #6 OF 39

SonarSource is Agent-Ready to agents.

Discry independently scored how well an AI agent can discover and understand the SonarSource API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.

Discry your API — freeView the docs ↗

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/100
OpenAPI specA machine-readable OpenAPI/Swagger spec agents can parse.Pass
llms.txtAn llms.txt index that points agents to the docs that matter.Pass
llms.txt qualityThe llms.txt is focused, current, and well under the size budget.Partial
llms-full.txtA full-text bundle agents can load in one request.Pass
AGENTS.mdAn AGENTS.md that tells coding agents how to build on the API.Pass
.well-known/mcp.jsonA discoverable MCP manifest at a well-known path.Fail
MCP registryThe API is listed in a public MCP registry.Pass
robots.txt AI directivesrobots.txt allows (or explicitly guides) AI crawlers.Pass
SitemapA sitemap so agents can enumerate the docs surface.Pass

Comprehension

55% of score · 91/100
Task-oriented descriptionsEndpoints described by what they accomplish, not just their shape.Pass
Realistic examplesRunnable, real-world request/response examples.Pass
Multi-step workflowsDocs that chain calls into complete jobs an agent can follow.Pass
Error-recovery guidanceDocumented failure modes and how to recover from them.Partial
Answer-first formatThe answer leads; preamble does not bury it.Pass
Capability boundariesClear limits — what the API can and cannot do.Partial
Naming consistencyConsistent, predictable naming across endpoints.Pass
Heading hierarchyClean heading structure agents can navigate.Pass
Markdown docsDocs available as clean markdown, not JS-rendered HTML only.Pass
Token efficiencyDocs are concise enough to fit an agent context window.Pass

What we found

  • An agent discovering SonarSource lands in an unusually agent-native environment: robots.txt carries an explicit AI-crawler allow-list (GPTBot, ClaudeBot, anthropic-ai, CCBot, Perplexity, etc.) plus a Content-Signal: ai-train=yes header, so nothing blocks retrieval.
  • Documentation is machine-first by design — every page is available as clean markdown by appending .md, via Accept: text/markdown content negotiation, and a full llms-full.txt corpus export. Even the 404 page instructs agents to use a ?ask= natural-language query endpoint and sitemap.md index.
  • An agent looking for a machine-readable contract finds one: a valid OpenAPI 3.1 spec for Web API v2 (/api/v2/api-docs, 102 paths, 188 schemas) plus a hosted API reference portal (api-docs.sonarsource.com) and a self-documenting legacy webservices JSON with per-action descriptions, params, permissions, and response examples.
  • SonarSource is deeply invested in agent tooling: an official SonarQube MCP Server (listed on PulseMCP), AGENTS.md/CLAUDE.md in the sonarqube-cli repo, agent plugins for Claude Code/Cursor/Codex/Copilot, and an entire 'Agent Centric Development Cycle' documentation tree.
  • The main gap is operational, not discovery: rate limits and idempotency are not documented anywhere in the corpus, so an agent would only learn throttling limits by hitting them — the reason this scores A rather than a clean top of the range.

What to change

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

  1. 01Document rate limits and their response headers (limit, remaining, Retry-After) in the Web API appendix so agents can back off correctly instead of discovering limits by failing — this is the single biggest remaining gap.
  2. 02Add explicit error-recovery guidance for the top 5-10 error scenarios (e.g., what a 400 means per endpoint, how to resolve 401/403 permission failures, token-expiry handling) rather than relying on HTTP status codes alone.
  3. 03Publish a stable, versioned OpenAPI download URL (e.g., a documented /openapi.json) instead of only exposing the spec via a live instance's /api/v2/api-docs, so agents have a canonical, cacheable contract.
  4. 04Make the base-domain llms.txt API-aware — it currently lists only marketing/product pages with zero API references; adding a short 'API & developer docs' section pointing to the Web API and OpenAPI would tighten the discovery path.
  5. 05Document idempotency behavior for write endpoints (POST/PUT/PATCH) so agents can safely retry mutations without duplicating resources.

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.

Bearer token (personal access token)Scoped organization tokensOne-time agent-app tokensOAuth / DevOps platform SSO (login)✓ Error format documented✕ Rate limits documented✓ Pagination documented✕ Idempotency documented

The SonarQube Web API v2 ships a valid OpenAPI 3.1 spec (v2026.4, 102 paths, 188 schemas) that documents standardized HTTP error responses (400/401/403/500) per endpoint. Auth is bearer-token (personal, scoped-org, and one-time agent-app tokens), documented with realistic cURL examples. Legacy v1 endpoints use p/ps pagination and declare required permissions per action. Rate limits and idempotency keys are not documented; these are claims to confirm via a live Audit.

See your own Discry Score.

Drop your API docs URL. See what an agent sees — in 60 seconds, free.

Discry your API — free