Edera is Needs Work to agents.

What we found

• —An agent trying to operate Edera would succeed quickly: the docs are exemplary CLI/runtime documentation — task-oriented command descriptions, copy-pasteable YAML and bash with realistic UUIDs and IPs, a per-page 'Copy Markdown for LLMs' button, and clean H1->H2->H3 structure. Comprehension scored 96/100 (A).
• —An agent looking for a machine-readable API contract would come up empty: no OpenAPI/Swagger spec exists at any common path (all 404). This is expected for a CLI-and-Kubernetes-runtime product rather than an HTTP API, but the absence still removes the single highest-weighted discovery signal, which is the primary drag on the overall score.
• —An agent that needs to recover from failures is unusually well served: the troubleshooting docs go beyond listing symptoms — OOMKilled is explained with causes and concrete fixes, debug logging is spelled out step by step, and `edera-check postinstall` generates a diagnostic bundle. Error-recovery guidance passed, which is rare.
• —An agent crawling for discovery signals would find strong LLM-facing infrastructure: a well-structured llms.txt (7.9KB index with titles, content types, difficulty, and concept tags), a complete 662KB llms-full.txt regenerated 2026-06-24, and a full docs sitemap. But it would find no AGENTS.md, no .well-known/mcp.json, and no MCP registry listing.
• —An agent respecting robots.txt would be allowed in as an assistant (explicit catch-all Allow plus a comment naming AI assistants), but training/scraper crawlers CCBot and Amazonbot are explicitly blocked — so the robots posture is welcoming to interactive agents but partial by the rubric's AI-bot criteria.

What to change

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

1. 01Add an AGENTS.md to the primary edera-dev repos (krata, am-i-isolated, learn) with orientation for coding agents — repo layout, how the `protect` CLI maps to the codebase, and build/test entry points. This is a rising-standard discovery signal (weight 3) currently scoring zero and is a fast win.
2. 02Publish a machine-readable command/config contract to compensate for the absent OpenAPI spec (the top discovery weight). Even a generated JSON/YAML schema of the `protect` CLI command tree and the pod annotations (dev.edera/cpu, runtimeClassName) would give agents a structured surface to plan against.
3. 03Add a consolidated capability-boundaries reference: a single page enumerating what Edera supports and does not (supported cloud/kernel/GPU matrices, known limitations, version-gated features), so an agent learns limits by reading rather than by failing. Today boundaries are scattered across comparison and version-note pages.
4. 04Ship a .well-known/mcp.json or list an Edera MCP server in a major registry (Glama, Smithery, PulseMCP). With docs this clean, exposing the `protect` operations as MCP tools would make Edera directly agent-invocable and capture two currently-failing discovery signals.
5. 05Reconsider blocking CCBot and Amazonbot in robots.txt if broad AI reachability is desired; allowing them (while keeping true scraper/SEO bots blocked) would move the robots.txt check from partial to pass.