Jason Lee

Posted on Aug 17

Every Docs Tool Ships llms.txt Now. Blume Hands Coding Agents Write Access to Your Docs Instead.

#opensource #documentation #ai #astro

Every documentation tool launched in the last twelve months claims to be "AI-ready." In practice that has come to mean one thing: it ships an llms.txt file so a language model can slurp your docs into its context window a little more cleanly. That's a reasonable bar, and it's already table stakes — Mintlify, Docusaurus plugins, and half a dozen static-site generators all do it now.

Blume, an open-source documentation framework that launched on Product Hunt in July 2026, does the llms.txt thing too. But that's not the interesting part of what it shipped. Blume also ships a hosted Model Context Protocol server, a set of "agent skills" that teach a coding agent to write and maintain your docs, and a CLI command (blume eval) that scores whether the resulting docs actually answer real questions. Put together, that's a different bet than "make docs legible to AI." It's "assume an AI agent is going to be one of your doc maintainers, and build the guardrails for that from day one."

That's the angle worth digging into, because it's a preview of where a lot of internal tooling is heading, and because the claim is specific enough to check against the actual code rather than the launch copy.

Zoom out for a second on why "AI-ready docs" became a category at all. The llms.txt convention — a plain-text index of a site's most important pages, meant to be dropped straight into a model's context — spread fast in 2025 and 2026 because retrieval-augmented answers and coding-agent workflows kept choking on the same problem: HTML docs pages are full of navigation chrome, ads, and JavaScript that a model has to wade through to get to the actual sentence it needs. Serving raw Markdown solves that. It's a genuinely useful, genuinely cheap feature to add, which is exactly why every framework added it within a few months of each other and why it stopped being a differentiator almost as fast as it became one. Blume shipping it is expected. What's worth stopping on is everything the framework built on top of that baseline.

What happened

Blume is the work of Hayden Bleasel, a San Francisco-based developer whose GitHub profile lists OpenAI as his employer and whose other pinned project, Ultracite (a zero-config linter/formatter wrapper around Biome), has 3.1k GitHub stars. Blume itself sits at roughly 1.2k stars at the time of writing. It's MIT-licensed, free, and — per the repository's own commit and release history — being iterated on aggressively: the first real 0.1.0 release on npm shipped June 30, 2026, and the package had reached version 1.5.1 across 45 published releases by August 16, 2026, one day before this article. That's a new-ish project moving fast, not an established tool with years of production mileage.

The pitch, in the README's own words: "Documentation for everything you build. Fast, AI-ready, and zero-config. Free and open source, forever." You point Blume at a folder of Markdown or MDX files, run blume dev, and get a production-grade docs site — navigation, search, theming, Open Graph images, a component library — without writing or maintaining any app boilerplate.

What it actually does

Strip away the AI framing for a second, because the base product is a solid, if crowded, entry in the "markdown folder to docs site" category that Docusaurus, Nextra, Fumadocs, and Mintlify already occupy. Blume's version of that story:

Zero-config, including the template. There's no starter repo to clone. A folder of .md/.mdx files is a complete project. Configuration (blume.config.ts, per-section meta.ts) is opt-in and fully typed, validated against a schema via defineConfig/defineMeta helpers, so mistakes surface in your editor instead of at build time.
Static by default. Output is plain HTML built on Astro and Vite. The core theme ships no client-framework JavaScript, so Core Web Vitals scores are good out of the box without any tuning.
A real component library, no imports. Cards, tabs, accordions, steps, code groups, file trees, type tables, live component previews, and diffs are all usable directly in MDX.
Local search with escape hatches. Orama runs the default search index in dev and production with no hosted service required. If you outgrow it, Algolia, Typesense, Pagefind, FlexSearch, Orama Cloud, and Mixedbread are each one config setting away.
API references from a spec. Drop in an OpenAPI or AsyncAPI file and Blume renders an interactive reference — schemas, auth flows, a live request playground — using Scalar under the hood.
Content sources beyond the local filesystem. You can mix local Markdown with remote MDX, GitHub Releases, Notion, Sanity, or a custom backend in a single site.
i18n for 36 locales, SEO metadata, sitemap and robots.txt generation, RSS feeds, JSON-LD, and build-time Open Graph image rendering via Takumi, a Rust renderer that skips the headless-browser step most OG-image pipelines still pay for.
Export to PDF and EPUB, done entirely client-side so static builds stay static.
An eject hatch. blume eject produces a standalone Astro project that still depends on the blume package, for teams that hit the ceiling of the abstraction and want direct control.

None of that is revolutionary on its own — most of it exists somewhere in the competitive set. What makes it worth a full write-up is how the framework treats the "AI" half of "AI-ready."

How it works: the architecture, and the part that's actually new

Under the hood, the Blume CLI loads blume.config.ts, scans your content folder into an internal graph, and generates a hidden Astro project in a .blume/ directory that it drives for you. Astro renders everything through a catch-all route that pulls in Blume's shipped components, the generated content graph, and any overrides you've defined. .blume/ regenerates on every run — only changed files get rewritten, which is why hot reload stays fast — right up until you run blume eject and take ownership of the generated project yourself. It's the same "magic folder that becomes a real framework" trick Next.js popularized for pages, applied to a docs tool.

For deployment, blume build emits static HTML you can push to Vercel, Netlify, Cloudflare Pages, GitHub Pages, or any CDN. If you want request-time features — the Ask AI assistant, the MCP server — you switch to server output and pick an adapter (Vercel, Netlify Functions, Node, or Cloudflare Workers/Pages), and Blume auto-detects the right one on the big three hosts.

Now the part that's the actual subject of this review. Blume's AI-readiness feature set breaks into two tiers, and the distinction matters:

Tier one is read access, which is what "AI-ready" has come to mean industry-wide: llms.txt and llms-full.txt generation, raw Markdown served at any page's URL by appending .md, "Copy as Markdown" and "Open in chat" buttons in the UI, and an optional hosted Ask AI assistant. This is the part every competitor is racing to ship too, and Blume doesn't do anything here that a well-configured Docusaurus or Mintlify site can't also do.

Tier two is write access, and this is where Blume diverges. The framework ships a hosted MCP server so that Claude Code, Cursor, and VS Code can search and read your docs directly from inside an agent session — again, still reading. But it also ships "agent skills": packaged instructions that teach a coding agent how to scaffold, write, and maintain a Blume docs site using the framework's own conventions, so an agent asked to "document this new API route" produces MDX that matches your existing structure instead of freelancing a new one. And critically, it ships tooling to check the agent's homework: blume eval spins up an agent that answers real questions using only the built documentation, so you can tell whether a page actually explains the thing it claims to explain, versus reading fluently while omitting the one detail a user needed. blume audit checks SEO and general site health, blume validate checks internal links, anchors, and assets, and blume doctor diagnoses config and content problems — all scriptable in CI.

Line them up and the shape becomes clear: read tooling gets an agent into your docs, agent skills let it produce changes in your project's own house style, and blume eval/audit/validate/doctor are the checks that catch it when the output is wrong. That's a maintenance loop, not a search index. It's the same shift you're seeing in other corners of the ecosystem right now — coding agents being treated as an operator of a system rather than a one-off text generator — just applied to the docs folder instead of the database or the CI pipeline.

There's also a blume translate command that hands a configured locale list to "a local agent CLI" to produce translated content for the 36 supported locales. It's the same pattern again — an agent does the work, the framework provides the scaffolding and the place to plug in verification — though unlike eval, there's no described automated check on translation quality beyond whatever the agent CLI itself does.

Worth naming plainly: none of this makes an agent's docs edit trustworthy by default. blume eval tells you whether the current built site answers a set of questions correctly — it's a regression check you have to run and read, not a gate that blocks a bad edit automatically unless you wire it into CI yourself. Agent skills constrain the shape of what an agent produces (right MDX conventions, right file location, right frontmatter) without constraining whether the content of what it writes is accurate. That's still a meaningful improvement over "an agent edited a markdown file and nobody checked," but it's closer to giving a junior contributor a style guide and a smoke test than it is to a fully automated safety net. Teams adopting this for the agent-maintenance workflow should plan to actually wire blume eval and blume validate into a required CI check, not just have them available as commands someone might remember to run.

What changed versus the incumbents

The closest comparisons are Mintlify, Docusaurus, and Fumadocs, and each occupies a genuinely different niche:

Mintlify is a managed, hosted platform — you get a polished editor experience, built-in analytics, and a "ship it this week" workflow aimed partly at non-engineers, but you're paying a subscription and your docs live inside Mintlify's infrastructure.
Docusaurus, maintained under the Meta Open Source umbrella, is the mature, battle-tested option: a huge plugin ecosystem, React-based theming, and years of production use, at the cost of more config surface and a heavier client bundle by default.
Fumadocs targets engineer-led, fully customized docs sites built on Next.js. Its own creator has publicly said it isn't trying to be as fully-featured as Mintlify, and that it doesn't compete for the founder-led, non-technical "ship it fast" use case — it's explicitly for teams that want to own their stack.

Blume's positioning cuts across that map. It's free and self-hosted like Fumadocs and Docusaurus, zero-config like Mintlify claims to be, framework-agnostic-feeling despite being an Astro project underneath (you never touch Astro unless you eject), and — the actual differentiator — the only one of the four that ships purpose-built tooling for agents to both consume and produce content, with a scoring mechanism attached. Docusaurus and Mintlify have both added llms.txt support this cycle; neither has published an equivalent to blume eval or agent skills as of this writing.

Roughly, the trade-offs shake out like this:

	Hosting	Config	Framework lock-in	Agent write tooling
Mintlify	Managed SaaS	Minimal, hosted editor	High — proprietary platform	Read-focused (`llms.txt`)
Docusaurus	Self-hosted	Moderate–heavy	Low, but React-specific	None built-in
Fumadocs	Self-hosted	Moderate	Medium — tied to Next.js	None built-in
Blume	Self-hosted (static or server)	Minimal, typed	Low — eject to plain Astro	MCP server + agent skills + `blume eval`

The honest caveat on that table: Mintlify's managed hosting and non-technical editor are a real product advantage for teams without engineers wanting to touch the docs pipeline, and nothing in Blume's feature list replaces that. This is a trade-off, not a strict win for either side.

Why developers should care

Cost and lock-in. Free and MIT-licensed beats a subscription, and the eject hatch means you're never more locked in than "this is an Astro project now," which is a much softer landing than migrating off a proprietary hosted rendering pipeline.

DX. A typed config file that a language server can catch mistakes in before you build is a small thing that compounds over a docs site's lifetime, especially once a team — human or agent — is making changes to it weekly.

Security posture, visibly. The repository's README badges include a Socket.dev supply-chain score and a CodeRabbit pull request review badge — the project dogfoods automated PR review and dependency scanning on itself, which is a reasonable signal for a tool you're about to add to your build pipeline, though it's not a substitute for reading the dependency tree yourself.

Maintainability, specifically for the agent-assisted era. If your team already lets Claude Code or Cursor open PRs, "does this framework have a machine-checkable way to verify an agent's docs edit didn't quietly break something" is a real question, and right now Blume is one of the only entrants with a concrete answer (blume eval, audit, validate, doctor) rather than a hope that the agent got it right.

Practical use cases

Open-source project docs where you want fast static hosting, no vendor bill, and a component library good enough that you're not hand-rolling callouts and tabbed code blocks.
API documentation for a product with an existing OpenAPI or AsyncAPI spec — point Blume at it and get an interactive reference via Scalar without standing up a separate tool.
Docs meant to be operated on by coding agents inside a monorepo — the MCP server plus agent skills are specifically for teams where "ask the agent to update the docs after this PR" is already a workflow, and you want that workflow to produce consistent output and a way to catch regressions.
Multi-region products that need genuine i18n routing and translated navigation rather than a single English tree with a machine-translate widget bolted on.
Compliance or offline-distribution scenarios where a client-side PDF/EPUB export saves you from maintaining a separate export pipeline.
Docs-as-tests for onboarding. Because blume eval runs an agent against your built site and checks whether it answers real questions correctly, you can repurpose it as a rough proxy for "would a new engineer actually find the answer here" — run it against your own onboarding FAQ before asking a human to validate the same thing.
Content sourced from multiple systems. A team whose product docs live partly in Notion (marketing-facing pages) and partly in the engineering repo (API reference, changelogs) can pull both into one site instead of running two separate docs deployments that inevitably drift out of sync.

None of these are exotic — they're the same use cases every docs framework targets. The difference is that in a Blume site, "have an agent update this page after the API changed" is a designed-for workflow with scaffolding around it, rather than something you'd bolt on yourself with a custom script against a Docusaurus repo.

Limitations the launch page doesn't dwell on

A few things worth knowing before you adopt this for anything load-bearing:

Node 22.12+ is a hard requirement. That's a recent runtime. Plenty of CI images and production containers are still pinned to Node 20 LTS, and that's friction the "zero-config" pitch doesn't mention.
"Zero-config" has an asterisk on the AI features. Ask AI and the MCP server both require switching from static output to a server adapter — which is itself only a config-file change, but it's a real architectural decision (and a hosting-cost decision) that the marketing copy folds into the same "zero-config" umbrella as the parts that are genuinely zero-config.
This is a young, fast-moving project. 45 releases in about seven weeks is a good sign for active maintenance and a fair warning sign for API stability — if you adopt now, budget time for churn, and read changelogs before bumping the version in CI.
No described automated quality gate on blume translate output, unlike blume eval for the English source. Translation quality will depend entirely on which "local agent CLI" you have configured and how well you prompt it.
Single maintainer, for now. MIT licensing and open-source visibility mitigate bus-factor risk, but there's a real difference between a project with one prolific maintainer and one with a funded team behind it, which matters if you need guaranteed support SLAs — something Mintlify explicitly sells and Blume does not.
Traction signals are thin outside GitHub. Star counts and npm version cadence tell you the maintainer is active; they don't tell you how many teams are running this in production yet, and Product Hunt's own vote/comment counts for the launch weren't independently verifiable at the time of this review.

An independent read

The core static-site path here is legitimately zero-config and genuinely fast — that part of the pitch holds up against the code, not just the landing page. The AI angle is the more interesting bet, and it's a better bet than most "AI-ready docs" launches this year, because it's not just a read-only convenience feature bolted onto an existing product. Building agent skills, an MCP server, and a verification loop (blume eval) into a docs framework from the start is a genuine step ahead of where most tooling in this category is — most competitors are still solving "let the AI read this," and Blume is already asking "how do we know the AI got it right." That's the right question to be asking as more teams let agents touch documentation without a human reviewing every line.

That said, the "zero-config" framing does some work to paper over the fact that the more interesting half of the product (agent write access, live Ask AI) needs a server deployment, not a static one — a fair trade, but worth naming plainly rather than folding into the same pitch as the free static path. And a seven-week-old 1.x with 45 releases is not yet a tool with a long track record; the architecture reads well, but "reads well" and "survived a year of real teams hammering on it" are different claims.

Who should try it, who should wait, who should ignore it

Try it if you're an engineering team already comfortable with Astro-adjacent tooling, want free and self-hosted docs, and specifically want to let a coding agent participate in maintaining your documentation with some kind of check on its output.

Wait if you need guaranteed vendor support, a non-technical writer-friendly editing experience, or you're currently on Node <22 across your infrastructure and can't move that up on short notice — give the project a few more months to settle its API before depending on it for anything customer-facing.

Ignore it if you're already deep in a Next.js app and want your docs embedded in that same framework (Fumadocs is the more direct fit), or if what you actually need is a hosted, non-technical, drag-and-drop docs editor — that's Mintlify's lane, not this one.

What's your take: is shipping write access and a verification loop for AI agents the right next move for developer tooling generally, or does handing agents write access to docs — even with an eval command watching — just move the trust problem one layer down instead of solving it?

Sources:

DEV Community