Mintlify vs Docusaurus

Agent access

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

   weight 2 · round to Mintlify
   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

   Docusaurus—none0/10

   Probes show Docusaurus's own site has no llms.txt (404) and no agent-oriented docs.md endpoint (404), and no docs evidence describes shipping llms.txt support for generated sites either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   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

   Docusaurus~partialprobed6/10

   Docusaurus ships a documented CLI (`npm run build`, `docusaurus serve`) that produces static files non-interactively, which is the basis for running it in CI/CD pipelines (e.g., building docs on every push and deploying to Vercel/Netlify/GitHub Pages), and this is a standard, well-documented workflow for static-site generators. However, there's no first-party CI-specific guide (e.g., GitHub Actions workflow) in the evidence, and community reports describe build performance problems severe enough to time out GitHub Actions runners on larger sites, which undercuts reliability for automation at scale. Missing for 10: explicit CI/automation documentation or example workflow, and independent confirmation of successful large-scale CI builds (contradicted in part by comm-10's report of CI timeouts).

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [community] “I haven't used Starlight, but Docusaurus is very slow. The last time I used it, its performance on a large documentation site was terrible, …”
   • [community] “I tried migrating our markdown docs-as-code to use Docusaurus, we have somewhere around several hundred pages, and the build times seemed ve…”

   proof ↗⚑ flag

3. 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

   Docusaurus✓fullprobed7/10

   Docusaurus ships a well-documented official CLI (create-docusaurus scaffolding, docusaurus start/build/serve, versioning and swizzle commands) confirmed by docs and a probe hit on /docs/cli, all scriptable via npm and usable non-interactively by automation/agents. Missing for 10: no explicit documentation or examples of AI-agent-specific usage/integration, and no independent hands-on confirmation of CLI reliability in automated/agentic pipelines.

   • [claimed-docs] “npx create-docusaurus@latest my-website classic”
   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”

   proof ↗⚑ flag

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

   weight 3 · round to Mintlify
   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

   Docusaurus~partialprobed4/10

   Docusaurus exposes a documented CLI (build, serve, versioning commands) and a plugin/Node API that let a user or script drive site generation and customization programmatically, which is the closest analog to a public API for this static-site-generator category. However, probes confirm there is no REST/OpenAPI, no llms.txt, and no HTTP-callable interface for AI agents to interact with — only local CLI/build-time automation. Missing for 10: HTTP/REST or OpenAPI-documented API, AI-agent discovery file (llms.txt), and any remote/service-style programmatic interface beyond local CLI/plugin hooks.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “Builds and serves a preview of your site locally with [Webpack Dev Server]”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Docusaurus
   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

   Docusaurus~partialprobed5/10

   Docusaurus documents official developer-facing APIs to build against — a plugin architecture (docs-4, docs-8, docs-25), theme swizzling API (docs-10, docs-27), and a documented CLI (docusaurus-probe-4, docusaurus-docs-11) — which count as 'official SDKs' for extending/building sites. However, there is no AI-native machine-readable SDK surface: llms.txt and docs.md both 404, and no OpenAPI spec exists (docusaurus-probe-1, docusaurus-probe-2, docusaurus-probe-3), so an AI agent cannot discover or consume an official SDK spec automatically. Missing for 10: machine-readable API/SDK manifests (llms.txt, OpenAPI), any AI-specific SDK or agent-facing integration docs, and independent confirmation that the plugin/theme APIs are stable enough to be treated as a true SDK.

   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Mintlify
   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

   Docusaurus—none0/10

   Docusaurus's evidence shows only generic MDX/React embedding, versioning, i18n, and search features—no built-in interactive API reference or runnable-example tooling (e.g., OpenAPI/Swagger integration) is documented, and probes for openapi.json/swagger.json all return 404. While MDX could theoretically host custom interactive widgets, there's no evidence of a first-party or documented capability for this specific story.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   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

   Docusaurus—none0/10

   Docusaurus is a documentation site generator, not an API service, but it could plausibly expose a machine-readable spec of its own CLI/config or plugin API; probes explicitly show no OpenAPI/swagger spec exists at any expected path, and no docs mention publishing one.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

3. 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

   Docusaurus—none0/10

   The pack shows Docusaurus has a 'document versioning' feature for content (docs-6, docs-19, docs-23), but that is unrelated to the story's ask about the framework's own APIs (plugin API, config schema, npm package) being semantically versioned with a documented deprecation policy. No evidence of a changelog, semver policy, or deprecation notices for Docusaurus's own APIs is present; the only related note is that v2 was a 'total rewrite' from v1 (docusaurus-docs-16), which suggests breaking changes rather than a managed deprecation path.

   • [claimed-docs] “Docusaurus v2+ has been a total rewrite from Docusaurus v1, taking advantage of a completely modernized toolchain.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”

   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 to Mintlify
   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

   Docusaurus—none0/10

   No evidence Docusaurus generates or exposes an MCP server for published docs sites; search is via Algolia DocSearch, not an agent-queryable MCP endpoint, and probes for llms.txt/docs.md/openapi all 404.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   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

   Docusaurus—none0/10

   No evidence Docusaurus core ships automatic llms.txt or full-content markdown variant generation; direct probes of the Docusaurus own site show 404 for both llms.txt and docs.md, and no docs mention this feature.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   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

   Docusaurus—none0/10

   Docusaurus builds static HTML from Markdown/MDX but there is no evidence of a per-page clean-markdown endpoint (e.g. .md suffix) or llms.txt-style output; direct probes confirm llms.txt and docs.md both 404, indicating this capability is not shipped.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   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

   Docusaurus—none0/10

   No evidence of an embedded AI assistant or Q&A-with-citations feature; Docusaurus documentation covers search (Algolia DocSearch), MDX, plugins, versioning, i18n, etc., but nothing about an AI chat/assistant answering reader questions with citations into content.

   ⚑ flag

Analytics

1. 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

   Docusaurus—none0/10

   Docusaurus is a static site generator; evidence shows search (Algolia DocSearch) support but nothing about built-in analytics dashboards, page-view tracking, search-term analytics, or reader feedback collection. No evidence of any such capability exists in the pack.

   ⚑ flag

Playground

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

   weight 2 · round to Mintlify
   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

   Docusaurus—none0/10

   Docusaurus is a static-site/documentation generator supporting MDX, React embeds, versioning, i18n, and search, but nothing in the evidence pack shows a built-in interactive API playground/try-it-out console for making real API calls; probes for OpenAPI support also failed (404s). Developers could theoretically embed a custom React component for this via MDX, but no evidence shows an out-of-the-box or officially supported playground feature.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   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 to Mintlify
   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

   Docusaurus—none0/10

   No evidence pack item mentions OpenAPI spec import, API reference page generation, or spec-sync capability; Docusaurus core is described as a Markdown/MDX static-site generator with docs/blog/pages plugins, not an OpenAPI-driven doc generator. The OpenAPI probe explicitly found no such endpoints/support.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “All features are delegated to individual plugins: the [docs](/docs/docs-introduction) feature provided by the [docs plugin]”

   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 Docusaurus
   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

   Docusaurus~partialcommunity6/10

   Docusaurus docs confirm built-in MDX/JSX support letting writers embed and import React components directly in Markdown without hand-writing HTML (docusaurus-docs-3, docusaurus-docs-17, docusaurus-docs-31, docusaurus-docs-32), and community users confirm using Markdown+React together happily (docusaurus-comm-13, docusaurus-comm-20). However, the evidence never explicitly names or documents the specific built-in rich components the story calls out (Tabs, admonitions/callouts, code-block groups, Steps) — it only shows general MDX/component-embedding capability. missing for 10: explicit docs citing built-in Tabs/Admonition/CodeBlock-group/Steps components, and hands-on confirmation that writers use them without custom code.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “You can even embed React components in your Markdown thanks to MDX.”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   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 to Mintlify
   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

   Docusaurus—none0/10

   Docusaurus is a git-based, MDX/React static site generator with no visual web editor for non-technical users — all editing happens via markdown files and git workflows; no evidence of a WYSIWYG editor or non-git content sync.

   ⚑ flag

Content reuse

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

   weight 1 · round to Docusaurus
   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

   Docusaurus~partialclaimed6/10

   Docusaurus's MDX support lets writers define partial files and import them as reusable components across pages (docs-3, docs-31), which is the documented mechanism for reusable snippets, but the evidence pack never explicitly mentions a dedicated 'variables' or site-wide constants feature (e.g. customFields) or admonition-style snippet reuse guidance. missing for 10: explicit docs on site-wide variables/customFields, dedicated partials/snippets guide, independent hands-on confirmation that content stays in sync across pages.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”

   proof ↗⚑ flag

Quality

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

   weight 2 · round drawn
   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

   Docusaurus—none0/10

   No evidence of any built-in or first-party linting/style-guide checking feature for content; Docusaurus docs cover MDX authoring, versioning, i18n, search, deployment, but nothing about automated prose/style linting before publish.

   ⚑ 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

   Docusaurus—none0/10

   Docusaurus is a static site generator with a CLI for building/serving sites, but there is no evidence of any bulk operation capability across many content items (e.g., bulk editing, batch content transformation, mass metadata updates) beyond a single site build/version command; probes for machine-readable APIs (llms.txt, docs.md, openapi) all returned 404, showing no programmatic bulk-automation surface. Missing for 10: any documented bulk-edit/batch-processing feature, API or CLI subcommand for operating across many items at once, and evidence of AI-native automation tooling.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   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 Docusaurus
   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

   Docusaurus✓fullcommunity9/10

   Docusaurus provides multiple documented layers of theming/branding: custom CSS import via classic theme (docusaurus-docs-9/26/41), full React component customization and MDX embedding (docusaurus-docs-4/31/33), and swizzling to override/replace built-in theme components entirely (docusaurus-docs-10/27), plus a plugin architecture for deeper extension (docusaurus-docs-8/40). Community testimonials corroborate real-world use of React/TypeScript/CSS customization (docusaurus-comm-13/20). Missing for 10: independent hands-on verification specifically of brand-level theming (fonts/logo/full rebrand) rather than general customization mentions.

   • [claimed-docs] “you can create your own CSS files (e.g. /src/css/custom.css) and import them globally by passing them as an option of the classic theme.”
   • [claimed-docs] “If you're using `@docusaurus/preset-classic`, you can create your own CSS files (e.g. `/src/css/custom.css`) and import them globally”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “swizzling permits to **swap a theme component with your own implementation**”
   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Extend and customize your project's layout by writing React components.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   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

   Docusaurus✓fullcommunity8/10

   Docusaurus is fundamentally a static-site generator that builds from Markdown/MDX files stored in your own repo, and its docs plugin explicitly reads content from a `docs` directory that you version-control (versioning CLI operates on `docs` directory content), with localization also handled 'via git' or other translation managers. It deploys to static hosts like GitHub Pages, Netlify, Vercel that are commonly wired to git push/PR/merge triggers, and community users confirm using it for markdown-based docs-as-code workflows (migrating docs, contributing via git). Missing for 10: no explicit documentation of PR-preview builds, branch-based deploy previews, or CI/CD pipeline configuration specifics.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ 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

   Docusaurus—none0/10

   No evidence pack items mention broken-link checking, config validation, or CI integration/build-failure behavior for invalid content; only build/serve/deploy CLI commands are documented. This is a fair axis for a docs-as-code SSG (Docusaurus does have onBrokenLinks options in reality, but nothing in the evidence pack supports it).

   ⚑ flag

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

   weight 3 · round to Docusaurus
   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

   Docusaurus✓fullcommunity8/10

   Docusaurus content is authored as plain Markdown/MDX files stored in the user's own git repo and compiled to static HTML, meaning there is no proprietary data store to 'export from' — the source of truth is already an open, portable format the user fully owns, reinforced by MIT licensing and git/Crowdin-based translation workflows. missing for 10: no explicit vendor documentation framing this as a 'data export/exit' guarantee, and no independent report confirming users successfully migrated away with zero data loss (only anecdotal mentions of switching to other SSGs).

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “For writing technical styled documentation, I've found fumadocs to be amazing... We just moved to it from Docusaurus and couldn't be happier…”

   proof ↗⚑ flag

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

   weight 2 · round to Docusaurus
   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

   Docusaurus✓fullcommunity7/10

   Community evidence confirms Docusaurus is open source and MIT licensed, with users noting they can read, fork, and contribute to the source code (docusaurus-comm-16, docusaurus-comm-1). No evidence contradicts open licensing. missing for 10: first-party documentation or GitHub repo citation explicitly stating the MIT license, and no direct link to the source repository in the evidence pack.

   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “So happy to see Docusaurus hit the big 2.0! I use it to power my blog and it's a tremendous tool. The DX is fantastic and it's open source! …”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Docusaurus
   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

   Docusaurus✓fullcommunity9/10

   Docusaurus is a static-site generator that builds fully self-hostable static HTML output via `npm run build`, deployable to any static host (Vercel, Netlify, GitHub Pages, or self-managed servers) with no vendor lock-in, and is MIT licensed so it can be forked/self-maintained indefinitely. Community evidence corroborates real-world self-hosting and even forking concerns being addressed by its open license. Missing for 10: no first-party Docker/container self-hosting guide or independent benchmark of a fully self-hosted deployment pipeline.

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   proof ↗⚑ flag

1. 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

   Docusaurus—none0/10

   The evidence pack contains no mention of telemetry, analytics collection, or an opt-out mechanism for Docusaurus's CLI or build process; while such a capability is plausible for a CLI-driven static site generator, there is no documentation or community evidence confirming it exists.

   ⚑ 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

   Docusaurus—none0/10

   Docusaurus is a static site generator; the evidence pack contains no mention of built-in authentication, password protection, JWT, or SSO gating features. Since Docusaurus builds static HTML files meant to be publicly served (docs-2, docs-13), auth-gating is a plausible but unaddressed capability for a docs publishing tool, making this 'none' rather than 'na'.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   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

   Docusaurus~partialclaimed5/10

   Docusaurus docs confirm it builds static files deployable to common static hosts (Vercel, GitHub Pages, Netlify, etc.) and provides a `docusaurus serve` command, which implicitly supports custom domains via those hosts. However, the evidence pack never explicitly documents the `baseUrl` config for subpath deployment or custom-domain setup instructions (e.g., CNAME files), leaving the core of the story only inferred rather than directly evidenced. Missing for 10: explicit docs on baseUrl/subpath configuration, explicit custom-domain setup guidance, and independent confirmation of successful custom-domain/subpath deployments.

   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   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 Docusaurus
   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

   Docusaurus✓fullclaimed9/10

   Docusaurus builds static HTML files via `npm run build` into a `build` directory, which can be hosted on any static host (Vercel, GitHub Pages, Netlify, Render, Surge) or served locally via `docusaurus serve`, confirming no vendor lock-in. Community comments corroborate real-world deployment and migration flexibility. Missing for 10: no independent hands-on verification of exporting/re-hosting a site across multiple providers beyond docs claims.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”

   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

   Docusaurus~partialclaimed5/10

   Docusaurus does not ship its own out-of-the-box search index; it relies on integrating third-party Algolia DocSearch, which requires a separate application/setup and free-tier approval, and there's a migration note suggesting the infra has changed over time. Typo-tolerant, relevance-ranked search is achieved via Algolia (once configured), not built-in by default. missing for 10: evidence of a zero-config/built-in local search out of the box, independent confirmation of Algolia's typo-tolerance/ranking quality in practice, and details on setup friction or fallback for sites not approved for free DocSearch.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “You can read more about migration from the legacy DocSearch infra in our blog post”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [claimed-docs] “The service is **free** for any developer documentation or technical blog: just make sure to read the [checklist]”
   • [claimed-docs] “We proudly support Algolia documentation search.”

   proof ↗⚑ flag

Localization

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

   weight 1 · round to Docusaurus
   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

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in i18n support explicitly designed for translating docs and navigation, with support for git/Crowdin translation workflows and RTL locales, plus versioning to keep translated docs in sync with releases. Missing for 10: independent hands-on verification of translated navigation specifically (community evidence focuses on other features, not i18n workflows).

   • [claimed-docs] “It is easy to translate a Docusaurus website with its internationalization (i18n) support.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “**RTL support**: locales reading right-to-left (Arabic, Hebrew, etc.) are supported and easy to implement”

   proof ↗⚑ flag

Versioning

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

   weight 3 · round to Docusaurus
   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

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in, well-documented versioning support (versioning CLI to snapshot docs directory into a version, version dropdown for readers to switch) and dedicated docs on this exact workflow, plus i18n for localization. No independent hands-on corroboration specifically for the versioning UX is present, and no evidence of a version-switcher dropdown being explicitly named, so missing for 10: independent/community confirmation of the version-switch UI in practice, edge-case coverage for large numbers of versions.

   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”

   proof ↗⚑ flag