Jamdesk Review - Documentation Your AI Agent Can Actually Read

Welcome to this Jamdesk (jamdesk.com) review ✨

Documentation has quietly changed audience. For years the job was to write for a developer with a browser tab open. Now a growing share of that traffic isn't a person at all: someone's Claude Code session trying to work out your auth flow, a Cursor window looking for the right endpoint, ChatGPT summarising your API for a user who will never visit your site. Most documentation software was built for the first audience and bolted on an llms.txt for the second.

Jamdesk is a documentation platform that takes the second audience seriously from the ground up. You write in Markdown and MDX, publish via a CLI or GitHub sync, and every site you ship comes with an MCP server, markdown endpoints on every page, a reader-facing AI chat, and a score that grades how legible your docs are to an agent. It also positions itself as a considerably cheaper Mintlify alternative, which is a claim worth testing rather than repeating.

Four axes, chosen with the founder, Geoff: the setup path, the AI-agent tooling, the built-in chat and AI Score, and the API documentation with its OpenAPI playground. So I created a real project, connected it to a real GitHub repo, edited and shipped a real page, and poked the MCP endpoint with curl. Here's what I found.

Getting started: from nothing to a live site in about two minutes

The onboarding is a five-step rail down the left edge (start free trial, create your project, set up your docs, install CLI, start editing) and it does not let you wander off it. I named the project, and the "set up your docs" step offered to create a starter repository on my GitHub account rather than asking me to bring one.

That's the right call. Jamdesk created a uneed-demo-docs repo, I installed the Jamdesk GitHub App scoped to that single repo, and the first build ran on its own. Total elapsed time from clicking "Create Project" to a live site at uneed-demo-docs.jamdesk.app: a shade over two minutes, and I never touched a config file.

Eleven pages ship with the starter repo: an introduction, a quickstart, three writing guides, two API reference pages generated from an OpenAPI spec, and a components tab with live examples. The whole site is three kinds of file: docs.json for config, .mdx for pages, and a spec file. The file path becomes the URL, and there is no build config to learn.

The CLI does far more than publish. npx jamdesk@latest --help (v1.1.181 at the time of writing) lists seventeen commands, and the interesting ones sit well away from deployment:

• validate checks docs.json, MDX syntax and OpenAPI specs in one pass.
• openapi-check validates a single spec.
• broken-links crawls internal links, and fix auto-repairs the broken ones by editing your local files.
• spellcheck runs a pass over your prose.
• rename moves a file and updates every reference to it.
• doctor diagnoses your environment, and jamdesk dev gives you hot reload on localhost:3000.

Those are the commands of a tool that expects docs to be maintained over years.

There's also a web editor in the dashboard, and it's better than I expected. A navigation tree of your pages on the far left with an "Add page" button and a filter box, raw MDX in the middle, live rendered preview on the right, a branch chip at the top, and Desktop/Mobile plus Light/Dark toggles for the preview.

I appended a sentence to the introduction page. The preview repainted as I typed, the edited block highlighted in the gutter, the word count ticked from 202 to 217, and a "1 change" pill appeared next to Commit. I reloaded the page mid-edit and the uncommitted change survived.

Committing is where it gets nice. The commit dialog has a Generate button that writes the message for you. Mine came back as "Add Uneed review live-test note to introduction welcome text", a more precise summary than I'd have bothered typing.

The build history then breaks the deploy into eight timed phases: authenticating with GitHub (0.42s), cloning (0.70s), validating configuration (1.44s), preparing content (1.12s), building documentation (1.79s), uploading to CDN (2.04s), indexing AI search and chat (0.52s), refreshing cache (0.58s). Total: 6.35 seconds from clicking Commit to "your changes are now live", and the commit landed on GitHub with the generated message intact. Custom domains and the three built-in themes (Jam, Nebula, Pulsar) are configured the same way: a field in docs.json, or a form in Settings.

Built for AI agents: the part that actually differentiates it

This is the section that earns its place. Plenty of documentation software now emits an llms.txt. Jamdesk goes several steps past that.

Every site gets an MCP server at /_mcp with zero configuration. I hadn't enabled anything, so I simply pointed curl at my two-minute-old demo site. The tools/list call returned two tools, searchDocs and getPage, with full JSON schemas. A searchDocs call for "callout" came back with three results, and not three pages but three sections: the Callouts page itself at a BM25 score of 1.4987, then its "With custom title" section at 1.1251, then its "Usage" section at 1.0172.

Section-level granularity with real relevance scores, on a site I'd built minutes earlier and never configured. Under the hood the index uses BM25 ranking with one-character fuzzy tolerance and field boosting on titles and headers, rebuilt on every deploy and rate-limited to 60 requests a minute per IP. Connecting it to Claude Code takes one line: claude mcp add --transport http my-docs https://your-domain/_mcp.

The llms.txt gets the same treatment: generated, then audited. Mine covered 100% of the eleven pages in the sitemap, each entry carrying a real description rather than just a title, and llms-full.txt came in at 23KB. Append .md to any page URL and you get the raw markdown back with content-type: text/markdown, frontmatter and components included.

What I didn't expect was the pointer inside the content itself. Every starter page opens with a line reading "For AI agents: the complete documentation index is at llms.txt. Append .md to any page URL for its markdown version." Small thing, but it means an agent that lands on one page discovers the rest.

Readers get their own version of this through the AI Actions menu. The chevron next to "Copy page" opens eight actions: copy the page as markdown for an LLM, view the raw markdown, open the page in ChatGPT, Claude or Perplexity, copy the MCP server config as JSON, or one-click install the MCP server into Cursor or VS Code. All of it works without you configuring a thing.

On the authoring side there's a Claude Code plugin, installed with /plugin marketplace add jamdesk/jamdesk-claude-plugin then /plugin install jamdesk@jamdesk-marketplace. It's a single skill (/jamdesk:jamdesk) with a quick-reference hub and three reference files that load on demand: every MDX component with its props, the full docs.json schema, and eight navigation patterns.

If your project has a docs.json, Claude may activate it automatically, so you stop re-explaining your docs stack to your agent at the start of every session. Cursor and OpenAI Codex paths are documented too, alongside an /update-jamdesk skill for keeping docs in sync when you ship a feature.

The AI chat, and where it's honest about its limits

Every Jamdesk site ships a reader-facing chat behind an "Ask AI" button (⌘I), grounded on that site's pages. No setup, no key, no toggle.

I asked it how to add a new page and get it into the sidebar. It came back with a two-step answer (create the .mdx file, then register it in docs.json) including the actual JSON snippet for a navigation group, a note that the file path becomes the URL automatically, and a "Related docs" chip linking to Quickstart. That's a genuinely useful answer, not a paraphrase of the nearest paragraph.

Then I asked it something the docs don't cover: the query parameters for listing tickets and the default page size. It replied, in full: "I don't have information about that in the documentation." No invention, no plausible-sounding guess. For a docs chatbot that's the single most important behaviour, and a lot of them fail it.

The chat feeds an analytics view that's arguably more valuable than the chat itself: total questions, unique questions, unanswered count, citation rate, average response time (3.8s in my case), and a Content Gaps tab that surfaces the questions your docs failed to answer. That's a content roadmap built from what readers actually wanted.

One wrinkle, though. My unanswerable question was logged under Top Questions, but the dashboard still showed zero unanswered and a 100% citation rate, so the gap detection missed the one gap I'd deliberately created. Worth knowing before you rely on that number.

AI Score: a build-time grade for agent readability

Every build produces an AI Score: a 0-100 grade for how easily agents can read your docs, measured against the open AFDocs standard. My starter site scored 100, A+, across seven categories: Content Discoverability, Markdown Availability, Page Size and Truncation Risk, Content Structure, URL Stability and Redirects, Observability and Content Health, and Authentication and Access.

The score itself is the least interesting part. What's useful is that each category expands into named, individually reported checks with the actual numbers. Content Discoverability alone ran seven: llms-txt-exists ("llms.txt found at 2 locations; using .../llms.txt as canonical"), llms-txt-valid, llms-txt-size ("2,521 characters, under 50,000 threshold"), llms-txt-links-resolve ("all 11 same-origin links resolve"), llms-txt-links-markdown ("11/11 point to markdown content"), and two directive checks confirming the llms.txt pointer appears near the top of both the HTML and the markdown of all eleven pages. Elsewhere, cache-header-hygiene confirmed all 13 endpoints had appropriate cache headers.

My one warning was markdown-content-parity: two of eleven pages had minor content differences between their markdown and their HTML. The explanation was specific and actionable. Content rendered by interactive components doesn't make it into plain markdown, so those pages show more to human readers than to agents, and the fix is to move the key information into regular paragraphs or headings.

There's also a Copy prompt to fix button that hands the whole thing to your agent as a prompt. That's the loop working properly: the platform finds the problem, explains it in plain language, and gives your AI the instructions to fix it.

An honest caveat: a pristine starter project scoring 100 tells you very little. The real test is what a five-year-old docs site with 400 pages scores, and I couldn't run that. The checks themselves are concrete enough that I'd trust the diagnosis, though.

API documentation: OpenAPI in, playground out

If you're comparing API documentation tools, this is where the comparison usually lands. Jamdesk reads an OpenAPI spec and generates endpoint pages: description, a parameter table with types and required flags and enum values spelled out ("low" | "normal" | "high" | "urgent"), request examples in nine languages (cURL, Python, JavaScript, Go, Ruby, C#, Java, Rust, PHP), and response examples tabbed by status code.

The playground is what I most wanted to put a real request through. Clicking "Try it" opens a full-width modal: request body fields on the left, generated code on the right, Send in the corner. I filled in a customer ID, subject, priority and message, hit Send, and got back 201 Created in 99ms with a fully-formed ticket object: id, status, timestamps.

A live request against a live endpoint, from inside the docs, with the cURL panel updating to match my inputs as I typed them. That's the behaviour that makes an API reference useful to someone evaluating your product at 11pm.

Validation runs at build time too. The CLI's openapi-check validates a spec standalone, and the build pipeline validates it non-blocking with alerts rather than silently skipping the operations it can't parse.

The rest of the product

A roundup of everything else worth knowing, most of which I confirmed in Settings or the docs:

• Twenty-six documented MDX components, including Mermaid diagrams built to SVG at build time, KaTeX math, an EmailSubscribe block with native capture for seven providers, a Prompt component for reusable AI instructions, and a Visibility component that shows different content to humans and agents on the same page.
• Custom React components in MDX with server-side rendering and Tailwind, plus custom CSS and JavaScript on every plan.
• Analytics built in: visitors, views, search queries and AI chat usage, with no third-party script required. Mine was already logging traffic within minutes of the site going live.
• Subpath hosting: serve docs at yoursite.com/docs behind your existing site with one proxy rule, with documented setups for Vercel, Cloudflare, and CloudFront. Or a subdomain with automatic SSL.
• Password protection for the whole site or individual pages, configured in docs.json.
• An automation-accounts allowlist: bots that push to your repo must be explicitly authorised before they can trigger a publishing build. A thoughtful detail in a product that expects agents to be writing your docs.
• A "What's New" changelog widget you embed on your own product with a script tag, plus Slack build notifications, email signup capture, PDF export, a Docs Search API, and a native iOS app for build status.
• Migration from Mintlify via npx jamdesk migrate, which imports pages, navigation and config, and supports Mintlify's component set.

One inconsistency I noticed: the starter site's own card advertises "50+ components" while the pricing page and docs both say 25+. The docs list 26 component pages, so the marketing on the starter template is the odd one out.

Pricing & plans

Pricing is refreshingly boring, which is a compliment.

There's a 14-day free trial with full access to every feature and no credit card, then a single Pro plan at $29/month, or roughly $24/month on annual billing (Jamdesk quotes a 17% annual saving). Pro covers unlimited pages, unlimited team members, one docs project, the web editor, custom domain with SSL, password protection, analytics, the API playground, branding removal, and every AI feature (Ask AI chat, Fix with AI, AI Score) with no credit meters and no overage billing. Extra docs projects are $15/month or $150/year each. Enterprise is custom and adds SSO/SAML, regional hosting, an SLA, volume discounts and a dedicated account manager.

Two things are notable. First, unlimited team members on every plan, including the trial, with no per-seat pricing at all. Second, no AI credits. Metered AI is now the norm in this category, and Jamdesk simply doesn't do it.

Which brings us to the Mintlify alternative angle, and it holds up better than most vendor comparisons. I checked Mintlify's own pricing page rather than taking Jamdesk's word for it: Mintlify's Starter is free, and Pro is $540/month billed monthly, $450/month on annual, with 10,000 AI credits a month and $0.01 per credit for overages. Jamdesk's comparison page is accurate on that. So for a team that needs analytics or the AI assistant, you're comparing $29/month against $540/month, and the free Mintlify plan caps you at five team members where Jamdesk doesn't cap at all.

That's a real gap, but be clear about what you're buying with it. Mintlify has the larger ecosystem: more public sites, more templates, more community answers, and a customer list that includes Anthropic and Perplexity. If your evaluation is about price and what's included, Jamdesk wins comfortably. If it's about ecosystem maturity, it doesn't yet.

Who should use Jamdesk?

It's a strong fit if you are:

• A startup or small team shipping developer or API docs, where $540/month for analytics and an assistant is simply not happening.
• A team that works Git-first and wants docs reviewed in pull requests like everything else, with a web editor for the non-technical people who need one.
• Anyone who cares that agents can read their docs, because the MCP server, the markdown endpoints and the AI Score are the most developed version of that I've seen shipped as defaults.
• Currently on Mintlify's free plan and about to hit the five-member cap.

It's less compelling if your docs are a handful of pages that would be happier as a README, or if you need a WYSIWYG editor for a large non-technical team (this is a Markdown product with a Markdown editor, and no amount of live preview changes that). Heavy visual customisation is out too: three built-in themes plus custom CSS is the whole story, and if none of the three suits your brand you'll be writing CSS.

Conclusion

That's the end of this Jamdesk review. What convinced me isn't any single feature; it's that the AI-agent story is wired through the entire product rather than sitting in a marketing section. The MCP server exists on a site you built two minutes ago and never configured. The markdown endpoints are announced to agents from inside the content. The AI Score hands your agent a prompt to fix what it found. Most documentation software in 2026 has an AI checkbox; this one has a coherent argument.

The setup cost is genuinely two minutes, and the trial gives you every feature for fourteen days, so the fastest way to judge it is to point npx jamdesk migrate at your existing docs and look at your own AI Score.

What I liked:

• Two minutes from signup to a live docs site, including the GitHub repo, with no config file touched.
• A built-in MCP server at /_mcp on every site with zero setup, returning section-level results with real BM25 scores.
• The AI chat refused to invent an answer it didn't have, the behaviour that matters most and the one most often missing.
• AI Score reports named, individually explained checks with real numbers, plus a "Copy prompt to fix" button that hands the work to your agent.
• The API playground fires real requests: 201 Created in 99ms, with code samples in nine languages.
• Commit-to-live in 6.35 seconds, broken out into eight timed build phases, with an AI-generated commit message that was actually accurate.
• $29/month flat, unlimited team members, no AI credit metering.

Things to keep in mind:

• A pristine starter project scoring 100 on AI Score tells you little; the real test is a large legacy docs site, which I couldn't run.
• The chat analytics logged my deliberately unanswerable question but still reported zero unanswered and 100% citation rate, so don't lean on that metric yet.
• Three built-in themes. Past that you're writing custom CSS.
• It's a Markdown-and-Git product. The web editor is good, but a non-technical team that expects Notion will feel the friction.
• Smaller ecosystem than Mintlify: fewer templates, fewer public examples, fewer community answers when you get stuck.
• The starter template claims "50+ components" where the docs list 26. Minor, but it's the kind of thing that erodes trust in the numbers around it.

If your docs need to be read by people and by the agents working on their behalf, Jamdesk is the most complete answer I've tested. And if you're weighing it against the incumbent, the Mintlify comparison is worth five minutes of your time.