Mintlify vs Fern

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

   Fern✓fullprobed9/10

   Fern documents and probes confirm automatic llms.txt generation, clean Markdown pages via .md suffix, agent directives, and this is independently verified by a live probe returning HTTP 200 with agent instructions at /llms.txt. Fern also hosts an MCP server and analytics for llms.txt usage. Missing for 10: independent third-party (non-Fern-docs) confirmation of agent consumption in the wild beyond the one probe.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “To override the default, set a custom directive using the `agents` key in `docs.yml`”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   proof ↗⚑ flag

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

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

   Fern✓fullprobed7/10

   Fern's CLI is explicitly designed for automation: every command outputs JSON for piping/scripting, and it's distributed via installers (Homebrew, npm, curl) enabling CI installation and headless use for validating, generating SDKs, and publishing docs. Fern Agent can also run on a schedule to open PRs automatically, further supporting headless/CI workflows. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions snippet), no independent/community confirmation of headless CI usage.

   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

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

   Fern✓fullprobed8/10

   Fern is a documentation/SDK platform, not an agent itself, so this axis clearly applies; Fern documents an official, automatically generated MCP server for every docs site (and a private org-wide MCP server) that coding agents like Claude Code, Cursor, and Windsurf can register with to query docs, CLI syntax, and site data. Missing for 10: independent/hands-on verification beyond first-party docs and probes confirming the MCP endpoint is live and functional.

   • [claimed-docs] “Fern automatically generates and hosts a production-ready Model Context Protocol (MCP) server for every documentation site with Ask Fern ena…”
   • [claimed-docs] “Register it with your coding agent to look up `docs.yml` syntax, components, and CLI commands while you build, and to read your sites, deplo…”
   • [claimed-docs] “The server connects AI clients like Claude Code, Cursor, and Windsurf to your documentation as an external data source, so your readers can …”
   • [claimed-docs] “Fern hosts a private Model Context Protocol (MCP) server for your organization, with full context on Fern’s documentation and configuration”
   • [probe] “official MCP server documented at https://buildwithfern.com/learn/docs/ai-features/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Fern✓fullprobed9/10

   Fern ships an official CLI (fern-docs-1) distributed via signed binaries on Homebrew, npm, pnpm, Scoop, and curl (fern-docs-35), with AI-native design explicitly called out: every command outputs JSON so coding agents can pipe calls (fern-docs-34), and probe confirms official CLI docs exist (fern-probe-5). Missing for 10: independent/hands-on community verification of CLI's agentic JSON behavior beyond vendor docs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

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

   Fern~partialprobed6/10

   A probe confirms Fern publishes a public OpenAPI spec at buildwithfern.com/openapi.json, and the CLI is documented to emit JSON so 'coding agents can pipe one call into the next,' giving AI-native users a programmatic path to drive the product. However, there's no explicit first-party 'API reference' page for Fern's own platform API (only the raw spec) and no independent confirmation of usage. Missing for 10: a dedicated documented API reference page, independent/community corroboration of driving Fern via its API, and clearer distinction between Fern's own platform API vs. customer-generated SDKs.

   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”

   proof ↗⚑ flag

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

   Fern—none0/10

   Fern is a docs/SDK generation platform; no evidence describes issuing scoped or least-privilege API credentials/keys for an agent — only visitor authentication (JWT/SSO) and password-protected docs are mentioned, which are for human readers, not agent credential scoping.

   ⚑ flag

7. ai-native userBuild against official SDKs

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

   Fern✓fullcommunity8/10

   Fern is explicitly a SDK generator platform producing type-safe, idiomatic client libraries in 9+ languages (TypeScript, Python, Java, Go, Ruby, PHP, C#) from a single API spec, with pagination helpers and other SDK-native features, positioning it squarely for AI-native developers to build against generated official SDKs; community corroboration (HN) confirms it delivers end-to-end SDK generation. missing for 10: independent hands-on verification of SDK quality/reliability across all languages, and clearer evidence of long-term maintenance/versioning guarantees for generated SDKs.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [claimed-docs] “Generate client libraries in multiple languages.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “Pagination helpers. Cursor-based and offset-based pagination are first-class.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Mintlify—none0/10

   No evidence of webhook subscription capability; Mintlify offers automations triggered by repo pushes/integration events and a REST API to trigger deployments, but nothing about outbound webhooks for subscribing to events.

   ⚑ flag

   Fern—none0/10

   No evidence in the pack shows Fern itself offers a webhook subscription mechanism for platform events (e.g., doc publish, build status, reader activity); the evidence only covers SDKs, CLI, docs, MCP servers, and Ask Fern.

   ⚑ 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

   Fern~partialclaimed6/10

   Fern Agent automations can review reader feedback, unanswered Ask Fern questions, search queries, and analytics, then report findings and open a PR with suggested doc changes — a form of AI-generated insight/suggestion from in-product usage data. However this is scoped narrowly to documentation analytics/feedback rather than general 'my data' insights, and there's no independent corroboration beyond first-party docs. Missing for 10: broader data-source insight generation beyond docs analytics, independent/hands-on verification of Fern Agent's insight quality, and evidence of proactive dashboards or analytics summarization beyond the changelog mention.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”

   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

   Fern~partialclaimed6/10

   Fern Agent can be scheduled to autonomously review reader feedback, unanswered questions, search queries, or analytics, report findings, and open a PR when appropriate — a genuine background automation. However, this is scoped narrowly to documentation-maintenance tasks rather than general-purpose autonomous automations, and detail on scheduling configuration, reliability, or failure handling is thin. Missing for 10: broader automation scope beyond docs upkeep, independent/hands-on verification of the scheduled agent working reliably, and more detail on configuring/monitoring these background runs.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”

   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

   Fern✓fullclaimed7/10

   Fern ships a built-in 'Fern Agent' that users can prompt or schedule to review reader feedback, unanswered questions, or analytics, then autonomously open a pull request with the requested changes — a genuine in-product AI assistant task-delegation feature (fern-docs-8, fern-docs-25, fern-docs-29, fern-docs-42, fern-docs-45). It can also be triggered via Slack for ad hoc tasks (fern-docs-45), going beyond simple Q&A like Ask Fern. Missing for 10: independent/hands-on verification of Fern Agent's reliability, and more detail on the scope of tasks it can safely handle beyond docs edits.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”

   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

   Fern~partialclaimed6/10

   Fern Agent lets users describe desired documentation changes in natural language (e.g., via Slack or scheduled prompts) and it reads the repo, makes edits, and opens a PR, and Ask Fern answers NL questions over docs; the CLI also emits JSON for agent piping. However, this NL-command capability is scoped mainly to docs content/maintenance, not core product operations like SDK/OpenAPI generation or CLI config, and there is no independent/hands-on evidence confirming reliability. Missing for 10: broader NL control over SDK generation and CLI workflows, independent/hands-on verification of Fern Agent's accuracy, and evidence of NL commands driving core product configuration rather than just docs edits.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”

   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

   Fern~partialclaimed5/10

   Fern generates full API reference documentation from OpenAPI specs (including GraphQL type pages) and produces SDKs in multiple languages with code snippets, which is the foundation for an interactive reference. However, the evidence never explicitly documents a 'try it now' / runnable request console or live execution feature within the API reference itself. missing for 10: explicit documentation of an interactive 'try it' console or live request execution, hands-on/independent confirmation of runnable examples.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   proof ↗⚑ flag

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

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

   Fern✓fullprobed8/10

   Fern generates API references from OpenAPI specs (fern-docs-22) and the product's own site exposes a live, machine-readable openapi.json confirmed via probe (fern-probe-3), demonstrating the platform both consumes and can serve OpenAPI specs. Missing for 10: no explicit first-party doc describing a built-in 'download/export spec' button for end-customers' generated docs sites, and no independent third-party confirmation of that export UX beyond the self-probe.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”

   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

   Fern—none0/10

   Fern documents a 'Versions' feature that lets customers add version dropdowns to their own docs/API references, but there is no evidence of Fern's own APIs, CLI, or SDK generator having a documented deprecation policy or semantic versioning guarantees that an AI-native user could rely on. missing for 10: evidence of Fern's own API/CLI versioning scheme, changelog of breaking-change policy, explicit deprecation timeline documentation.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

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

   Fern✓fullprobed9/10

   Fern documents that every documentation site with Ask Fern enabled gets an automatically generated, production-ready MCP server that connects AI clients (Claude Code, Cursor, Windsurf) to the docs as an external data source for search and page content, letting readers' agents get instant answers within their dev environment. This is corroborated by a dedicated docs page and probe confirming the feature is documented. Missing for 10: independent (non-vendor) hands-on verification that the MCP server works end-to-end in practice.

   • [claimed-docs] “Fern automatically generates and hosts a production-ready Model Context Protocol (MCP) server for every documentation site with Ask Fern ena…”
   • [claimed-docs] “The server connects AI clients like Claude Code, Cursor, and Windsurf to your documentation as an external data source, so your readers can …”
   • [probe] “official MCP server documented at https://buildwithfern.com/learn/docs/ai-features/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 drawn
   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

   Fern✓fullprobed9/10

   Fern documents automatic generation and maintenance of llms.txt (fern-docs-7/37), plus serving clean Markdown variants of pages via .md/.mdx suffix (fern-docs-6), and this is independently confirmed by a live probe returning HTTP 200 with correct llms.txt content and agent instructions (fern-probe-1). Analytics even track llms.txt usage by LLM provider (fern-docs-18). Missing for 10: independent third-party corroboration beyond the single probe, and the docs-md probe for a specific page returned 404 (fern-probe-2), suggesting some inconsistency in full-content variant availability across all pages.

   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.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

   Fern!disputedcontradicted5/10

   Fern's docs explicitly claim every documentation page serves clean Markdown by appending `.md` to the URL (fern-docs-6) and the llms.txt probe confirms this pattern is advertised (fern-probe-1), but a hands-on probe against an actual Fern-hosted page (buildwithfern.com/learn.md) returned HTTP 404 instead of Markdown (fern-probe-2), directly contradicting the universal claim. missing for 10: a successful probe on an actual content page returning clean Markdown, and clarification on which paths the `.md` suffix reliably works for.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   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

   Fern✓fullclaimed8/10

   Ask Fern is a first-party embedded AI assistant that indexes documentation and answers reader questions with citations linking to source pages, directly matching the story. Missing for 10: independent/hands-on third-party corroboration of citation accuracy and no community validation of the feature's real-world quality.

   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “You can now replace the default Ask Fern disclaimer (“Responses are generated using AI and may contain mistakes.”) with your own wording.”

   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

   Fern✓fullclaimed8/10

   Fern Agent explicitly reads the docs repo, makes described changes, can be triggered from a prompt, Slack, reader feedback/analytics review, or a schedule, and opens pull requests as its output — directly matching the story's prompt/PR/schedule → change-request workflow. missing for 10: independent/hands-on verification of Fern Agent's PR quality and no evidence of it reviewing/updating docs triggered directly from an incoming PR (only prompt, feedback, and schedule triggers are documented).

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Move the SDK guides under Reference and fix the links.”

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

   Fern~partialclaimed6/10

   Fern's llms.txt analytics tab explicitly reports 'Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)' distinguishing AI-agent consumption from generic web traffic, and this is tracked separately in the Web Analytics tab. However, this only covers llms.txt-based AI fetches, not a full breakdown distinguishing AI-agent vs human traffic across all documentation pages/formats (e.g., .md fetches, MCP server queries). Missing for 10: unified analytics dashboard showing AI-agent vs human split across all traffic sources (not just llms.txt), independent/hands-on verification of the analytics accuracy, and any breakdown of MCP-server query traffic as distinct from human pageviews.

   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   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

   Fern~partialclaimed5/10

   Fern's docs mention automations that can 'review your reader feedback, unanswered Ask Fern questions, search queries, or analytics' (fern-docs-8/25) and a Web Analytics/llms.txt usage tab tracking traffic by LLM provider (fern-docs-18/44), implying some page-view, search, and feedback signals exist. However there's no dedicated analytics dashboard walkthrough showing page views, search-term breakdowns, or reader feedback UI in one coherent place — missing for 10: a first-party analytics dashboard doc/screenshot showing page views, search term reports, and reader feedback aggregation, and independent/hands-on confirmation that these metrics are usable by a DevRel lead.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

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

   Fern—none0/10

   The evidence pack covers Fern's SDK generation, docs platform, AI/MCP features, CLI, and preview/versioning tools, but contains no mention of an interactive 'try it' playground for executing real API calls within the reference docs. Although this is a plausible feature for an API documentation platform, none of the docs, changelog entries, or community posts describe it.

   ⚑ 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

   Fern✓fullclaimed7/10

   Fern's docs explicitly state it generates API Reference documentation from an OpenAPI specification (fern-docs-22, fern-docs-46), and the CLI supports validating and republishing docs from the spec (fern-docs-1, fern-docs-33), with generated GraphQL type pages reflecting schema changes (fern-docs-9), confirming spec-driven generation. missing for 10: explicit description of automatic re-sync/CI pipeline when the OpenAPI spec changes, and independent/hands-on confirmation that reference pages update without manual regeneration steps.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

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

   Fern~partialclaimed6/10

   Fern explicitly supports authoring pages in Markdown and generating API references from OpenAPI, which covers the base authoring workflow, but the evidence pack lacks direct documentation of specific rich components like tabs, callouts, code groups, and steps that a technical writer would use without custom HTML. missing for 10: explicit docs/examples of tabs, callouts, code-group, and step components in MDX, and independent/hands-on confirmation that these render without custom HTML.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload. Offline access is available after the first online run.”

   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

   Fern✓fullclaimed8/10

   Fern Editor is explicitly documented as a visual, no-code, no-Git editing interface for non-technical roles (content writers, PMs, marketers), and edits presumably sync back into the same docs source (git) that developers use. missing for 10: independent/hands-on confirmation that Editor changes actually commit into the same git source of truth without conflicts, and more detail on the sync/versioning workflow.

   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   proof ↗⚑ flag

Content reuse

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

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

   Fern—none0/10

   No evidence in the pack mentions reusable content snippets, includes, or variable substitution for keeping repeated content in sync across pages; Fern's documented features cover Markdown authoring, versions, OpenAPI-based reference generation, and AI features but nothing about reusable snippets/variables.

   ⚑ 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

   Fern—none0/10

   No evidence of any style-guide linting, vale/textlint-style content checks, or pre-publish content quality gates in Fern's docs or CLI; validation features mentioned (fern-docs-1) refer to API definition validation, not prose/style linting. Missing for 10: any mention of prose style-guide rules, linting integration, or automated content-quality checks before publish.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   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

   Fern~partialclaimed4/10

   Fern's CLI is scriptable and machine-readable (every command outputs JSON so it can be piped/chained, fern-docs-34) and generates SDKs in 9 languages from a single spec in one operation (fern-docs-32), and the scheduled Fern Agent can review large sets of reader feedback, unanswered questions, and search queries in a single automated pass (fern-docs-8/25). However, there is no explicit documentation of a bulk/batch API or CLI mode for operating across many discrete items (e.g., mass-editing pages, bulk API endpoint updates) — missing for 10: explicit bulk-edit/batch API commands, evidence of scale limits, and independent confirmation that agents can reliably chain many operations at once.

   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”

   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

   Fern~partialclaimed5/10

   Fern documents 'Fern Agent' automations that can run on a schedule or be triggered by Slack discussions to review reader feedback/questions and open PRs when a described change is needed, which is a form of event-triggered automation (fern-docs-8, fern-docs-25, fern-docs-45). However, this is limited to Fern's own docs-maintenance domain (feedback, search queries, Slack) rather than a general rule engine for arbitrary events/actions. Missing for 10: a configurable rules/trigger system spanning arbitrary event sources (webhooks, API calls, custom conditions) and arbitrary actions beyond PR creation, plus independent confirmation of reliability.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Slack to kick off PRs based on internal team discussions or customer troubleshooting”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Mintlify~partialclaimed5/10

   Mintlify automations let the agent run 'on a schedule, on repository pushes, or on connected integration events' to maintain content, which is a form of recurring scheduled job — but this is limited to documentation-maintenance workflows, not a general-purpose scheduling/workflow engine for arbitrary AI-native tasks. missing for 10: evidence of configurable cron-like scheduling UI/API, arbitrary custom workflow definitions beyond doc maintenance, and independent/hands-on confirmation that scheduled automations work reliably.

   • [claimed-docs] “Automate content maintenance with Mintlify automations by running the agent on a schedule, on repository pushes, or on connected integration…”
   • [claimed-docs] “Automate conte”
   • [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

   Fern~partialclaimed5/10

   Fern Agent can reportedly be put 'on a schedule' to automatically review reader feedback, unanswered Ask Fern questions, or analytics and open pull requests when warranted — a genuine recurring-workflow automation. However, this is described only in brief changelog entries with no detail on scheduling granularity, cron-like configuration, or reliability, and no independent/hands-on confirmation exists. Missing for 10: documented scheduling configuration options, broader recurring-job use cases beyond docs-review automation, and third-party corroboration.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   proof ↗⚑ flag

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

   Fern~partialclaimed5/10

   Fern Agent automations operate by reading the docs site's source repo and opening a pull request when changes are needed, which inherently gives git-based versioning and human review before merge (fern-docs-8/25/29). However, there's no dedicated automation-specific version history, audit log, or explicit one-click rollback/undo feature documented beyond relying on standard git revert via PRs. Missing for 10: explicit rollback/undo UI for automations, automation run history/audit trail, and any review workflow beyond generic PR review.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

   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

   Fern~partialclaimed4/10

   Fern's docs are stored as code, and the Fern Agent automation explicitly 'opens a pull request when the prompt asks for a change,' implying a git-based review/merge gate before publishing (fern-docs-8/25). However, there's no direct documentation of an in-product commenting or approval workflow, and Fern Editor is described as letting non-technical writers publish updates 'without code, markdown, or Git' (fern-docs-2), which bypasses any PR-based review step. Missing for 10: explicit description of inline comments/approvals, confirmation that Editor changes also go through a review/merge gate, and independent evidence of a working review pipeline.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”

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

   Fern—none0/10

   The evidence pack contains no mention of theme, font, layout, custom CSS/JS, or custom component capabilities for Fern docs — only custom domains, versions, preview, and AI features are documented. As a documentation platform, this axis clearly applies, but there is no evidence Fern supports deep visual/brand customization beyond domain routing.

   ⚑ flag

Git workflow

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

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

   Fern~partialclaimed6/10

   Fern's CLI-driven workflow (init, validate, preview, publish) and Fern Agent explicitly 'reads your docs site's source repository and makes the changes you describe,' plus automations that 'open a pull request when the prompt asks for a change,' point to a git-backed, PR-driven docs pipeline. However, the evidence never explicitly documents a CI/CD-style trigger where merging a branch/PR automatically republishes docs, and Fern Editor is marketed as a non-git alternative for content editors, which cuts against a pure docs-as-code narrative. Missing for 10: explicit documentation of branch-based preview/staging tied to PRs, and a described merge-to-publish pipeline (e.g., GitHub Action or webhook) rather than manual CLI publish or Agent-initiated PRs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   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

   Fern~partialclaimed4/10

   Fern documents a local preview server with hot reload (fern-docs-14/26/39) but there is no evidence of automatic, shareable preview deployment URLs generated per pull request (e.g., a bot comment with a live link tied to CI/CD on PR open). This is a local-only workflow rather than a hosted PR-preview link. missing for 10: PR-triggered hosted preview deployment, shareable preview URL per PR, CI/CD integration or bot comment posting preview links, independent confirmation of PR-preview behavior.

   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload. Offline access is available after the first online run.”
   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload.”
   • [claimed-docs] “Fern offers two ways to preview documentation changes”

   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

   Fern—none0/10

   The CLI reference mentions validating API definitions, but there is no evidence of a CI/CD integration that catches broken links or invalid configuration before publishing (e.g., no GitHub Action, pre-publish link checker, or CI validation step documented).

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

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

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

   Fern~partialprobed5/10

   Fern's CLI covers core workflows also available in the UI — initializing, validating, previewing, and publishing docs/SDKs (fern-docs-1) — and every CLI command outputs JSON for agent piping (fern-docs-34), suggesting good API/CLI parity for build workflows. However, several UI-only capabilities (Fern Editor's no-code content editing for non-technical writers, Ask Fern configuration, analytics dashboards, version/domain management) have no documented API/CLI equivalent in the evidence. Missing for 10: documented API/CLI parity for Fern Editor no-code edits, analytics access, and admin/config actions performed via the web UI.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   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

   Fern~partialcommunity5/10

   Fern's content model is built on open formats (Markdown pages, OpenAPI specs for API references, YAML docs.yml config) and the CLI validates/previews/publishes from your own source repo, implying content isn't locked in a proprietary format (fern-docs-22, fern-docs-33, fern-docs-46). However, there is no explicit 'export all your data' feature, no documented bulk-export/backup tool, and the optional 'Fern Definition' language is noted by a community reviewer as an added proprietary layer that doesn't map 1:1 to OpenAPI (fern-comm-2). Missing for 10: an explicit data-export/backup capability, confirmation that Fern Definition and Ask Fern indices/analytics can be exported, and independent evidence of migrating off Fern without friction.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

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

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

   Fern✓fullcommunity7/10

   Fern's source is publicly hosted on GitHub (fern-api/fern), and independent community commentary explicitly confirms it is open-source (though commercially licensed/not free), satisfying the ability to read the source. Missing for 10: explicit license file/name (e.g., MIT/Apache) confirmation and first-party docs stating the license terms.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   Fern~partialcommunity5/10

   Fern's docs confirm a self-hosted container option for serving documentation (env var resolution 'on each request' in self-hosted deployments) and community commentary notes Fern is open-source, supporting self-hosting of the core product. However, there is no first-party deployment guide, infrastructure requirements, licensing terms, or independent hands-on confirmation of running the full SDK-generation/docs platform outside Fern's hosted service. Missing for 10: explicit self-hosting setup documentation, infra/licensing details, and independent verification of a full self-hosted deployment.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   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

   Fern—none0/10

   Fern is a docs/SDK platform for API providers; data residency/region choice is a plausible axis for a hosted SaaS documentation platform, but no evidence pack item mentions region selection, data residency, or storage location options. Self-hosting is mentioned but not framed as a residency control.

   ⚑ flag

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

   Fern—none0/10

   Fern is a docs/SDK generation platform; no evidence pack item discusses data retention policies, deletion controls, or user data lifecycle management for content, analytics, or Ask Fern query logs. This axis plausibly applies (any SaaS handling user/reader data could document retention/deletion controls) but no such documentation is present.

   ⚑ flag

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

   Fern—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Fern's CLI, docs platform, or SDKs; this is a fair privacy-posture question for a dev-tool/platform but no documentation or community source confirms or denies telemetry opt-out.

   ⚑ 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 Fern
   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

   Fern✓fullclaimed8/10

   Fern's pricing page explicitly lists password-protected docs and visitor authentication with JWT/SSO as features, directly matching the story's requirement for gating docs behind authentication for customers-only content. Missing for 10: no independent/hands-on corroboration or detailed docs page describing configuration steps for these auth methods beyond the pricing page mention.

   • [claimed-docs] “Password-protected docs”
   • [claimed-docs] “Visitor authentication (JWT, SSO)”

   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

   Fern✓fullclaimed8/10

   Fern's docs explicitly document configuring custom domains as a subdomain (docs.mydomain.com), subpath (mydomain.com/docs), or root domain (mydomain.com), directly matching the story's requirements. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on DNS/setup complexity or edge cases.

   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain: `docs.mydomain.com`, Subpath: `mydomain.com/docs`, Root domain: `mydo…”
   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain... Subpath... Root domain”
   • [claimed-docs] “You can configure any of the following custom domain types”

   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

   Fern~partialclaimed3/10

   Evidence only mentions a 'self-hosted container' that can serve pages with per-request environment variable resolution, implying some self-hosting flexibility, but there is no documentation of exporting the docs site as a plain static HTML/asset bundle deployable to arbitrary static hosts (e.g., S3, Netlify) without Fern's runtime. Missing for 10: an explicit static-export/build-to-static-files feature, confirmation that the exported bundle has no dependency on Fern's hosted infrastructure or container, and independent verification of successful self-hosting outside Fern's ecosystem.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”

   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

   Fern~partialclaimed4/10

   Fern's docs mention a 'search queries' analytics feature and a `search-metadata` frontmatter for customizing search grouping/filtering, implying a built-in site search exists, and Ask Fern provides an AI Q&A alternative with citations. However, there is no explicit claim about typo-tolerance, relevance ranking, or full-site coverage of the search feature itself. Missing for 10: explicit documentation of the underlying search engine's typo-tolerance, ranking algorithm, and independent/hands-on verification of search quality.

   • [claimed-docs] “You can now attach your own key-value metadata to a page with the `search-metadata` frontmatter object... so a custom search integration can…”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   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

   Fern—none0/10

   The evidence covers versioning (dropdown for multiple releases), custom domains, previews, and SDK/CLI generation, but there is no mention anywhere of localization, translated navigation, multi-language content, or i18n support for docs sites. missing for 10: any mention of localization/i18n, translated navigation menus, language switcher, or multi-locale content management.

   ⚑ flag

Versioning

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

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

   Fern✓fullclaimed8/10

   Fern explicitly documents a Versions feature that adds a dropdown selector letting readers switch between multiple releases of the same docs/API content, with each version able to have its own pages, tabs, and API references. This directly matches the story's core need for per-product/version documentation with reader-facing version switching. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on version-specific URL structure or SEO handling.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

   proof ↗⚑ flag