Escape is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Escape 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 · 48/100Comprehension
55% of score · 84/100What we found
- An agent can drive the entire platform without scraping HTML: Escape ships a valid, downloadable OpenAPI 3.1.0 spec at public.escape.tech/v3/openapi.json AND a hosted remote MCP server (mcp.escape.tech/mcp) with spec-compliant OAuth 2.1 PKCE auth — including a `public_api_answer_question` tool that grounds questions in the live spec and returns copy-pasteable cURL. This is unusually advanced agent-readiness.
- An agent looking for lightweight discovery signals comes up empty: llms.txt, llms-full.txt, and /.well-known/mcp.json all return 404, and no AGENTS.md exists in the Escape-Technologies GitHub org. Discovery leans entirely on the OpenAPI spec + robots/sitemap, dragging the discovery score to a D despite the strong underlying API.
- Documentation is written for task completion, not just reference: the Public API page is organized by outcome ('Retrieving API coverage in CI/CD', 'Enforcing a rate limit across many profiles', 'Validating authentication'), with poll-until-FINISHED loops and cookbook links. An agent can chain multi-step workflows without guessing.
- The hosted MCP server is not listed in any major MCP registry (Glama, Smithery, PulseMCP), so an agent doing registry-based discovery would not find it even though a production-grade server exists — a pure distribution gap, not a capability gap.
- Error handling is agent-parseable but not agent-recoverable: errors return typed JSON with a `message`, but the docs and spec stop at descriptions ('Not found', 'Pagination error') without telling an agent what to change to succeed on retry.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an API-focused llms.txt (and optionally llms-full.txt) at docs.escape.tech linking the Public API, MCP server, CLI, and quickstart pages — a cheap fix that would lift three discovery checks (llmsTxt, llmsTxtQuality, and materially help token efficiency) from fail toward pass.
- 02List the hosted Escape MCP server in Glama, Smithery, and PulseMCP so registry-based agents can discover it; the server already exists and is OAuth-compliant, so this is a distribution task, not engineering.
- 03Add an AGENTS.md to the primary public repos (cli, escape-rules, action) with build/test/usage context so coding agents working against Escape tooling get first-class guidance.
- 04Add actionable recovery guidance to error responses — e.g. name the offending parameter on 400s and specify Retry-After behavior on rate-limit responses — to move error-recovery from partial to pass.
- 05Include realistic multi-language request examples (not just cURL) in the Public API docs so agents generating client code in Python/JS have copy-pasteable, non-placeholder samples.
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.
Auth is well documented: static API-key header for the REST/CLI/CI path plus a spec-compliant OAuth 2.1 PKCE flow for the hosted MCP server. Error responses are machine-parseable JSON with a `message` field and typed codes (e.g. PaginationError, 404 Not found, coverage-status enums), but responses lack actionable recovery steps. Rate limits are configurable and documented (network.requests_per_second, range 1-1000, default 100). Pagination is cursor+size across list endpoints with realistic cursor examples. No idempotency-key mechanism is documented.