@haydenbleasel@fmerian Congrats on the launch! "AI-ready" jumped out at me. I’m curious how you’re actually pulling that off. Is it just clean markdown that LLMs can chew through easily, or are you baking in structured data or schemas so AI assistants pull and cite docs correctly, not just scrape them? We’ve been down this hole ourselves on the content team, so I’d love to hear how you’re tackling it for a docs-first product.
@fmerian@haydenbleasel Appreciate the link looking now. One thing I’m wondering: with both llms.txt and MCP servers running, have you seen one get picked up more in practice? We put llms.txt on our site a while back, and it’s hard to gauge from out here whether assistants lean on it reliably or if uptake’s still patchy model to model. Have you spotted any real signal either way?
Report
Huge congratulations on the release! The decision to ship AI-ready endpoints alongside static Astro performance is a massive win for modern docs.
Does Blume support custom MDX components out of the box, or do those require extending the config? Upvoted and wishing you a great launch day!
curious what "AI-ready" means concretely here - is it generating something like an llms.txt under the hood, or is it more about the markdown being cleanly chunked/structured for retrieval. the docs tools I've seen that use this label usually just mean well-formed markdown, but the actual pain point for me has always been staleness - docs drifting from the real API surface over time. does blume do anything to flag that drift, or is it purely a generation/theming layer on top of whatever markdown you feed it
@galdayan Means lots of things - llms.txt, raw markdown via negotiation headers, mcp servers, agent readability, skills. All in the pursuit of making your docs easier to read by agents. Check it out here: https://useblume.dev/docs/configuration/ai
@galdayan As for staleness, we have a few things to help here e.g. translations but hoping we can work on bridging the gap between product and docs more going forward, perhaps with skills.
Report
@haydenbleasel that's a fair scope for a docs framework specifically - the drift problem really lives one layer up, in the CI/build pipeline diffing docs against the actual API surface, not in how the markdown gets served. skills as the bridge makes sense, thanks for the link, going to read through the ai config page properly
Report
Congratulations on the launch! The service can integrate with Claude Code, right?
Kilo Code
the maker of @Ultracite keeps cooking.
@haydenbleasel just introduced @Blume, an open-source alternative to @Mintlify and @Fumadocs that is fast, AI-ready, and zero-config.
view source code here
@haydenbleasel @fmerian Congrats on the launch! "AI-ready" jumped out at me. I’m curious how you’re actually pulling that off. Is it just clean markdown that LLMs can chew through easily, or are you baking in structured data or schemas so AI assistants pull and cite docs correctly, not just scrape them? We’ve been down this hole ourselves on the content team, so I’d love to hear how you’re tackling it for a docs-first product.
Ultracite
@fmerian @farrukh_ahmed8877 Thanks! There's a ton of different ways - llms.txt, *.md, agent readability, MCP servers. Check it out here: https://useblume.dev/docs/configuration/ai
@fmerian @haydenbleasel Appreciate the link looking now. One thing I’m wondering: with both llms.txt and MCP servers running, have you seen one get picked up more in practice? We put llms.txt on our site a while back, and it’s hard to gauge from out here whether assistants lean on it reliably or if uptake’s still patchy model to model. Have you spotted any real signal either way?
Huge congratulations on the release! The decision to ship AI-ready endpoints alongside static Astro performance is a massive win for modern docs.
Does Blume support custom MDX components out of the box, or do those require extending the config? Upvoted and wishing you a great launch day!
Ultracite
@vahid_davoudi Yep custom MDX is definitely supported: https://useblume.dev/docs/configuration/customization
curious what "AI-ready" means concretely here - is it generating something like an llms.txt under the hood, or is it more about the markdown being cleanly chunked/structured for retrieval. the docs tools I've seen that use this label usually just mean well-formed markdown, but the actual pain point for me has always been staleness - docs drifting from the real API surface over time. does blume do anything to flag that drift, or is it purely a generation/theming layer on top of whatever markdown you feed it
Ultracite
@galdayan Means lots of things - llms.txt, raw markdown via negotiation headers, mcp servers, agent readability, skills. All in the pursuit of making your docs easier to read by agents. Check it out here: https://useblume.dev/docs/configuration/ai
Ultracite
@galdayan As for staleness, we have a few things to help here e.g. translations but hoping we can work on bridging the gap between product and docs more going forward, perhaps with skills.
@haydenbleasel that's a fair scope for a docs framework specifically - the drift problem really lives one layer up, in the CI/build pipeline diffing docs against the actual API surface, not in how the markdown gets served. skills as the bridge makes sense, thanks for the link, going to read through the ai config page properly
Congratulations on the launch! The service can integrate with Claude Code, right?
Aymo AI
Amazing stuff!
We generally use Fuma or Nextra, but it seems like found a better alternative. Congrats on the launch, and thanks for building this.