GameScorekeeper is Not Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the GameScorekeeper 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 · 19/100Comprehension
55% of score · 43/100What we found
- An agent could reach the docs but not discover them programmatically: there is no llms.txt, no OpenAPI/Swagger spec, no .well-known/mcp.json, and no MCP-registry listing anywhere, so the API is invisible to agent-native discovery paths. The only machine-readable entry point is a single 68K-token HTML reference page.
- The reference data itself is agent-friendly where it counts: response examples use real values (competition 'BLAST Premier: Spring Groups 2022', teams 'Natus Vincere'/'Astralis', Unix-ms timestamps), field naming is consistently camelCase, and every endpoint section leads with its path and a one-line purpose.
- There are zero request examples in any language — no curl/python/js snippets. An agent sees realistic response shapes but has to infer how to construct the actual authenticated call, raising the odds of a malformed first request.
- Error handling is a dead end for self-correction: only 401 (prose) and 200/404 (on the historic-live endpoint) are documented, with no 429/500 coverage, no rate-limit headers, and no 'what to do when it fails' guidance. An agent hitting an error would have to guess the fix.
- The documentation is pure reference with no tutorials or end-to-end workflows. An agent must assemble the sports → competitions → fixtures → fixture → live-socket chain itself, because no guide walks through auth, connect, retrieve, and handle as a sequence.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an OpenAPI/Swagger spec at a stable URL (and link it from the docs). This is the single highest-impact fix — it makes every endpoint, parameter, and schema machine-consumable and unlocks client generation, spec-driven discovery, and MCP wrappers in one move.
- 02Add an llms.txt (and ideally llms-full.txt) at both gamescorekeeper.com and docs.gamescorekeeper.com describing the API's purpose, base URLs, auth model, and links to the key endpoint families. Right now the docs subdomain returns 403 for every discovery path.
- 03Add request examples in multiple languages (curl + at least one SDK-style language) to every endpoint, using the same realistic values already present in the response examples, so an agent can copy-paste an authenticated call rather than infer it.
- 04Document errors as a real table with recovery guidance: cover 401/403/429/500, specify rate-limit header names, and state the action for each (e.g. 'on 429, back off and retry'). Pair this with a machine-parseable JSON error envelope.
- 05Add 2-3 end-to-end workflow guides (e.g. 'authenticate → find a fixture → open the live WebSocket → handle events') and a compact endpoint index at the top of the reference to cut the token cost of understanding core capabilities.
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 auth on REST/Image endpoints, with the same token replayed over a WebSocket auth handshake for the Live API; tokens are issued manually via a sales contact (no self-serve key). Soft rate limits (1,000 req/hr REST, one socket per fixture) and page-based pagination (page/pageCount) are documented, but there is no machine-parseable JSON error envelope, no error-code table beyond 401/404, and no idempotency support.