Methodology

Docs Lens is a free utility for people who maintain documentation. This page explains what it checks, how it checks, and what it deliberately doesn't do.

What Docs Lens measures

When an AI coding agent, an answer engine, or a RAG chunker reads your documentation, different things happen to your content. Docs Lens runs 28 deterministic checks that simulate what each of those readers experiences, then produces three short narrative readings, one per reader type.

The three axes

  • Agent Retrieval
    Can Claude Code, Cursor, and Copilot fetch and parse your content?
  • GEO, Generative Engine Optimization
    Can Perplexity, ChatGPT Search, and Google AI Overviews cite you?
  • Context Management
    Does your content survive truncation, conversion, and chunking?

How the scan works

Every scan follows the same pipeline, in this order:

  1. Fetch. We GET your URL using undici, capture the full redirect chain, and record response headers and body length.
  2. Convert. We run the HTML through cheerio (to strip scripts, styles, SVGs) and then turndown to produce the markdown an agent on the HTML path would receive.
  3. Analyze. 28 checks run. Some are HTTP probes (/llms.txt, /.well-known/*, soft-404 test). Some are content analyses (page size, content-start position, heading hierarchy). Some are structural (code fence validity, JSON block parseability). All are deterministic: same input, same result.
  4. Observe.The scan result feeds a small editorial engine that produces the three narrative paragraphs. That engine is the closest thing to "opinion" in the system, and it lives at src/lib/observations.ts, readable in one sitting.

What Docs Lens does not do

  • No LLMs in the scan path. Nothing we do requires a model call. No API keys, no prompts, no inference costs. Same URL run twice returns the same result, byte for byte.
  • No authenticated access. Docs Lens never sends credentials, never follows an auth redirect into a credentialed page, and never attempts to bypass a login wall. If your docs are behind auth, we note it and stop.
  • No user tracking.No cookies, no analytics, no fingerprinting. Scan history is stored in your browser's localStorage; we don't see it.
  • No scoring as hero. Docs Lens produces a grade under the hood (for the share card only), but the user-facing result is prose, not a letter. The grade exists for virality; the reading exists for action.

Where our checks come from

Docs Lens combines three sources, cited per-check in the "why this matters" panel:

  • AFDocs v0.3.0. The Agent-Friendly Documentation Specification by Dachary Carey. Open-source, MIT. 22 of our checks trace to AFDocs.
  • Web platform RFCs. RFC 9727 (API Catalog), RFC 8288 (Link headers), RFC 9309 (robots.txt), CommonMark. Used for checks about capability discovery.
  • EkLine additions. Heading hierarchy, image alt coverage, metadata completeness, JSON block validity, internal link integrity, prose quality. These sit at the intersection of accessibility, RAG-friendliness, and answer-engine optimization. No existing spec covered them together.

Agent truncation thresholds

The per-agent profile dropdown is not an LLM call. It's a static table of empirical truncation limits. These numbers come from public reverse-engineering of each platform's fetch pipeline.

AgentTruncation threshold
Claude Code~100,000 chars
Cursor (WebFetch MCP)~28,000 chars
MCP Fetch (default)5,000 chars
Claude API (web_fetch)~20,700 chars
GitHub CopilotNo fixed cap detected

Who made this

Docs Lens is made by EkLine, a documentation tooling company for engineering teams. We built this as a free contribution to the docs community. No upsell, no lead form, no paid tier. If it's useful, tell a docs-team lead you know.

Free, deterministic, no LLMs in the scan path. 28 checks across 3 axes.