diff --git a/ai/agent-readiness-checks.mdx b/ai/agent-readiness-checks.mdx new file mode 100644 index 000000000..bfe68bbd7 --- /dev/null +++ b/ai/agent-readiness-checks.mdx @@ -0,0 +1,491 @@ +--- +title: "Agent readiness checks" +description: "What each Agent Rank check tests, why it matters, and how to make your documentation more agent friendly." +keywords: ["agent rank", "agent friendly"] +--- + +[Agent Rank](https://agentrank.io) scores your documentation site on how accessible it is to AI agents. This page explains what each agent readiness check tests, why it matters, and how to make your documentation more agent friendly. + +## How scoring works + +Agent Rank weights and organizes checks into a tree. Some checks depend on others, so they only run if their parent check passes. + +For example, if your site has no `llms.txt` file, none of the checks that evaluate the contents of `llms.txt` run and you cannot get any points from them. + +Focus on passing parent checks first to make the biggest improvements to how accessible your documentation is to agents. + +| Category | What it checks | Weight | +| --- | --- | --- | +| llms.txt | Does an `/llms.txt` file exist, follow the spec, and link to Markdown versions of pages? | 17 | +| llms-full.txt | Is there a bundled, well-structured corpus agents can ingest in one request? | 8 | +| skill.md | Does the site expose agent skills? | 8 | +| Markdown content negotiation | Can the server return clean markdown when an agent asks for it? | 10 | +| Plaintext content negotiation | Can the server return clean plaintext as a fallback? | 5 | +| MCP server | Is there a discoverable MCP server? Does it expose tools? | 20 | +| OpenAPI spec | Is there a machine-readable API specification at a standard path? | 12 | +| robots.txt allows AI agents | Does `robots.txt` allow AI crawlers? | 8 | +| Sitemap | Is there a discoverable, valid `sitemap.xml`? | 5 | +| Structured data | Does the homepage embed JSON-LD? | 4 | +| Response latency | Does the site respond in less than two seconds? | 3 | + + + Every check includes a ready-to-use prompt for improving your documentation and passing the check and any dependent checks. + + Click **Copy prompt** and paste it into your preferred tool to make your documentation more accessible to agents. + + +## llms.txt + +This check fetches `/llms.txt` from your domain and fallback paths including `/.well-known/llms.txt`. The check passes if it can reach an `llms.txt` file with non-HTML text content. + +Mintlify generates and hosts an `llms.txt` file for every documentation site. See [llms.txt](/ai/llmstxt) for customization options. + +**Why this check matters:** `llms.txt` gives agents a standard starting point for discovering your documentation before crawling or guessing at navigation. + +**How to improve:** If you use a [reverse proxy](/deploy/reverse-proxy), configure it to forward `/llms.txt` and `/.well-known/llms.txt` to your Mintlify subdomain. If you host your docs outside Mintlify, create an `llms.txt` file at the root of your site. + + +Generate an `llms.txt` file for my documentation site that fully adheres to the [llms.txt format specification](https://llmstxt.org#format). + +Requirements: +- The file must begin with a `#` heading containing the site title. +- Immediately below the title, add a blockquote (`>`) with a concise site description. +- For navigation, include one or more `##` section headers that match the site's main navigation structure. +- Under each section, list every documentation page as a Markdown link to its `.md` version immediately followed by a short description of the page content ([Page Title](https://example.com/docs/page.md): Description of the page contents). +- Ensure page list and hierarchy accurately reflect the docs site's structure. +- Use clear, specific, human-readable descriptions for each page. +- Output only the content of the `llms.txt` file—do not provide explanations or commentary. + +This file should be ready to serve at the site root, be valid plain text, and follow all required structural and formatting conventions. + + +### llms.txt valid structure + +The file must contain at least one Markdown link in `[text](url)` format. + +**Why this check matters:** Without links, `llms.txt` cannot direct agents to your content. + +**How to improve:** Mintlify-generated files always include links. If you use a custom file, ensure it contains links for each page using the `[Page Title](url)` format. + + +Review my llms.txt file and add a `[Page Title](url): Description of the page contents` style Markdown link for every documentation page that is missing. Each link must point to the `.md` version of the page, use a clear, human-readable title, and include a concise description of the page content. Make sure no documentation page is omitted, and that the format matches the llms.txt specification exactly. + + +### llms.txt size + +The `llms.txt` file must be under 100,000 characters. The check flags files over 50,000 characters as a truncation risk because agents don't reliably process long files. + +**Why this check matters:** Oversized files may be truncated by agents with limited context windows, causing them to miss pages listed toward the end. + +**How to improve:** If you have a large custom `llms.txt`, trim it to the most important pages. Use `llms-full.txt` for the complete content corpus. + + +Review my `llms.txt` file if it exceeds 50,000 characters and optimize it to be well under this threshold. + +Prioritize keeping: +- High-level overview pages +- Onboarding and "get started" docs +- API reference index and section entry points +- Pages that are essential for agents to understand site structure + +Consider removing or moving to a final `## Optional` section: +- Deeply nested and less-visited sub-pages +- Pages with redundant or highly similar content +- Changelog, release notes, or historical archives + +Return a revised, specification-compliant `llms.txt` that maintains coverage of the most important and frequently referenced content, structured for clarity and optimal agent ingestion. + + +### llms.txt links resolve + +This check samples up to 50 same-origin links. At least 90% must properly resolve and return `HTTP 200` status codes. + +**Why this check matters:** Broken links mean agents cannot reach content. + +**How to improve:** Mintlify-hosted `llms.txt` update each time you make a change to your site. For custom `llms.txt` files, audit links and fix renamed, moved, or deleted entries from your custom `llms.txt`. + + +Audit all links in my llms.txt file to find any that lead to missing or relocated pages. For each broken or outdated link you find, recommend the best action: update the link to the correct URL if the page has moved, restore the missing page if it should exist, or remove the entry if it is obsolete. Summarize your findings and provide the exact changes required to keep llms.txt accurate and up to date. + + +### llms.txt links point to Markdown + +At least half of the links in `llms.txt` must end in `.md`. + +**Why this check matters:** `.md` links let agents fetch the Markdown version of a page directly, which is more token-efficient than parsing HTML. + +**How to improve:** Mintlify-generated `llms.txt` always uses `.md` links. If you have a custom file, append `.md` to your page URLs. + + +Review the provided `llms.txt` for documentation links. + +**Objective:** Every link to documentation content should end with `.md` (the raw Markdown source), unless the destination is intentionally non-Markdown (e.g., an external site, API endpoint, or other non-doc resource). + +**Instructions:** +- For each documentation link that does not end in `.md`, update the URL to point to the corresponding `.md` file—typically by inserting `.md` before any query string or fragment, while avoiding double slashes. +- Do not alter links that already end with `.md`. +- Do not modify the visible link text, list structure, or any section headings. +- For any link that cannot be safely rewritten (e.g., its target is ambiguous, external, or requires human judgment), add it to a clearly marked “Needs review” section, and briefly state why. + +After making these changes, provide: +1. The full revised `llms.txt` file. +2. A concise summary with: + - Total number of links processed + - The count (and percentage) that now end with `.md` + - A list of any links that require manual review. + + + +### llms.txt directive format + +The file must start with an H1 title like `# Site name` and include an H2 section heading like `## Docs` or `## Documentation`. + +**Why this check matters:** This structure follows the `llms.txt` specification, which agents use to parse the file predictably. + +**How to improve:** Mintlify-generated `llms.txt` files have these headings. For custom files, ensure the first non-empty line is an H1 like `# Site name` and the main page list appears under an H2 heading like `## Documentation`. + + +My `llms.txt` file does not comply with the required [llms.txt format](https://llmstxt.org#format). Please rewrite it so that: + +1. The first non-empty line is an H1 heading with the exact site name in the form: `# Site Name` +2. The H1 is immediately followed by a single blockquote line summarizing the site, like: `> Brief description of the site` +3. All documentation links are grouped under an H2 section titled `## Documentation` + +**Instructions:** +- Keep all existing page links, titles, and content—just reorganize them into the correct heading and section structure. +- Do not edit link URLs or titles. +- Do not add or remove any links or content besides required headings. +- If any required section (H1, blockquote, `## Docs`) is missing, add it in the appropriate place. +- Ensure there is exactly one H1 at the top, followed by a blockquote, then the `## Docs` section with all page links directly beneath. + +Output only the full, fixed `llms.txt` file that passes the format requirements. + + +## llms-full.txt + +This check fetches `/llms-full.txt` from your domain and verifies it is reachable, returns a text content type, is non-empty, and is not HTML. + +Mintlify automatically generates and hosts `llms-full.txt` for every documentation site. See [llms.txt](/ai/llmstxt#llms-fulltxt) for details. + +**Why this check matters:** A single-file corpus allows long-context agents to ingest your entire documentation in one pass without making individual page requests. + +**How to improve:** Mintlify-generated `llms-full.txt` files update each time you make a change to your site. For custom `llms-full.txt` files, ensure the file is updated to include the full content of each page. If you use a reverse proxy, forward `/llms-full.txt` and `/.well-known/llms-full.txt` to your Mintlify subdomain. + + +You have access to my entire documentation source (MDX/Markdown files). Generate a `llms-full.txt` file that: + +1. Starts with an H1 heading with the exact site name (from my `docs.json`), with no extra text. +2. Includes a blockquote with a concise, plain-language description of the site. Use the `description` field from my `docs.json` if present. Otherwise, generate a concise description of the site. +3. Is followed by the **full content** of every public documentation page that should be in the agent corpus. + - Each page's content should be preceded by a top-level heading (`###`) that matches the page title. + - If available, include frontmatter `title` and `description` as part of each section. +4. Has a total length between 500 and 5,000,000 characters. +5. Does **not** include duplicate pages, boilerplate, or irrelevant internal/experimental content. +6. Contains at least two Markdown headings overall, including the initial H1. + +**Instructions:** +- Source only content from the current published documentation and linked pages. +- Ensure Markdown is original and clean—do not pad with meaningless text. +- Only include Markdown. There should be no HTML, JS, or other non-Markdown content. +- Separate each page's content cleanly with `###` headings for navigation. +- The file should be suitable for direct upload and ingestion by LLMs. + +When done, report the character count and confirm it is within the 500-5,000,000 character requirement. + + + +### llms-full.txt size + +The `llms-full.txt` file must be between 500 and 5,000,000 characters. + +**Why this check matters:** Files that are too small contain too little content to be useful. Files that are too large exceed what most agents can process in a single context window. + +**How to improve:** If the file is too small, your site may have very few published pages. Start by adding more documentation content then update your `llms-full.txt` file. If the file is over the limit, identify less important information for agent context like changelog entries, info only relevant to humans like how to contact support, or other information that is not useful for agents. Also use `llms.txt` to point agents to individual pages. + + +The `llms-full.txt` file must be between 500 and 5,000,000 characters. + +If the file is **too small**: +- Review for missing pages or sections. +- Add the full Markdown content of each missing page, separating each section with a `###` heading that matches the page title. +- Ensure the file begins with a single H1 and meets the minimum heading and length requirements for discoverability. +- If the file is still too small, suggest a plan to add more relevant, user-focused content. + +If the file is **too large**: +- Audit the content for lengthy changelogs, machine-generated reference pages, or redundant text. +- Identify and recommend which sections to summarize or remove entirely, prioritizing core docs over verbose or duplicative material. +- Streamline the file so it contains the most valuable information for AI, targeting a total size under 5,000,000 characters. + +When finished, output a revised `llms-full.txt` file within the valid range, preserving clarity and navigation for LLMs and agent applications. + + +### llms-full.txt valid structure + +The `llms-full.txt` file must start with an H1 heading and contain at least two headings total. + +**Why this check matters:** Structure helps agents navigate and chunk the file rather than processing it as undifferentiated text. + +**How to improve:** Mintlify-generated files always meet this requirement. For custom files, ensure each major documentation section starts with a heading. + + +Ensure the `llms-full.txt` file begins with an H1 heading (e.g., `# ` on the very first line) and contains at least one additional heading. + +Instructions: +- Without altering any body content, insert headings where needed to meet these requirements. + - First line: Add a single H1 for the site or product name—do not add explanatory text on that line. + - Add `##` for each major section (such as "Guides", "API reference"). + - Use `###` for pages or logical subsections where appropriate to improve navigation. +- Do not modify or remove content just to increase heading count. +- When finished, provide the updated file and verify that: + - The file starts with `# ` as the first line. + - There are at least two Markdown headings in total. + + +### llms-full.txt links resolve + +At least 90% of same-origin links in the `llms-full.txt` file must properly resolve and return an `HTTP 200` status code. + +**Why this check matters:** Broken links make content unreachable for agents following them. If an agent can't follow a link, it may guess or fail to find content. + +**How to improve:** Fix broken links in your documentation source then update your `llms-full.txt` file. + + +Audit all same-origin links in my `llms-full.txt` file. For each link that does not resolve to an `HTTP 200` status code: +1. Determine the correct URL for the linked page. +2. Update the link in the `llms-full.txt` file to point to the correct URL. +3. Verify the link resolves correctly. +4. After updating each broken link in your `llms-full.txt`, ensure you apply the exact same correction in the original source documentation file where that content is authored. + +After fixing all broken links, provide the updated `llms-full.txt` file. + + +## skill.md + +This check looks for a skill discovery endpoint at `/.well-known/agent-skills/index.json`. If found, it fetches the first listed skill URL and verifies it returns Markdown content. If no index exists, it falls back to checking `/skill.md` directly. + +Mintlify generates a `skill.md` file for every documentation site. See [skill.md](/ai/skillmd) for customization options. + +**Why this check matters:** While `llms.txt` tells agents where your content is, `skill.md` tells agents how to use your product. This gives agents the operating context they need to take meaningful actions on behalf of users. + +**How to improve:** If you use a reverse proxy, configure it to forward `/skill.md`, `/.well-known/skills/*`, and `/.well-known/agent-skills/*` to your Mintlify subdomain. + + +Draft a `skill.md` for my product that follows the [Agent Skills](https://agentskills.io) conventions and is suitable for discovery via `/.well-known/agent-skills/index.json` or `/skill.md`. + +Use YAML frontmatter at the top with at least: `name`, `description`, `license`, and `compatibility` (add other standard fields if useful). + +Body structure: +1. **Overview** — One short paragraph: what the product is and who the agent user is +2. **Capabilities** — Bullet list of outcomes agents can drive end-to-end (not marketing features) +3. **Skills** — For each skill: purpose, required inputs, outputs, guardrails (auth, PII, rate limits), and failure modes +4. **Workflows** — Numbered procedures for 2-4 common tasks, with decision points and when to escalate to a human + +Tone: imperative, testable statements. Avoid vague adjectives. If you lack product facts, insert `TODO` with the specific fact needed instead of guessing. + +Output the full `skill.md` in one fenced markdown block. Call out any TODOs that must be resolved before the skill can be used. + + +## Markdown content negotiation + +This check sends a request to your documentation root with `Accept: text/markdown, text/html;q=0.9` and verifies that the response `Content-Type` is `text/markdown` or `text/x-markdown` and the body is not HTML. + +Mintlify handles this automatically for all hosted documentation sites. + +**Why this check matters:** Agents requesting Markdown receive structured content that is more efficient to process than HTML. This reduces token usage and removes noise from navigation elements, scripts, and markup that takes up the context window. + +**How to improve:** If you use a [reverse proxy](/deploy/reverse-proxy), ensure it forwards `Accept` headers to your Mintlify subdomain rather than stripping or overriding them. + + +Configure the documentation server so that when a client sends a request with the `Accept: text/markdown, text/html;q=0.9` header to the root (and preferably any documentation path), it returns the raw Markdown source, not HTML. The HTTP response should have a `Content-Type` of either `text/markdown` or `text/x-markdown`. All other requests—such as those from browsers without this Accept header—must continue to return HTML as usual. + +Requirements: +- Do not remove, transform, or ignore the `Accept` header at any reverse proxy—forward it to your origin server unchanged. +- Only serve Markdown responses to requests explicitly asking for them via `Accept`. + +The response should include: +1. Minimal example of request and response headers for both HTML and Markdown negotiations. +2. The exact middleware or server configuration needed. +3. A short `curl` command to test that Markdown negotiation works (ensure it checks both the `Content-Type` and body output, demonstrating Markdown is served). + +Optional: If content negotiation for individual documentation pages as well as the root is supported, describe any additional setup needed. + +Be concise. Focus only on the changes or code/configuration necessary for robust Markdown negotiation. + + +## Plaintext content negotiation + +This check sends a request to your documentation root with `Accept: text/plain, text/html;q=0.9` and verifies that the response returns a non-HTML `text/*` content type. + +Mintlify handles this automatically for all hosted documentation sites. + +**Why this check matters:** Some agents cannot handle Markdown and fall back to plain text. Support plain text fallback to keep your content accessible to simpler clients. + +**How to improve:** If you use a reverse proxy, ensure it forwards `Accept` headers to your Mintlify subdomain. + + +Configure the documentation server so a request with `Accept: text/plain, text/html;q=0.9` gets a **non-HTML** `text/*` body. Browsers sending default Accept headers must still receive HTML. + +Provide: routing or middleware changes, how plain text differs from Markdown negotiation if both are supported, and a `curl` command to confirm `Content-Type` and that the body is not HTML. + + +## MCP server + +This check sends a JSON-RPC `initialize` request to `/mcp` on your domain and verifies that the response includes a valid `serverInfo.name`. + +Mintlify hosts an MCP server for every documentation site. See [MCP server](/ai/model-context-protocol) for details and configuration. + +**Why this check matters:** An MCP server gives agents a way to integrate structured tools and typed outputs, rather than forcing them to scrape HTML or infer behavior from documentation. + +**How to improve:** If you use a reverse proxy, configure it to forward `/mcp` to your Mintlify subdomain. + + +I need a working MCP (Model Context Protocol) endpoint at `/mcp` subdomain of my documentation site so agents can run `initialize` and discover tools. + +Requirements to satisfy: +1. **JSON-RPC POST** to `/mcp`: `initialize` returns a result whose `serverInfo.name` is a non-empty string (this is what readiness checks look for) +2. **`tools/list`** returns **at least one** tool with `name`, `description`, and `inputSchema` (JSON Schema object) +3. If I use a reverse proxy or API gateway, show the exact path forwarding and any body-size or WebSocket settings MCP needs + +Deliver: architecture sketch, minimal handler pseudocode or real code for my stack, and example `curl` bodies for `initialize` and `tools/list` I can paste to test. + + +### Tool count + +This check calls `tools/list` and verifies at least one tool is returned. + +**Why this check matters:** An MCP server with no tools offers no integrations for agents. + +**How to improve:** If you use a reverse proxy, ensure it forwards requests to `/mcp` without stripping the request body or modifying headers that the MCP protocol depends on. If you host your own MCP server, implement the `tools/list` JSON-RPC method and register at least one tool with a valid `name`, `description`, and `inputSchema`. + + +My MCP server at `/mcp` responds to `initialize` but `tools/list` is empty or returns zero tools. Fix it so **at least one** tool appears with valid `name`, `description`, and `inputSchema`. + +Prioritize doc-site tools that map to real behavior in my codebase: +- **`search_docs`** — `query` string; returns ranked snippets + page URLs +- **`get_page`** — `slug` or `url`; returns Markdown (or structured sections) +- **`list_sections`** — no args or optional `locale`; returns nav tree + +Implementation asks: +1. Register tools in one place so both `tools/list` and `tools/call` stay in sync +2. Use JSON Schema for parameters (`type`, `properties`, `required` as appropriate) +3. Add one happy-path test or manual `curl` showing `tools/list` non-empty + + +## OpenAPI specification + +This check looks for a valid OpenAPI specification at standard paths: `/openapi.json`, `/openapi.yaml`, `/swagger.json`, `/swagger.yaml`, and `/api/` variants of each. The specification must parse as valid JSON or YAML with an `openapi` or `swagger` version field. + +**Why this check matters:** A discoverable OpenAPI specification gives agents context on your API surface, parameters, and schemas without scraping HTML. This is the most direct path for agents to call your API accurately. + +**How to improve:** Host your OpenAPI specification at one of the standard paths listed above. If you already have a specification, verify it is publicly accessible without authentication. + + +I want my OpenAPI specification publicly accessible at one of these standard paths so agents can discover it without scraping my docs: `/openapi.json`, `/openapi.yaml`, `/swagger.json`, `/swagger.yaml`, or `/api/` variants of each. + +Requirements: +- The spec must be valid JSON or YAML with an `openapi` or `swagger` version field at the top level +- Correct `Content-Type`: `application/json` for JSON specs, `application/yaml` or `application/x-yaml` for YAML +- No authentication required for GET requests—the spec must be publicly readable + +My API framework: **<e.g. FastAPI, Express, Rails, hand-maintained file>** +Where the spec currently lives: **<e.g. auto-generated at runtime, static file at path/to/openapi.yaml>** + +Deliver: +1. The exact route or server config to serve the spec at the correct path +2. Whether to prefer JSON or YAML given my stack, and why +3. A `curl` one-liner to confirm the spec is reachable and parses correctly: `curl -s https://yourdomain.com/openapi.json | head -5` + + +## robots.txt + +This check fetches `/robots.txt` and verifies that none of the known AI agent user-agents—including Claude, ChatGPT, Gemini, Copilot, and Perplexity—are blocked with `Disallow: /` or `Disallow: /*`. If no `robots.txt` exists, or it returns HTML, the check passes. + +**Why this check matters:** Blocking AI crawlers in `robots.txt` prevents content from being indexed and fetched, even if your documentation is otherwise well-structured and publicly accessible. + +**How to improve:** Review your `robots.txt` for blanket disallow rules targeting AI user-agents. Replace them with path-specific rules if you need to restrict access to certain sections without blocking all content. + + +My `robots.txt` may be blocking AI crawlers. Update it so none of these user-agents are blocked with `Disallow: /` or `Disallow: /*`: `GPTBot`, `ClaudeBot`, `Claude-User`, `Google-Extended`, `PerplexityBot`, `Copilot`, `OAI-SearchBot`. + +Rules: +- Use path-specific `Disallow` for sensitive areas rather than sitewide blocks for AI crawlers +- Preserve existing rules for non-AI bots—do not weaken unrelated protections +- If `User-agent: *` has a broad `Disallow`, add explicit `Allow` lines for AI crawlers above it and explain precedence + +Deliver: +1. The complete revised `robots.txt` +2. A summary of what changed for each AI-related user-agent and its effective access to my documentation path + + +## Sitemap + +This check fetches `/sitemap.xml` and verifies it returns a valid XML content type or starts with valid XML (` +I need a `sitemap.xml` served at `/sitemap.xml` so agents and crawlers can discover all my documentation URLs without guessing at navigation. + +Include: +- Every public documentation URL in canonical `https://` form—no auth-gated pages +- `lastmod` if you can derive it from git history or file dates; omit it rather than guess +- `changefreq` and `priority` only if my framework already generates them + +Deliver: +1. The complete `sitemap.xml` file content +2. Where to place it so it is served at `/sitemap.xml` in my build output +3. A `curl` one-liner to confirm it's reachable and recognized as XML: `curl -sI https://yourdomain.com/sitemap.xml | grep content-type` + + +## Structured data + +This check fetches your documentation homepage as HTML and looks for `