Mintlify vs ReadMe

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Mintlify✓fullprobed9/10

   Mintlify auto-generates llms.txt/llms-full.txt, markdown exports, and skill.md files for agent consumption, and this is independently confirmed by a live probe returning a working llms.txt at mintlify.com. This directly enables an AI agent to be pointed at agent-oriented docs formats. Missing for 10: independent third-party verification that llms-full.txt/skill.md render correctly across customer sites (only vendor's own site probed).

   • [claimed-docs] “Automatically generate llms.txt and llms-full.txt files so AI tools like ChatGPT and Claude can index and understand your documentation.”
   • [claimed-docs] “Add `.md` to any page's URL to view a Markdown version.”
   • [claimed-docs] “Mintlify hosts a `skill.md` file at the root of your project that describes what AI agents can do with your product.”
   • [claimed-docs] “Make your documentation agent-ready with automatically generated skill.md files that describe your product's capabilities for AI agents.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.mintlify.com/llms.txt # Mintlify > Mintlify is the knowledge platform built for agents: self-updati…”

   proof ↗⚑ flag

   ReadMe✓fullprobed9/10

   ReadMe hosts a verified llms.txt at docs.readme.com/llms.txt (probe confirms HTTP 200) plus per-page .md access, dedicated llms.txt-style docs for customizing/writing/workflows/ai sections, an Agent-Friendly Docs scoring feature (ai-discoverability), and an official MCP server giving agents live access to API specs and docs. missing for 10: independent/hands-on third-party confirmation that an external agent successfully consumes the llms.txt content end-to-end (only first-party docs and one probe corroborate this).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Get your API documentation live in three steps: create a project, upload your API definition, and write your first guide.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Draft, edit, and research documentation from the AI chat panel.”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Mintlify~partialprobed6/10

   Mintlify offers a CLI for local preview/build-error checking and a REST API to trigger deployments, export analytics, and manage docs programmatically, plus automations that run the agent on schedule/push/integration events — all usable in CI-like automation. However, there's no documented headless CI recipe (e.g., GitHub Actions example, CI-specific flags, or exit-code based validation) and the CLI docs emphasize local preview rather than CI. missing for 10: explicit CI/headless workflow examples (e.g. GitHub Actions integration), documented non-interactive CLI flags for build validation, independent confirmation of CLI use in automated pipelines.

   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”
   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [probe] “official CLI documented at https://www.mintlify.com/docs/cli/install”
   • [claimed-docs] “Queue a deployment update for your documentation project. Returns a status ID that can be used to track the update progress.”
   • [claimed-docs] “Create or update a preview deployment for a specific branch. If a preview already exists for the branch, it triggers a redeployment.”

   proof ↗⚑ flag

   ReadMe~partialprobed6/10

   ReadMe ships an official CLI (rdme) and a documented REST API for controlling docs programmatically, both of which support headless/CI automation (e.g., syncing OpenAPI specs in pipelines). However, the evidence pack lacks explicit CI/CD workflow examples, headless-mode documentation, or community confirmation of CI usage. Missing for 10: explicit CI pipeline examples/docs, headless-mode guarantees, and independent confirmation of automated CLI/API use in production pipelines.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Mintlify—none0/10

   All MCP-related evidence describes Mintlify exposing its own MCP servers (search, admin, index) for external AI tools like Claude/Cursor/ChatGPT to consume — the opposite direction of this story. There is no evidence that Mintlify's own agents (editor agent, docs-writing agent, automations) can be extended by plugging in third-party MCP servers so they gain new tools.

   • [claimed-docs] “Connect AI tools like Claude, Cursor, and ChatGPT to your hosted search MCP server so they can search and retrieve content from your site.”
   • [claimed-docs] “Give AI tools like Claude, ChatGPT, and Cursor write access to your Mintlify content and dashboard so they can edit pages, update settings, …”
   • [claimed-docs] “The Mintlify Index MCP server gives AI tools read-only access to technical documentation and web context.”
   • [claimed-docs] “Search Model Context Protocol (MCP) server - Mintlify”
   • [claimed-docs] “Admin Model Context Protocol (MCP) server - Mintlify”
   • [claimed-docs] “Mintlify Index MCP server”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”

   proof ↗⚑ flag

   ReadMe—none0/10

   All MCP-related evidence describes ReadMe publishing its own MCP server so external AI coding assistants (Cursor, Claude Code, VS Code Copilot) can call ReadMe's API/docs tools (readme-docs-3, readme-docs-34, readme-probe-2) — this is the server role, the opposite of what the story asks. There is no evidence that ReadMe's own AI features (Ask AI, AI Agent, GitHub AI Writer) can connect to and consume external MCP servers as a client.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Mintlify✓fullprobed8/10

   Mintlify documents multiple official MCP servers (search MCP, admin/write MCP, and Index MCP) that let agents like Claude, Cursor, and ChatGPT connect, search, and even edit content, confirmed by both docs and a probe verifying the page exists. missing for 10: independent hands-on confirmation that the MCP server works reliably in practice beyond vendor docs.

   • [claimed-docs] “Connect AI tools like Claude, Cursor, and ChatGPT to your hosted search MCP server so they can search and retrieve content from your site.”
   • [claimed-docs] “Give AI tools like Claude, ChatGPT, and Cursor write access to your Mintlify content and dashboard so they can edit pages, update settings, …”
   • [claimed-docs] “The Mintlify Index MCP server gives AI tools read-only access to technical documentation and web context.”
   • [claimed-docs] “Search Model Context Protocol (MCP) server - Mintlify”
   • [claimed-docs] “Admin Model Context Protocol (MCP) server - Mintlify”
   • [claimed-docs] “Mintlify Index MCP server”
   • [probe] “official MCP server documented at https://www.mintlify.com/docs/ai/mintlify-mcp”

   proof ↗⚑ flag

   ReadMe✓fullprobed8/10

   ReadMe documents an official, project-specific MCP server that gives AI coding assistants (Cursor, Claude Code, VS Code Copilot) a live connection to API specs/docs, backed by dedicated MCP metrics/analytics and confirmed live via probe. missing for 10: independent/hands-on third-party verification that the MCP connection works as described beyond first-party docs.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “MCP Metrics”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Mintlify
   Mintlify✓fullprobed8/10

   Mintlify ships an official CLI (mintlify-docs-11/29, confirmed by probe mintlify-probe-5) used to preview docs locally, test changes in real time, and catch build errors before deployment — a core dev/agentic workflow tool. Missing for 10: no independent/hands-on corroboration of CLI usage or evidence of AI-specific CLI subcommands tailored for agent workflows beyond standard doc preview.

   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”
   • [claimed-docs] “Install the Mintlify CLI to preview documentation l”
   • [probe] “official CLI documented at https://www.mintlify.com/docs/cli/install”

   proof ↗⚑ flag

   ReadMe~partialprobed5/10

   ReadMe does maintain an official CLI (rdme) per the GitHub probe, confirming the capability exists, but the evidence pack contains no first-party documentation detailing the CLI's commands, AI-native workflow support, or independent corroboration of its use. missing for 10: detailed CLI docs/feature list, AI-native workflow examples, independent/hands-on usage confirmation.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to ReadMe
   Mintlify~partialprobed7/10

   Mintlify documents a REST API for triggering deployments, embedding the assistant, exporting analytics, and managing docs programmatically, plus llms.txt-listed endpoints for deployment/preview management, CLI, and MCP servers for agent-driven interaction. However, a live probe found no discoverable OpenAPI/swagger spec at standard locations, and there's no independent/hands-on corroboration of the API's completeness or reliability. Missing for 10: publicly verifiable OpenAPI/schema discovery, independent developer confirmation of API usage.

   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [claimed-docs] “Queue a deployment update for your documentation project. Returns a status ID that can be used to track the update progress.”
   • [claimed-docs] “Create or update a preview deployment for a specific branch. If a preview already exists for the branch, it triggers a redeployment.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.mintlify.com/openapi.json, https://www.mintlify.com/swagger.json, https://www.mintlify.c…”

   proof ↗⚑ flag

   ReadMe✓fullprobed8/10

   ReadMe documents a full public API ('Control your docs programmatically with the ReadMe API') plus a companion developer-metrics API and an open-source CLI (rdme) that wraps it, giving AI-native users a documented, scriptable interface to drive the product. missing for 10: independent/hands-on confirmation that the API works as documented and more detail on API reference completeness beyond the one-line docs mention.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Mintlify
   Mintlify!disputedcontradicted4/10

   Mintlify does offer some role-based separation (a read-only search/index MCP server vs. a separate write-access admin MCP for editing content and settings), which hints at scoped access levels, but there is no documented mechanism for issuing fine-grained, least-privilege API keys or credentials scoped per agent/task. A hands-on account explicitly contradicts the least-privilege idea: onboarding via the GitHub app forced full access to all repositories with 'no way to get around that,' the opposite of scoped credentialing. Missing for 10: documented scoped API-key/token creation flow, per-agent permission granularity, and confirmation that write-access MCP/API keys can be limited rather than all-or-nothing.

   • [claimed-docs] “Connect AI tools like Claude, Cursor, and ChatGPT to your hosted search MCP server so they can search and retrieve content from your site.”
   • [claimed-docs] “Give AI tools like Claude, ChatGPT, and Cursor write access to your Mintlify content and dashboard so they can edit pages, update settings, …”
   • [claimed-docs] “The Mintlify Index MCP server gives AI tools read-only access to technical documentation and web context.”
   • [community] “I was a Mintlify customer 6 months ago and found their onboarding strange. Their Github app asked for permissions to access all my repos and…”

   proof ↗⚑ flag

   ReadMe—none0/10

   While ReadMe exposes an MCP server and a general ReadMe API, the evidence pack contains no mention of issuing scoped or least-privilege API credentials specifically for AI agents (e.g., agent-specific API keys, permission scopes, or token restrictions) — only general API key injection for docs personalization and generic API access control.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to ReadMe
   Mintlify—none0/10

   Mintlify documents a REST API (mintlify-docs-21) and CLI, but there is no evidence of official client SDKs (e.g., Python/JS/Go libraries) for developers to build against, and probes for an OpenAPI spec for Mintlify's own API returned 404s (mintlify-probe-3), suggesting no such SDK tooling exists.

   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.mintlify.com/openapi.json, https://www.mintlify.com/swagger.json, https://www.mintlify.c…”

   proof ↗⚑ flag

   ReadMe~partialprobed3/10

   ReadMe documents a public REST API and an official CLI (rdme) that developers can build against programmatically, but there is no evidence of dedicated official client SDKs in multiple languages (e.g., Python, Node, Go) for integrating with the ReadMe platform itself — 'Pick a language' refers to code-sample generation for the API reference of the docs being hosted, not an SDK for ReadMe. Missing for 10: explicit official multi-language SDKs, independent/hands-on validation of SDK quality, and clear API-vs-SDK distinction.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Pick a language”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Mintlify~partialclaimed6/10

   Mintlify provides an analytics dashboard covering documentation traffic, assistant conversations, search queries, and reader feedback, plus an AI assistant/agent that can answer questions and act on content, which offers some data-driven insight into how docs are used. However, this is more operational analytics than deep AI-generated 'insights and suggestions' proactively surfaced from user data (e.g., no evidence of trend analysis, content gap detection, or recommendation generation from analytics). missing for 10: proactive AI-generated recommendations/insights derived from analytics data, independent validation of 'advanced insights' (mentioned only in pricing tier name), and concrete examples of suggestions generated from user behavior data.

   • [claimed-docs] “Explore the Mintlify analytics dashboard to measure documentation traffic, assistant conversations, search queries, engagement, and reader f…”
   • [claimed-docs] “Everything in Pro * SSO, SCIM & RBAC * Performance SLA * Advanced insights * Enterprise security & legal * …”
   • [claimed-docs] “Add an AI-powered chat assistant to your documentation site that answers user questions, cites sources, and generates code examples on deman…”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe offers AI-generated insights within the product itself: the AI Linter/Docs Audit checks content against natural-language rules, the AI Agent and Inline AI can draft/rewrite/enhance content, and Ask AI surfaces answers from docs; API/MCP Metrics also surface usage insights though these are analytics dashboards rather than AI-generated suggestions. However, evidence is entirely vendor documentation with no independent/hands-on validation of the AI suggestions' quality or accuracy. missing for 10: independent/hands-on evidence of AI insight quality, examples of AI-generated suggestions in practice, and confirmation that analytics (metrics) include AI-driven interpretation rather than raw charts.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “Draft, edit, and research documentation from the AI chat panel.”
   • [claimed-docs] “An AI-powered tool for checking page content against your own style guide.”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed8/10

   Mintlify's Automations feature explicitly supports running the documentation agent autonomously on a schedule, on repo pushes, or on connected integration events, with pre-built automations requiring no manual setup — a clear background-agentic capability. This is corroborated by the agent docs (research/plan/write/PR) and blog updates describing redesigned automations for quicker setup. Missing for 10: independent/hands-on verification of automation reliability and no detail on failure handling or monitoring of autonomous runs.

   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”
   • [claimed-docs] “We redesigned automations for quicker setup with pre-built automations optimized for common use cases. Choose the right automations for your…”
   • [claimed-docs] “Automate conte”

   proof ↗⚑ flag

   ReadMe~partialclaimed4/10

   The GitHub AI Writer feature watches pull requests in the background and autonomously proposes documentation updates when code changes affect docs (readme-docs-8), which is the only evidence of a background automation. However, this is a single fixed integration (not a general automation framework), still requires human review/approval before changes go live (readme-docs-12/27), and there's no evidence of user-configurable autonomous background jobs, schedules, or triggers beyond this one PR-watching feature. missing for 10: general-purpose automation/workflow builder, evidence of fully unattended (no-approval) execution, multiple autonomous background triggers beyond PR-watching, independent confirmation of autonomy in practice.

   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Mintlify
   Mintlify✓fullclaimed8/10

   Mintlify ships multiple built-in AI assistants users can delegate tasks to: the docs-site chat assistant that answers questions and cites sources, the editor's built-in AI agent that edits pages, reorganizes navigation, updates config, and searches the repo, and a broader 'agent' that researches/plans/writes docs and opens PRs autonomously (including on a schedule via automations). This is corroborated across first-party docs describing distinct but overlapping delegate-to-AI workflows. Missing for 10: independent/hands-on verification of assistant task delegation quality and reliability beyond vendor docs.

   • [claimed-docs] “users can chat with the [assistant](/docs/assistant) in your documentation for immediate answers to their questions and links to relevant co…”
   • [claimed-docs] “Add an AI-powered chat assistant to your documentation site that answers user questions, cites sources, and generates code examples on deman…”
   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”
   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe ships an in-product 'Agent' documentation assistant that creates, edits, and enhances content across Guides, API References, and Custom Pages, plus inline AI editing via natural-language prompts — a genuine built-in AI assistant users can delegate documentation tasks to. However, this is scoped to docs authoring/editing tasks, not general task delegation, and there's no independent/hands-on corroboration of the Agent's reliability or scope beyond vendor docs. missing for 10: independent or hands-on verification of the Agent's capabilities and limits, evidence of broader task delegation beyond content editing, and any community feedback on the Agent feature specifically.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Mintlify
   Mintlify✓fullprobed8/10

   Mintlify supports natural-language operation extensively: chat assistant for readers, editor's built-in AI agent that edits pages/navigation/settings via commands, Slack agent responding to @mentions, and MCP servers letting external AI tools (Claude, Cursor, ChatGPT) issue natural-language commands to search or edit docs. missing for 10: independent hands-on verification of the natural-language command experience (evidence is entirely vendor docs) and no third-party review confirming reliability of agent-driven edits.

   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”
   • [claimed-docs] “Give AI tools like Claude, ChatGPT, and Cursor write access to your Mintlify content and dashboard so they can edit pages, update settings, …”
   • [claimed-docs] “Mention @mintlify in any channel or DM - Answers grounded in your docs, with sources - Follow-ups stay in the same thread”
   • [claimed-docs] “Reads the full thread for context - Opens a pull request in your docs repo - Live status updates until the PR is ready”
   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”
   • [probe] “official MCP server documented at https://www.mintlify.com/docs/ai/mintlify-mcp”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's Agent and Inline AI let users edit and enhance docs content via plain-language prompts, and the Linter lets you define documentation rules in natural language, showing genuine NL-driven operation of core content-editing workflows. However, this is scoped to content editing rather than full product operation (e.g., configuring project settings, analytics, or publishing via NL commands), and there's no independent/hands-on corroboration beyond first-party docs. Missing for 10: evidence of NL control over broader product functions (settings, analytics, admin tasks) and independent verification of the Agent/Inline AI working as described.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify generates interactive API reference pages with request builders/API playground directly from OpenAPI specs, explicitly described as 'Interactive for developers. Structured for agents,' matching the AI-native runnable-example story. Missing for 10: independent/hands-on verification of the playground's interactivity and no direct evidence of live 'run' execution against real endpoints beyond docs claims.

   • [claimed-docs] “Generate interactive API documentation from OpenAPI specification files with automatic endpoint pages, request builders, and navigation.”
   • [claimed-docs] “Docs generated directly from your OpenAPI spec. Interactive for developers. Structured for agents. Generated from the spec you already maint…”
   • [claimed-docs] “API playground where user”
   • [claimed-docs] “Generate i”

   proof ↗⚑ flag

   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make test calls and see real responses without writing code, backed by OpenAPI upload/management for generating that reference, and community feedback corroborates strong API reference/Swagger support versus alternatives. missing for 10: independent hands-on validation specifically of the 'runnable examples' UX (only vendor docs cited) and no direct AI-native user testimonial trying the runnable examples.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Mintlify
   Mintlify~partialprobed5/10

   Mintlify explicitly supports generating API documentation from OpenAPI spec files (mintlify-docs-14), implying OpenAPI is a first-class, machine-readable input to the platform, and it also offers a REST API (mintlify-docs-21) and markdown exports (mintlify-docs-9/23) for AI consumption. However, there is no direct evidence that a hosted Mintlify docs site exposes the underlying OpenAPI file for download, and a probe of Mintlify's own site found no openapi.json/swagger.json at any standard path (mintlify-probe-3), suggesting the spec isn't uniformly published as a downloadable artifact. Missing for 10: confirmation that generated docs sites serve the raw OpenAPI/spec file at a discoverable URL, and that Mintlify's own product API has a published machine-readable spec.

   • [claimed-docs] “Generate interactive API documentation from OpenAPI specification files with automatic endpoint pages, request builders, and navigation.”
   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.mintlify.com/openapi.json, https://www.mintlify.com/swagger.json, https://www.mintlify.c…”

   proof ↗⚑ flag

   ReadMe—none0/10

   Evidence documents ReadMe's ability to upload/manage an OpenAPI spec to generate docs (readme-docs-23) and export docs/PDF files (readme-docs-13/29), but there is no evidence of a feature letting a user download the underlying OpenAPI spec (JSON/YAML) as a machine-readable artifact. Missing for 10: any documented spec-download endpoint, export-as-OpenAPI option, or explicit machine-readable API spec retrieval capability.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Mintlify
   Mintlify~partialclaimed6/10

   Mintlify provides local CLI previews and per-PR preview deployment URLs that let users (including AI agents) test documentation changes before they reach the live/production site, which functions as a de facto sandbox for content changes without touching production. However, this is scoped to docs preview/staging rather than an explicit 'sandbox environment' with isolated test data, and there's no independent corroboration of this workflow. Missing for 10: a dedicated sandbox/test environment concept distinct from PR previews, explicit handling of test vs production data, and independent/hands-on validation of the preview-before-prod workflow.

   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”
   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”

   proof ↗⚑ flag

   ReadMe—none0/10

   ReadMe's API Reference lets users make live test calls against real APIs (readme-docs-1, readme-docs-15), but no evidence describes a distinct sandbox/staging environment isolated from production data — the docs explicitly describe 'real responses,' implying production calls rather than a sandboxed test environment.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “Try it out — enter a URL , , or Upload Files , or Drag and Drop”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Mintlify—none0/10

   The evidence pack contains extensive documentation on Mintlify's own API (REST API for deployments, MCP servers, CLI, etc.) but no mention of API versioning schemes or a documented deprecation policy for Mintlify's own APIs/products. Probe evidence even shows the OpenAPI spec for Mintlify's own API returns 404, and there's no reference to version history or deprecation timelines anywhere in the pack.

   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.mintlify.com/openapi.json, https://www.mintlify.com/swagger.json, https://www.mintlify.c…”

   proof ↗⚑ flag

   ReadMe—none0/10

   Evidence shows ReadMe offers a 'Versions' feature for customers' own API docs (readme-docs-17, 48, 69) and exposes its own ReadMe API for programmatic control (readme-docs-87), but there is no documentation of a versioning scheme or deprecation policy for ReadMe's own API/product that an AI-native consumer could rely on.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use cases.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”

   proof ↗⚑ flag

Agent access

1. ai-native userMy published docs site exposes its own MCP server that my users' agents can query for search and page content

   weight 3 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify explicitly documents a hosted Index/Search MCP server that exposes each published docs site for AI agents to search and retrieve content, and this is listed as a pricing-tier feature, confirming it's a real, shipped per-site capability rather than a roadmap item. Missing for 10: independent/hands-on verification that the MCP server works as described on a live customer site, and clarity on default-on vs opt-in status.

   • [claimed-docs] “Connect AI tools like Claude, Cursor, and ChatGPT to your hosted search MCP server so they can search and retrieve content from your site.”
   • [claimed-docs] “The Mintlify Index MCP server gives AI tools read-only access to technical documentation and web context.”
   • [claimed-docs] “Search Model Context Protocol (MCP) server - Mintlify”
   • [claimed-docs] “Mintlify Index MCP server”
   • [claimed-docs] “Full platform * Custom domain * Web editor * Authentication * MCP server * API playground”

   proof ↗⚑ flag

   ReadMe✓fullprobed8/10

   ReadMe documents a per-project MCP server that gives AI agents/coding assistants a live connection to the API spec and docs, with dedicated analytics tracking every tool call made by AI clients, matching the story of an exposed queryable MCP server. missing for 10: no independent/hands-on confirmation of query quality or third-party agent testing, and no detail on search-specific tool schemas beyond general spec/doc access.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [claimed-docs] “MCP”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

Agent output

1. ai-native userMy published docs site automatically serves llms.txt (and a full-content variant) so agents can index it

   weight 3 · round to Mintlify
   Mintlify✓fullprobed9/10

   Mintlify docs explicitly state it auto-generates llms.txt and llms-full.txt for published sites, structured as a file hierarchy so agents can traverse without loading the whole index, and this is independently confirmed by a live probe returning HTTP 200 at mintlify.com/llms.txt. missing for 10: no probe confirmation of the llms-full.txt variant specifically (only llms.txt was probed).

   • [claimed-docs] “Automatically generate llms.txt and llms-full.txt files so AI tools like ChatGPT and Claude can index and understand your documentation.”
   • [claimed-docs] “We rebuilt generation as a hierarchy of files so agents can reach every page without loading the entire index.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.mintlify.com/llms.txt # Mintlify > Mintlify is the knowledge platform built for agents: self-updati…”

   proof ↗⚑ flag

   ReadMe✓fullprobed8/10

   A direct probe confirms docs.readme.com serves a live llms.txt (HTTP 200) that also documents a full-content variant via appending .md to any page URL — matching the story's ask exactly. This is reinforced by ReadMe's own docs being organized under numerous /llms.txt paths (e.g. customizing-docs/llms.txt, workflows/llms.txt, ai/llms.txt) and a dedicated 'AI Discoverability' feature (readme-docs-10/31/65) that scores published docs against an 'Agent-Friendly Docs spec,' indicating llms.txt generation is a first-class, cross-project capability rather than a one-off. Missing for 10: explicit first-party confirmation that llms.txt is auto-generated for arbitrary customer-published hubs (not just docs.readme.com itself), and independent/community corroboration of this specific feature.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Inject your users' API keys, server variables, and more!”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”

   proof ↗⚑ flag

2. ai-native userEvery published page serves clean markdown at its URL (e.g. appending .md) so agents skip the HTML

   weight 3 · round to Mintlify
   Mintlify✓fullprobed8/10

   Mintlify explicitly documents that appending `.md` to any page's URL returns a clean Markdown version for AI/LLM consumption, positioned as a first-class agent-facing feature alongside llms.txt and skill.md. The 404 probe was against the marketing site's root docs.md, not an actual customer documentation page URL with .md appended, so it doesn't concretely contradict the documented per-page behavior. Missing for 10: independent hands-on verification on a live customer docs site confirming the .md suffix works as described.

   • [claimed-docs] “Add `.md` to any page's URL to view a Markdown version.”
   • [claimed-docs] “Export clean Markdown versions of your documentation pages for AI tools, LLM integrations, and automated content processing workflows.”
   • [claimed-docs] “Export clea”
   • [claimed-docs] “Automatically generate llms.txt and llms-full.txt files so AI tools like ChatGPT and Claude can index and understand your documentation.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.mintlify.com/llms.txt # Mintlify > Mintlify is the knowledge platform built for agents: self-updati…”

   proof ↗⚑ flag

   ReadMe✓fullprobed7/10

   A direct probe of ReadMe's own docs site confirms the .md URL pattern works ('Append .md to any documentation page URL to...'), and ReadMe's AI-discoverability feature explicitly scores published customer pages against an 'Agent-Friendly Docs spec,' indicating this is a platform-wide capability, not just ReadMe's own site. Missing for 10: independent confirmation on a customer-hosted docs hub (not just docs.readme.com), third-party corroboration of the .md behavior across arbitrary published projects.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Your docs, now agent-ready”

   proof ↗⚑ flag

Assistant

1. ai-native userAn embedded AI assistant on my docs site answers reader questions with citations into my content

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed9/10

   Mintlify's docs describe a first-party embedded AI assistant that answers reader questions with citations and code examples (mintlify-docs-2, mintlify-docs-3), and analytics track assistant conversations (mintlify-docs-19), showing this is a real, monitored feature rather than a stub. Missing for 10: independent/hands-on third-party verification of citation accuracy in a live customer deployment (community evidence covers other topics, not assistant quality).

   • [claimed-docs] “users can chat with the [assistant](/docs/assistant) in your documentation for immediate answers to their questions and links to relevant co…”
   • [claimed-docs] “Add an AI-powered chat assistant to your documentation site that answers user questions, cites sources, and generates code examples on deman…”
   • [claimed-docs] “Explore the Mintlify analytics dashboard to measure documentation traffic, assistant conversations, search queries, engagement, and reader f…”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's 'Ask AI' feature is documented as giving readers instant answers from published documentation directly inside the hub, matching the core story of an embedded assistant answering questions from docs content, but the evidence never confirms it surfaces explicit citations/links into specific content, and there's no independent or hands-on verification of this behavior. missing for 10: explicit documentation or proof that Ask AI cites/links specific source pages, independent/community confirmation of citation quality.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”

   proof ↗⚑ flag

Writer agent

1. ai-native userA platform AI agent drafts, updates, and reviews my docs — from a prompt, a PR, or a schedule — and ships its work as change requests

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed9/10

   Mintlify's docs describe a dedicated agent that researches, plans, and writes documentation and opens pull requests for review (mintlify-docs-4), automations that trigger this agent on a schedule, on repo pushes, or on integration events (mintlify-docs-5, mintlify-docs-57), a Slack-based agent that reads thread context and opens PRs from a prompt (mintlify-docs-52, mintlify-docs-53), and an editor built-in agent that edits pages/nav/settings with review-and-merge PR workflows (mintlify-docs-13, mintlify-docs-25/26). This covers prompt-, PR-, and schedule-triggered drafting/updating shipped as change requests (PRs). Missing for 10: independent/hands-on verification of the agent's PR quality or reliability beyond vendor docs.

   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”
   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”
   • [claimed-docs] “Mention @mintlify in any channel or DM - Answers grounded in your docs, with sources - Follow-ups stay in the same thread”
   • [claimed-docs] “Reads the full thread for context - Opens a pull request in your docs repo - Live status updates until the PR is ready”
   • [claimed-docs] “We redesigned automations for quicker setup with pre-built automations optimized for common use cases. Choose the right automations for your…”

   proof ↗⚑ flag

   ReadMe~partialclaimed7/10

   ReadMe documents an AI Agent that drafts/edits content from natural-language prompts (readme-docs-18, readme-docs-19), a GitHub AI Writer that watches PRs and proposes doc updates when code changes (readme-docs-8, readme-docs-53), and a Reviews/branches workflow where changes are held until approved (readme-docs-12, readme-docs-27, readme-docs-45, readme-docs-70) — functioning like change requests. However there is no evidence of a schedule-triggered agent run, and it's unclear whether GitHub AI Writer output surfaces as an actual GitHub pull request versus an internal ReadMe branch/review. Missing for 10: schedule-based trigger evidence, and explicit confirmation that agent output is submitted as a GitHub PR/change request rather than only an internal review branch.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Proposes documentation updates when pull requests change your codebase.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

Analytics

1. ai-native userMy docs analytics distinguish AI-agent traffic from human traffic so I can see who — or what — is actually reading

   weight 2 · round to ReadMe
   Mintlify—none0/10

   Mintlify's analytics docs describe traffic, assistant conversations, search queries, engagement, and reader feedback metrics, but none of the evidence mentions segmenting or distinguishing AI-agent/bot traffic from human readers. No dashboard feature, API field, or blog mention addresses agent-vs-human attribution.

   • [claimed-docs] “Explore the Mintlify analytics dashboard to measure documentation traffic, assistant conversations, search queries, engagement, and reader f…”
   • [claimed-docs] “Explore the Mintlify analy”
   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's MCP Metrics page explicitly tracks calls made by AI agents/clients to a project's MCP server (calls, latency, failures, per-tool breakdown), which functions as dedicated AI-agent-traffic analytics distinct from human page-view metrics. However, this only covers MCP tool-call traffic, not a unified dashboard that tags/distinguishes AI crawlers or AI agent readers from human visitors across regular docs page views and API Metrics. Missing for 10: evidence of AI-vs-human classification within general docs pageview/API Metrics (not just MCP), and any UI showing side-by-side human vs agent traffic breakdown.

   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [claimed-docs] “MCP Metrics”
   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “API & Docs Metrics Charts”

   proof ↗⚑ flag

2. devrel leadI see page views, search terms, and reader feedback so I know which docs work and which fail

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed8/10

   Mintlify's analytics dashboard explicitly covers traffic (page views), assistant conversations, search queries, engagement, and reader feedback, directly matching the story; Enterprise tier adds 'Advanced insights.' missing for 10: no independent/hands-on corroboration of the analytics dashboard's usability or accuracy, and no detail on how feedback is captured or segmented by page.

   • [claimed-docs] “Explore the Mintlify analytics dashboard to measure documentation traffic, assistant conversations, search queries, engagement, and reader f…”
   • [claimed-docs] “Explore the Mintlify analy”
   • [claimed-docs] “Everything in Pro * SSO, SCIM & RBAC * Performance SLA * Advanced insights * Enterprise security & legal * …”

   proof ↗⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe documents Docs/API Metrics Charts and a Developer Metrics API that show 'how people use your docs and how developers use your API' (page views/usage), and Suggest in GitHub lets readers flag typos or share feedback, giving DevRel leads usage and feedback signals. However, there is no explicit documentation of search-term tracking/analytics, and no independent or hands-on evidence validating the depth or accuracy of these analytics dashboards. Missing for 10: explicit search-query/search-term analytics, quantified reader feedback/ratings dashboard, independent corroboration of the metrics feature's usefulness.

   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “API & Docs Metrics Charts”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “Anyone consuming your public documentation (developers, partners, etc.). They can use Suggest in GitHub to flag typos or share user feedback…”
   • [claimed-docs] “Suggesting changes from GitHub allows anyone reading your document”

   proof ↗⚑ flag

Playground

1. developerReaders can try real API calls from an interactive playground embedded in the reference docs

   weight 2 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify docs explicitly describe generating interactive API documentation from OpenAPI specs with request builders and an 'API playground' feature listed as a platform capability, and use-case docs explicitly mention an 'API playground where users' can try calls. Missing for 10: independent/hands-on verification that real live API calls succeed against actual servers, and more detail on auth/credential handling within the playground.

   • [claimed-docs] “Generate interactive API documentation from OpenAPI specification files with automatic endpoint pages, request builders, and navigation.”
   • [claimed-docs] “Docs generated directly from your OpenAPI spec. Interactive for developers. Structured for agents. Generated from the spec you already maint…”
   • [claimed-docs] “API playground where user”
   • [claimed-docs] “Full platform * Custom domain * Web editor * Authentication * MCP server * API playground”
   • [claimed-docs] “Generate i”

   proof ↗⚑ flag

   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make real test calls and see actual responses without writing code, and independent community feedback corroborates ReadMe's strong Swagger/OpenAPI-based reference experience. Missing for 10: independent hands-on confirmation specifically of the try-it-out call execution (vs. general praise) and details on auth/key injection during live calls.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

Spec driven

1. developerMy API reference pages are generated from an OpenAPI spec and stay in sync when the spec changes

   weight 3 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify docs explicitly describe generating interactive API reference pages from OpenAPI spec files with automatic endpoint pages, request builders, and navigation, and marketing/use-case docs state pages are "updated every time it changes" from the spec you maintain. This directly matches the story of spec-driven, sync-on-change API reference generation. Missing for 10: independent/hands-on verification of automatic re-sync behavior beyond vendor docs, and detail on how sync is triggered (webhook vs CLI vs CI).

   • [claimed-docs] “Generate interactive API documentation from OpenAPI specification files with automatic endpoint pages, request builders, and navigation.”
   • [claimed-docs] “Docs generated directly from your OpenAPI spec. Interactive for developers. Structured for agents. Generated from the spec you already maint…”
   • [claimed-docs] “API playground where user”

   proof ↗⚑ flag

   ReadMe✓fullcommunity8/10

   ReadMe explicitly supports transforming an OpenAPI spec into interactive API reference docs (readme-docs-23), documents accepted OpenAPI versions/file types (readme-docs-32), and offers Git-based workflows to manage API definitions in source control with docs updating from spec changes (readme-docs-44, readme-docs-68). Independent community feedback also notes ReadMe's strong Swagger/OpenAPI support relative to alternatives (readme-comm-7). Missing for 10: no first-party or independent evidence detailing automatic re-sync behavior when the spec file is updated post-publish (e.g., webhook/CI-triggered re-ingestion) or hands-on confirmation of staying in sync over time.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “Check which OpenAPI versions and file types ReadMe accepts, and what your definition gives your API Refe”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

Authoring

1. technical writerI author pages in Markdown/MDX with rich components — tabs, callouts, code groups, steps — without writing custom HTML

   weight 3 · round to ReadMe
   Mintlify—none0/10

   The evidence pack covers Mintlify's editor, CLI, docs.json config, OpenAPI generation, and AI agent features, but nowhere mentions MDX component authoring or built-in rich components like tabs, callouts, code groups, or steps used without custom HTML. Missing for 10: any documentation of MDX component library, callout/tab/code-group syntax examples, or component authoring guides.

   ⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe documents Markdown/MDX authoring with JSX syntax support (readme-docs-42, 81) and slash-command Mermaid diagrams (readme-docs-60), plus reusable Markdown blocks (readme-docs-24, 43), which supports building rich pages without raw HTML. However, the evidence never explicitly names built-in components like tabs, callouts, code groups, or step lists — only MDX/JSX generically and diagrams. Missing for 10: explicit documentation of tabs/callout/code-group/step components, and independent/hands-on confirmation of their availability.

   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “MDX”
   • [claimed-docs] “Add flowcharts, sequence diagrams, and other Mermaid diagrams to your docs with a slash command, written as text rather than images.”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”
   • [claimed-docs] “Create reusable blocks of Markdown content to use repeatedly across your pr”
   • [claimed-docs] “Write long-form tutorials, walkthroughs, and explanations that sit beside your API Reference, in Markdown with MDX support.”

   proof ↗⚑ flag

2. technical writerNon-technical teammates can edit docs in a visual web editor without touching git, and their changes flow into the same source of truth

   weight 2 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify's web editor lets teammates edit pages, preview changes, and open/merge pull requests without touching git directly, with changes flowing into the same repo-backed source of truth (docs.json, git repo) used by developers via CLI/git workflow. Docs explicitly describe editing, previewing, commenting, and merging PRs from within the editor UI. Missing for 10: no independent/hands-on account confirming non-technical teammates successfully use it without any git knowledge, and no detail on permission/collaboration controls for non-technical users.

   • [claimed-docs] “Get started with Mintlify by deploying your documentation site in minutes and making your first content change with the web editor or Git.”
   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”
   • [claimed-docs] “Full platform * Custom domain * Web editor * Authentication * MCP server * API playground”

   proof ↗⚑ flag

   ReadMe✓fullclaimed8/10

   ReadMe provides a visual web editor (Guides/API Reference pages, inline AI editing) alongside bi-directional Git sync, so non-technical teammates can edit in the hub without touching git while changes sync to the same underlying source via branches/reviews. Suggest in GitHub and Reviews further support non-engineer contribution flows feeding into one source of truth. Missing for 10: independent/hands-on evidence (beyond vendor docs) confirming non-technical teammates specifically use the visual editor smoothly, and no explicit description of a WYSIWYG editor UI distinct from Markdown/MDX editing.

   • [claimed-docs] “Write in your preferred environment whether that's ReadMe or your local development setup.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”

   proof ↗⚑ flag

Content reuse

1. technical writerReusable snippets and variables keep repeated content in sync across pages

   weight 1 · round to ReadMe
   Mintlify—none0/10

   No evidence pack items mention reusable snippets, reusable components, or variables/placeholders for keeping repeated content in sync across pages; docs.json covers global site config, not content-level snippets/variables. Absence of evidence for this applicable authoring capability yields none.

   ⚑ flag

   ReadMe✓fullclaimed8/10

   ReadMe's Reusable Content feature lets admins create Markdown blocks reused across multiple pages, with edits automatically propagating to every instance ('Edit once, update everywhere'), directly matching the snippet-sync story; variables are less explicitly documented separately. missing for 10: dedicated documentation/example of a distinct 'variables' feature (vs. reusable Markdown blocks) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Edit once, update everywhere”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”

   proof ↗⚑ flag

Quality

1. technical writerAutomated checks lint my content against a style guide and flag issues before they publish

   weight 2 · round to ReadMe
   Mintlify—none0/10

   Evidence shows CLI catches build errors and broken links, and editor/agent features, but nothing about linting content against a style guide (e.g., prose/style rules, terminology, tone checks) before publishing.

   ⚑ flag

   ReadMe✓fullclaimed7/10

   ReadMe's Linter lets writers define natural-language style rules (e.g., 'Use active voice') that check every page, and Docs Audit runs those rules across the whole site to flag outdated content, broken links, and style inconsistencies before publishing; Reviews also let content be checked with the AI Linter before going live. missing for 10: independent/hands-on evidence of linting accuracy, no detail on pre-publish blocking/gating enforcement, and no third-party corroboration of the feature working in practice.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “An AI-powered tool for checking page content against your own style guide.”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Mintlify
   Mintlify~partialclaimed5/10

   The editor's built-in agent can 'search across your entire repository' and edit pages, reorganize navigation, and update docs.json (mintlify-docs-13/26), and automations can run the agent on schedule or across repo events (mintlify-docs-5), plus a REST API for programmatic management (mintlify-docs-21) — together implying some capacity to act across many docs items at once. However, there is no explicit documentation of a dedicated bulk-operation feature (e.g., batch rename, bulk metadata update, mass content transform) or evidence of it handling large-scale multi-item jobs reliably. Missing for 10: explicit bulk-edit/batch-processing documentation, evidence of scale/performance across many items, and independent confirmation of successful large bulk operations.

   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”
   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”

   proof ↗⚑ flag

   ReadMe~partialprobed4/10

   ReadMe offers a Docs Audit that runs Linter rules across every page in one pass (readme-docs-7, readme-docs-25, readme-docs-52) and an rdme CLI plus ReadMe API for programmatic control (readme-docs-87, readme-probe-3), which enable some bulk-style operations across many docs/pages. However there's no direct evidence of bulk operations across arbitrary 'items' (e.g., batch endpoint edits, bulk publish/delete, bulk API reference updates) beyond the audit/linter and CLI/API scripting potential. missing for 10: explicit bulk edit/publish/delete UI or API examples, documented batch size/limits, independent hands-on confirmation of bulk workflows succeeding at scale.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Mintlify
   Mintlify~partialclaimed6/10

   Mintlify's automations feature lets the agent run on a schedule, on repository pushes, or on connected integration events, which is a form of event-triggered automation, and the redesigned automations are described as pre-built for common use cases rather than a fully custom rule-definition system. This covers the 'trigger on events' part but not clearly the 'define rules/conditions' flexibility an AI-native user might want. Missing for 10: evidence of custom rule/condition authoring beyond selecting pre-built automation types, broader event-source coverage, and independent/hands-on confirmation of automation reliability.

   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “We redesigned automations for quicker setup with pre-built automations optimized for common use cases. Choose the right automations for your…”
   • [claimed-docs] “Every AI action in Mintlify now has a fixed credit price, and you only pay when we deliver a result. Assistant answers and automation update…”

   proof ↗⚑ flag

   ReadMe—none0/10

   ReadMe offers linting rules, GitHub sync, and AI writer proposals, but these are triggered by manual runs or PR events for documentation maintenance, not a general-purpose 'define rules that trigger arbitrary actions on events' automation engine for AI-native users. No evidence of a rules/automation/webhook engine letting users define custom event-triggered actions. missing for 10: an event-trigger/automation rules engine, webhook or conditional action framework, evidence of user-defined triggers beyond docs linting/sync.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Mintlify
   Mintlify~partialclaimed6/10

   Automations run the agent and open PRs (mintlify-docs-4, mintlify-docs-5), which are versioned via git and reviewable through preview deployments and the editor before merge (mintlify-docs-12, mintlify-docs-17, mintlify-docs-25). Rollback capability exists but is documented only as an Enterprise-tier 'instant rollback' for deployments generally, not specifically for automation configurations (mintlify-docs-56, mintlify-docs-61). missing for 10: automation-specific version history/diffing UI, rollback availability for non-Enterprise plans, and independent evidence that rollback works for automation runs specifically.

   • [claimed-docs] “Learn how the Mintlify agent researches, plans, and writes documentation, then opens pull requests with proposed changes for your team to re…”
   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”
   • [claimed-docs] “Instant rollbacks are now live for Mintlify Enterprise customers. You can roll back to a known good deployment in seconds, without waiting o…”
   • [claimed-docs] “Everything in Pro * SSO, SCIM & RBAC * Performance SLA * Advanced insights * Enterprise security & legal * …”

   proof ↗⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe supports versioning of docs content (readme-docs-17), review workflows with AI Linter/teammate approval (readme-docs-12, readme-docs-27), and bi-directional git sync (readme-docs-26) which implicitly enables rollback via git history for AI-driven changes like the GitHub AI Writer's proposed updates (readme-docs-8). However, none of this is framed specifically around 'automations' as a distinct object with version/review/rollback controls — it's inferred from general docs versioning and git integration rather than a dedicated automation-management feature. Missing for 10: an explicit rollback mechanism/UI for AI Agent or automation actions, direct evidence connecting review/versions to 'automations' specifically, and independent corroboration of this workflow in practice.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”

   proof ↗⚑ flag

Review

1. technical writerTeammates propose changes that go through review — comments, approvals, and a merge step — before they publish

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed8/10

   Mintlify's editor and Git-based workflow support PR-style review: preview URLs per pull request, comments/suggestions from the AI agent, and approve-and-merge from within the editor before publishing (mintlify-docs-12, mintlify-docs-17, mintlify-docs-25, mintlify-docs-26). This covers comments, preview/approval, and merge steps gating publication. missing for 10: independent/hands-on confirmation of the review UI in practice, and explicit documentation of multi-reviewer approval gating (e.g., required approvers) beyond generic PR/merge mechanics.

   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's Reviews feature explicitly supports pre-publish approval workflows — teammates can check changes for issues or get approval before they go live, and the branch-based model (Branch menu) implies a merge-into-main step. However, the evidence never explicitly mentions inline comments/discussion threads, only 'approval' and 'AI Linter' checks, and there's no dedicated documentation of the merge action itself. Missing for 10: explicit comment/discussion functionality within reviews, and clear documentation of the merge step that finalizes publishing.

   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”

   proof ↗⚑ flag

Theming

1. devrel leadI customize themes, fonts, and layout — down to custom CSS/JS or my own components — so the docs match my brand

   weight 2 · round to ReadMe
   Mintlify~partialclaimed5/10

   docs.json is documented as the central config controlling 'visual branding, navigation structure' etc., which supports theme/font/layout customization, but the evidence pack never mentions custom CSS/JS injection or embedding custom React/UI components for deeper brand control. Missing for 10: explicit documentation of custom CSS/JS support, custom component embedding, and independent confirmation that deep branding beyond docs.json settings is possible.

   • [claimed-docs] “The `docs.json` file is the central configuration file for your Mintlify documentation site. It controls your site's global settings, includ…”
   • [claimed-docs] “The docs.json file is the central configuration file for your Mintlify documentation site. It controls your site's global settings, includin…”
   • [claimed-docs] “Host your site at your own domain, subdomain, or subpath with DNS records, automatic TLS certificates, and Mintlify-managed or proxy traffic…”

   proof ↗⚑ flag

   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly cover theme presets with brand color/typography tuning, custom CSS (variables or raw rules), custom JavaScript and include tags, custom domain/SSL, and MDX support for custom components, directly matching the DevRel branding customization story. A community testimonial (Heap Analytics) also corroborates the visual customization experience in practice. Missing for 10: independent/hands-on verification of deep custom-JS/component work beyond vendor docs, and no evidence of a fully custom component framework beyond MDX.

   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules.”
   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules. The most flexible is to use CSS variables.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Apply your own CSS, JavaScript, and include tags to your hub, with the plan requirements and toggles for each.”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “Use Font Awesome 7 Regular and Duotone icons in your docs, including how to hide a decorative icon from screen readers.”
   • [community] “Heap Analytics moved docs to ReadMe.io: 'The ReadMe team is really responsive and helpful, the documentation is beautiful and the interface …”

   proof ↗⚑ flag

Git workflow

1. developerMy docs live in my own git repository — branches, pull requests, and merges drive what gets published

   weight 3 · round drawn
   Mintlify✓fullclaimed8/10

   Mintlify is explicitly git-based: docs live in a repo, CLI enables local preview before commits, PR preview deployments let reviewers see changes before merge, and the editor supports reviewing/merging PRs directly. This is core to Mintlify's docs-as-code model. Missing for 10: independent/hands-on confirmation of the git workflow (only vendor docs), and no detail on branch-based environment mapping beyond PR previews.

   • [claimed-docs] “Get started with Mintlify by deploying your documentation site in minutes and making your first content change with the web editor or Git.”
   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”
   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”

   proof ↗⚑ flag

   ReadMe✓fullclaimed8/10

   ReadMe supports bi-directional GitHub/GitLab/Bitbucket sync, git-based workflows with Markdown/OpenAPI in-repo, pull requests as the review step, and branch-based review before publishing (readme-docs-26, readme-docs-44, readme-docs-45, readme-docs-46, readme-docs-67, readme-docs-70, readme-docs-68). This directly matches docs-as-code with branches/PRs/merges driving publishing. missing for 10: independent/hands-on confirmation of the git-sync workflow in practice (community evidence is thin/tangential) and more detail on merge conflict handling.

   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Sync with GitHub”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”

   proof ↗⚑ flag

2. developerEvery docs pull request gets a shareable preview deployment before it merges

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed8/10

   Mintlify explicitly documents per-PR preview deployments with unique preview URLs so reviewers can view doc changes before merging (mintlify-docs-17, -35, -49), plus editor-based preview-then-merge workflow (mintlify-docs-12/25) and CLI local preview (mintlify-docs-11/29). Missing for 10: independent/hands-on confirmation of the preview-URL workflow in practice and detail on how previews integrate with GitHub PR checks/comments.

   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “Get uni”
   • [claimed-docs] “Create or update a preview deployment for a specific branch. If a preview already exists for the branch, it triggers a redeployment.”
   • [claimed-docs] “Preview your changes before they reach your live site, then review and merge the pull request without leaving the editor.”
   • [claimed-docs] “Preview changes before they go live, share them with your team, and approve and merge pull requests from the editor.”
   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”

   proof ↗⚑ flag

   ReadMe—none0/10

   No evidence describes per-PR shareable preview deployments of docs; ReadMe's docs-as-code features cover bi-directional sync, Reviews (AI Linter/teammate approval), and branch-based exports, but nothing indicates an automatic preview URL generated for each pull request before merge.

   ⚑ flag

Quality gates

1. developerCI validation catches broken links and invalid configuration before the site publishes

   weight 2 · round to Mintlify
   Mintlify~partialclaimed4/10

   The CLI docs mention that it lets you 'catch build errors before deploying to production' and PR preview deployments let reviewers see changes before merge, which implies some validation, but there's no explicit mention of automated CI pipeline integration, broken-link checking, or docs.json/config validation as a distinct CI step. missing for 10: explicit CI/CD integration docs (e.g., GitHub Actions), documented broken-link checker, and config schema validation output.

   • [claimed-docs] “Install the Mintlify CLI to preview documentation locally, test changes in real time, and catch build errors before deploying to production.”
   • [claimed-docs] “Get unique preview URLs for each pull request so reviewers can see documentation changes in a live environment before merging to production.”
   • [claimed-docs] “The `docs.json` file is the central configuration file for your Mintlify documentation site. It controls your site's global settings, includ…”

   proof ↗⚑ flag

   ReadMe—none0/10

   ReadMe's docs mention Docs Audit/Linter for style/broken-link checks and Reviews as a manual approval gate, and bi-directional sync with Git, but there is no evidence of a CI pipeline check (e.g., rdme CLI command or GitHub Action) that validates links/config and blocks a publish/merge automatically before the site goes live. missing for 10: evidence of an automated CI/CD integration (CLI command or GitHub Action) that runs link/config validation and fails the build pre-publish, and any confirmation that Docs Audit/Linter can be invoked as a CI gate rather than a manual dashboard action.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Mintlify~partialprobed6/10

   Mintlify offers a REST API for deployments, analytics, and assistant embedding, plus an admin MCP server giving AI tools write access to edit pages, update settings, and open PRs — covering much of what the UI/editor does. However, the OpenAPI spec for the API itself is not discoverable (probe returned 404 on all candidate paths), and some editor-only capabilities (e.g., in-editor commenting/suggestions, live preview UI) aren't clearly exposed as discrete API operations, leaving parity unproven for the full UI feature set. missing for 10: published/discoverable OpenAPI spec for the REST API, explicit API-level parity documentation for editor-only actions like commenting/navigation reorg, independent verification that all UI actions map to API/MCP calls.

   • [claimed-docs] “Give AI tools like Claude, ChatGPT, and Cursor write access to your Mintlify content and dashboard so they can edit pages, update settings, …”
   • [claimed-docs] “Use the Mintlify REST API to trigger deployments, embed an AI assistant, export analytics data, and manage documentation programmatically.”
   • [claimed-docs] “The editor includes a built-in agent that can edit pages, reorganize navigation, update `docs.json`, search across your entire repository, a…”
   • [claimed-docs] “Use the editor's built-in AI agent to write content, edit pages, leave comments and suggestions, search your site, upload files, and configu…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.mintlify.com/openapi.json, https://www.mintlify.com/swagger.json, https://www.mintlify.c…”
   • [probe] “official MCP server documented at https://www.mintlify.com/docs/ai/mintlify-mcp”

   proof ↗⚑ flag

   ReadMe~partialprobed6/10

   ReadMe documents a full ReadMe API for programmatic control (readme-docs-87) plus an official CLI (rdme, readme-probe-3) and bi-directional GitHub/GitLab sync (readme-docs-26/46), suggesting most content, versioning, and docs management actions can be done via API/CLI/Git instead of the UI. However, the evidence doesn't confirm parity for every UI feature (e.g., Reviews approval workflows, Linter/Docs Audit runs, custom CSS/domain setup, Analytics/metrics views) being fully scriptable via the API, and no independent confirmation of full UI/API parity exists. missing for 10: explicit API/CLI equivalents for Reviews, Linter/Docs Audit, Analytics dashboards, and custom domain/CSS configuration, plus independent verification of full parity.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Mintlify~partialcommunity5/10

   Docs content is authored in Markdown/MDX and lives in the user's own Git repo, and Mintlify explicitly supports exporting clean Markdown per page ([mintlify-docs-9],[mintlify-docs-23]) plus a self-host option ([mintlify-docs-18]), all reducing lock-in for the core documentation content. However, evidence only covers migrating *to* Mintlify from other platforms ([mintlify-docs-54]), not exporting non-content data (analytics, assistant conversation logs, settings) or a documented 'leave' path, and Mintlify is confirmed not open-source with proprietary backend features ([mintlify-comm-1]). Missing for 10: full data export (analytics/assistant history/config) in open formats, documented process for migrating away from Mintlify, and independent confirmation of no lock-in beyond content markdown.

   • [claimed-docs] “Add `.md` to any page's URL to view a Markdown version.”
   • [claimed-docs] “Export clean Markdown versions of your documentation pages for AI tools, LLM integrations, and automated content processing workflows.”
   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises environment, on AWS or any Kubernetes platform including Azure, Google Cloud, Oracle Cloud…”
   • [claimed-docs] “Migrate your documentation to Mintlify from ReadMe, GitBook, Docusaurus, Fern, or any platform. Get migration support and up to 12 months fr…”
   • [community] “If anyone is wondering, Mintlify is not open source: the license restricts the backend enterprise features to source-available only.”

   proof ↗⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe supports exporting docs files or PDF from the Branch menu, giving some data portability, but this is limited to documentation content and PDF/file export, not a full open-format export of all underlying data (API metrics, analytics, custom pages, versions, reusable content blocks) in machine-readable open formats like JSON/Markdown source. missing for 10: evidence of exporting all account/project data (metrics, settings, versions) in open formats, confirmation of underlying file format (e.g., raw Markdown vs proprietary), and independent/hands-on confirmation of a full data export and migration path away from ReadMe.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Mintlify—none0/10

   No vendor documentation claims Mintlify's source is available under an open license; community evidence explicitly states the opposite — 'Mintlify is not open source: the license restricts the backend enterprise features to source-available only' and it is 'pure SaaS.' There is no CLI, repo, or license evidence supporting open-source access to Mintlify's own source code.

   • [community] “If anyone is wondering, Mintlify is not open source: the license restricts the backend enterprise features to source-available only.”
   • [community] “We have a highly regulated environment... It is very nifty but it is pure SaaS, and I don't care how secure they are, having our source flow…”

   proof ↗⚑ flag

   ReadMe—none0/10

   ReadMe is a closed, proprietary SaaS documentation platform; there is no evidence of its core product source being released under an open license (only a CLI tool 'rdme' is open-source, not the product itself). No evidence supports an open-license source availability for the platform.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Mintlify
   Mintlify!disputedcontradicted5/10

   Vendor docs explicitly describe running Mintlify in your own cloud/on-prem (AWS or any Kubernetes platform) as a supported deployment mode, which would satisfy self-hosting the core product. However, independent community reports directly contradict this framing, describing Mintlify as 'pure SaaS' unsuitable for regulated environments and noting the product is not open source (only source-available for enterprise backend features), suggesting genuine self-hosting is either unavailable, gated, or not as advertised for most users. Missing for 10: clear evidence self-hosting is broadly available (not enterprise-sales-gated), independent confirmation of a successful self-hosted deployment, and resolution of the open-source/source-available licensing tension.

   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises environment, on AWS or any Kubernetes platform including Azure, Google Cloud, Oracle Cloud…”
   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises enviro”
   • [community] “If anyone is wondering, Mintlify is not open source: the license restricts the backend enterprise features to source-available only.”
   • [community] “We have a highly regulated environment... It is very nifty but it is pure SaaS, and I don't care how secure they are, having our source flow…”

   proof ↗⚑ flag

   ReadMe—none0/10

   ReadMe is a SaaS-only hosted documentation platform; there is no evidence of a self-hostable core product, Docker image, or on-prem deployment option. Community evidence even shows a user switching to open-source Docusaurus specifically to avoid ReadMe's hosted costs, and a request for an open-source-friendly plan went unmet, further indicating no self-hosting path exists.

   • [community] “Wish there was a plan for opensource projects, which allowed me to use customized landing page etc.”
   • [community] “Blog post titled 'From Readme to Docusaurus: How an Intern Saved Us $1.2k', describing a switch away from ReadMe.com to the open-source Docu…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Mintlify—none0/10

   No evidence of data residency/region selection controls; self-hosting on own cloud (mintlify-docs-18/36) offers infrastructure control but is not a documented data-residency/region-choice feature, and enterprise security items don't mention residency options.

   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises environment, on AWS or any Kubernetes platform including Azure, Google Cloud, Oracle Cloud…”
   • [claimed-docs] “Everything in Pro * SSO, SCIM & RBAC * Performance SLA * Advanced insights * Enterprise security & legal * …”

   proof ↗⚑ flag

   ReadMe—none0/10

   No evidence in the pack addresses data residency, regional storage selection, or data location controls for ReadMe; the docs cover editing, MCP, analytics, and customization but never data-residency options.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Mintlify—none0/10

   No evidence in the pack addresses opting out of AI training data usage, data privacy controls, or a training-data policy; evidence instead covers documentation/AI feature functionality and unrelated security incidents. Missing for 10: any documented privacy policy, opt-out mechanism, or contractual terms about AI training data use.

   ⚑ flag

   ReadMe—none0/10

   No evidence in the pack addresses AI training data opt-out or any data-privacy controls related to AI model training; ReadMe's docs cover documentation/AI-assistant features but not this privacy posture.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Mintlify—none0/10

   No evidence pack item addresses data retention policies, deletion controls, or data lifecycle management for user/customer data; security-related community complaints (token storage, GitHub permissions) touch security concerns but not retention/deletion controls specifically. This axis clearly applies to a SaaS documentation platform handling customer content, so absence of evidence yields 'none'.

   ⚑ flag

   ReadMe—none0/10

   The evidence pack covers documentation authoring, MCP server setup, AI writing tools, and content export/versioning, but nothing addresses data retention policies or user-controlled deletion of stored data (e.g., MCP call logs, Ask AI query history, or account data). Analytics features like MCP Metrics explicitly record every AI tool call, but no docs describe retention windows or deletion controls for that data.

   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [claimed-docs] “Export your docs using our built-in features, tooling, and our API.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Mintlify—none0/10

   No evidence pack item mentions telemetry opt-out or usage-tracking controls; analytics dashboard is documented but only as a feature to view traffic/engagement, not as something users can disable. Community items raise general privacy/security concerns (e.g., token storage, monitoring gaps) but don't address a telemetry opt-out mechanism specifically.

   ⚑ flag

   ReadMe—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out settings for ReadMe; nothing describes data collection controls or privacy toggles. Missing for 10: any documentation of telemetry practices, an opt-out mechanism, or privacy settings related to usage tracking.

   ⚑ flag

Access control

1. devrel leadI gate some or all docs behind authentication — password, JWT, or SSO — for customers-only content

   weight 1 · round to Mintlify
   Mintlify~partialclaimed5/10

   Mintlify's pricing page explicitly lists 'Authentication' as a Full-platform feature and 'SSO, SCIM & RBAC' as Enterprise-tier features, confirming gated/authenticated docs support at different tiers. However, the evidence pack contains no dedicated documentation page detailing how to configure password protection, JWT-based gating, or SSO setup mechanics, nor independent confirmation of how it works in practice. Missing for 10: a docs page describing JWT/password auth configuration, setup steps, and independent/hands-on verification of gated access working as described.

   • [claimed-docs] “Full platform * Custom domain * Web editor * Authentication * MCP server * API playground”
   • [claimed-docs] “Everything in Pro * SSO, SCIM & RBAC * Performance SLA * Advanced insights * Enterprise security & legal * …”

   proof ↗⚑ flag

   ReadMe—none0/10

   Evidence covers SSO only for internal Teammates sign-in (readme-docs-84) and admin permission control (readme-docs-63), but nothing describes gating published customer-facing docs behind password, JWT, or SSO authentication for readers/customers. missing for 10: reader-facing password protection, JWT-based authenticated docs, SSO gating for external customers viewing docs.

   • [claimed-docs] “Connect your identity provider and let Teammates sign in with SSO”
   • [claimed-docs] “Control who can access admin controls and edit content.”

   proof ↗⚑ flag

Domains

1. devrel leadI serve docs on my own custom domain or as a /docs subpath of my main site

   weight 2 · round to Mintlify
   Mintlify✓fullclaimed9/10

   Mintlify's docs explicitly support hosting at a custom domain, subdomain, or subpath with DNS/TLS handled, and this custom domain capability is also listed as a core Pro-tier feature on pricing. Missing for 10: independent/hands-on confirmation of subpath routing behavior beyond first-party docs.

   • [claimed-docs] “Host your site at your own domain, subdomain, or subpath with DNS records, automatic TLS certificates, and Mintlify-managed or proxy traffic…”
   • [claimed-docs] “Host your site at your own domain, su”
   • [claimed-docs] “Full platform * Custom domain * Web editor * Authentication * MCP server * API playground”

   proof ↗⚑ flag

   ReadMe✓fullclaimed8/10

   ReadMe's docs explicitly cover custom domain setup with CNAME, apex vs subdomain, and SSL certificates, framed as making docs 'polished and professional' on a company domain, which directly matches the custom-domain part of the story; the /docs subpath scenario is implicitly covered via apex/subdomain configuration options. Missing for 10: explicit first-party or independent confirmation of serving docs specifically as a path-based /docs subpath (vs subdomain) on the main domain.

   • [claimed-docs] “Hosting docs on your company domain is an important part of making your docs polished and professional. You can setup a custom domain from *…”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Custom Domain & SSL”

   proof ↗⚑ flag

Portability

1. developerExport my entire docs site as a static bundle and host it anywhere, so my content is never locked in

   weight 2 · round to Mintlify
   Mintlify~partialcommunity4/10

   Mintlify offers self-hosting on your own cloud/Kubernetes and per-page Markdown export, which mitigate some lock-in, but there is no documented feature to export the entire site as a portable static bundle usable on arbitrary hosting outside Mintlify's runtime. Community commentary also flags Mintlify as proprietary/SaaS-locked (not open-source, backend not portable). Missing for 10: a documented 'export static site' or 'build to static HTML' command, confirmation that self-host doesn't require Mintlify's proprietary backend, and independent verification of portability.

   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises environment, on AWS or any Kubernetes platform including Azure, Google Cloud, Oracle Cloud…”
   • [claimed-docs] “Run Mintlify inside your own cloud or on-premises enviro”
   • [claimed-docs] “Add `.md` to any page's URL to view a Markdown version.”
   • [claimed-docs] “Export clean Markdown versions of your documentation pages for AI tools, LLM integrations, and automated content processing workflows.”
   • [community] “If anyone is wondering, Mintlify is not open source: the license restricts the backend enterprise features to source-available only.”
   • [community] “I find these solutions actually make documentation harder. They're binary and proprietary, locked behind a paywall... My code is plain text,…”
   • [community] “We have a highly regulated environment... It is very nifty but it is pure SaaS, and I don't care how secure they are, having our source flow…”

   proof ↗⚑ flag

   ReadMe~partialclaimed3/10

   ReadMe docs mention exporting files or a PDF from the Branch menu, which shows some content-export capability, but there is no evidence of exporting the entire docs site as a deployable static bundle (with API reference, navigation, styling, etc.) that can be self-hosted elsewhere — the product is fundamentally a hosted SaaS platform. missing for 10: full static-site export/bundle, documentation of self-hosting elsewhere, independent confirmation that exported files constitute a complete replica of the hosted site.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

Search

1. developerReaders get fast, typo-tolerant, relevance-ranked search over the whole docs site out of the box

   weight 3 · round to Mintlify
   Mintlify~partialclaimed6/10

   Mintlify docs confirm a built-in in-product search bar with relevance ranking (boost multipliers, chunk relevance scores) and configurable filters/result limits, indicating search ships out of the box and is tunable for relevance. However, there's no explicit documentation or evidence of typo-tolerance or fuzzy-matching, nor independent benchmarks of search speed/quality across a full site. Missing for 10: explicit typo-tolerance/fuzzy search claims, performance/speed evidence, and independent hands-on validation of search quality.

   • [claimed-docs] “Use `boost` to bias the in-product search ranking of specific pages or sections. The value is a numeric multiplier applied to each chunk's r…”
   • [claimed-docs] “Configure the in-product search bar on your Mintlify-hosted documentation site: ranking boosts, maximum results per query, and product and v…”
   • [claimed-docs] “Configure in-product search ranking, results, and filters”

   proof ↗⚑ flag

   ReadMe—none0/10

   The evidence pack describes Ask AI (AI-generated answers from docs) and MCP/agent discoverability features, but contains no mention of a traditional full-text search index, typo-tolerance, or relevance ranking for the docs site itself. Search-discovery via a classic search bar is a plausible axis for a docs platform, but no evidence confirms it delivers fast, typo-tolerant, relevance-ranked search out of the box.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”
   • [claimed-docs] “Ask AI gives your users instant answers from your published documentat”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”

   proof ↗⚑ flag

Localization

1. technical writerI publish my docs in multiple languages with translated navigation and content

   weight 1 · round drawn
   Mintlify—none0/10

   The evidence pack covers Mintlify's docs.json config, CLI, editor, deployment, analytics, search, and AI features extensively, but there is no mention anywhere of multi-language/localization support, translated navigation, or i18n content structures.

   ⚑ flag

   ReadMe—none0/10

   No evidence of multi-language documentation publishing, translated navigation, or i18n/localization features; 'Pick a language' (readme-docs-2) refers to code-sample language selection, not content localization. Versioning docs (readme-docs-17, readme-docs-48) address content versions, not language translation.

   ⚑ flag

Versioning

1. developerI publish versioned documentation per product or API version, and readers switch versions from the site

   weight 3 · round to ReadMe
   Mintlify~partialclaimed3/10

   The only hint of version support is a mention that Mintlify's in-product search can be filtered by 'product and version,' implying some notion of versioned content exists, but there is no documentation of creating multiple documentation versions, a version switcher UI, or how readers navigate between versions on the site. missing for 10: explicit docs on defining/publishing multiple versions, a reader-facing version switcher, and any hands-on confirmation that this works as described.

   • [claimed-docs] “Use `boost` to bias the in-product search ranking of specific pages or sections. The value is a numeric multiplier applied to each chunk's r…”
   • [claimed-docs] “Configure the in-product search bar on your Mintlify-hosted documentation site: ranking boosts, maximum results per query, and product and v…”
   • [claimed-docs] “Configure in-product search ranking, results, and filters”

   proof ↗⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe's docs explicitly state that maintaining multiple versions of documentation is a supported, important feature (readme-docs-17), confirming per-product/API version publishing capability. However, the evidence pack contains no detail on the actual version-switcher UI or reader-facing mechanism for switching versions from the site, nor any independent/community confirmation of this workflow. Missing for 10: documentation or screenshots of the reader-facing version switcher, confirmation of how versions map to distinct URLs/hubs, and independent corroboration that readers can toggle versions seamlessly.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”

   proof ↗⚑ flag