Moxie Docs: Knowledgebases - Automated documentation for developers, users, and AI Tools
by•
Now in Beta: Public Sites!
Create auto-generated, public-facing help centers and knowledgebases at https://moxiedocs.app. Features rich layouts, white-labelling, full search, and no vendor lock-in. Integrates directly with Changelog! Example: https://docs.moxiedocs.app
Also shipped:
Webhooks & Slack integration for indexing/PR alerts
UI/UX pagination & bulk action improvements
DB/infrastructure upgrades for faster loading
Continued improvements on document generation quality
Replies
Moxie Docs
The “living docs + MCP context for your GitHub repos” line is interesting. How does Moxie Docs decide what repo context is safe or relevant to expose through MCP? For example, can teams scope it to specific folders, branches, or docs, or is the context built from the whole repo by default?
Moxie Docs
@ivory_xuxuxu We index & analyze the entire repo by default, but agents get a citation-backed packet (conventions, docs, gaps, commands, and team notes) we filter out anything in .gitignore by default (as well as some known folders like build/dist outputs, temp files, etc.) and agents can pull path-relevant context directly, like "I am about to touch these files, what docs do those impact?" (simplified but the general idea via the MCP).
Fantastic idea! Wondering if there is a document update every time the repo content changes? Does it run periodically? or is it all one and done (I doubt it!)
Moxie Docs
@rachid_abadli Every opened PR triggers a pass / check! Along with any AI agent utilizing the MCP, and routine checks every few hours. If docs drift from code changes - we find, fix, and surface that!
Moxie Docs
Hey all!
We've greatly expanded and improved our developer documentation & MCP tooling - giving internal devs useful docs that are always up to date, and tools for their AI agents that reduce token usage and improve code quality output. We've build a public open-source MCP server, a CLI setup tool, and a prompt to get setup easily in 1-paste.
The biggest ask we've seen was: How do we manage public-facing docs? Help centers? Knowledgebases?
Now you can! - https://moxiedocs.app/ Starting in Beta any Moxie Docs user can opt-in themselves to start using our Public Sites feature. This unlocks:
Automatically generated documentation for both developers and consumers targeted for public consumption. Rich with layouts, charts, codeblocks, internal linking, and more.
White-labelling - add your logo, brand color, and light instruction changes
Coming soon custom domains and remove Moxie Docs linking for Pro or higher plans
Fully hosted, you control what documentation is published, all exists in your code base no vendor lock-in, you own your data. Always.
Full document search, reading time, reading indicator, table of contents, documentation groupin
Integrates directly with our Changelog feature - get a hosted changelog directly linkable and tied to your help center
Check it out with our own dogfooding example 👉https://docs.moxiedocs.app/
What else has shipped?
Webhooks integration - set up any custom webhook endpoint to get alerted when moxie docs finishes indexing, PRs are opened, or Friday Recap is ready for review
Slack integration - set up the same alerts and summaries to any Slack workspace
Improved UI / UX for pagination, bulk actions, and more
Faster loading times app-wide, and an upgrade to our DB and infrastructure to improve performance
See what else is new on our hosted Moxie Docs changelog: https://docs.moxiedocs.app/changelog
@cadenjs - love the idea, but don't like the subscription model too much. What if you only need this for 1 repo and the docs are only typically updated 2 to 3 times a year? Paying a monthly fee seems excessive, are you not considering a pay as you go model for smaller projects? Perhaps something tiered based on usage volume rather than a flat monthly/annual subscription.
Moxie Docs
@codeandsea great question! We do offer free support for qualified open source projects, but a big chunk of the value is the MCP itself. We categorize your code based conventions, docs, context and surface it all directly to agents via skills and an MCP - so even if docs only update periodically (which often is not the case) the MCP will continually provide benefit by giving AI agents direct context and conventions.
If you’ve ever had to say “follow our conventions” or ask AI to update docs it immediately caused to drift from truth, that’s what we solve for.
@cadenjs - Understood, and thanks for getting back to me so quickly. Best of luck with everything!
Really keen to test this out and see how it differs from using pre-commit documentation update hooks, which is my current setup. One quick question for ya - how do you handle the case where the docs are right and the code is wrong? On a bad merge, "sync to code" would happily overwrite the doc that describes the intended behavior. Does drift detection ever flag the code side, or is source always treated as ground truth?
Moxie Docs
@aidan_codefox really love this question! Moxie Docs doesn’t propose code changes so at this time we scan and index code only to understand conventions, overall context / behaviors, and capabilities (which get fed into documentation generation and our MCP), and since code is what’s running - that’s the source of truth for docs. I personally use & suggest code review tools that would catch (probably in the same PR as a doc update) that the code may have bugs or be incorrect.
What we would help with though is that reverse side - if you have your agent fix a bug, a normal flow would mean it fetches codebase context and scans similar files and tries to figure out conventions (all token burn) but then fixes the bug - maybe after some follow up prompts. With our MCP it gets your conventions and context upfront, when it fixes the bug it can automatically fetch what docs already exists, scan those only to identify if it needs to update them, and then update them for you in the same session.
Congrats on the launch! On the PR checks that keep docs honest, does it block the merge if docs go stale, or just leave a comment flagging what needs updating?
Moxie Docs
@irahimiam We run checks as GH native tie-ins so you can set it as a requirement they pass! Otherwise it will flag via comment + the failing check with details.
Moxie Docs can also be configured to automatically rewrite any PR description to match a standardized format so it’s easier for humans to review / orient any PR.
This feels useful because docs are starting to serve two audiences at once: humans reading the public knowledgebase, and AI agents using repo context while work is happening.
The trust boundary I’d care about is the step before something becomes public. Temporary implementation notes are often helpful for an agent, but not always safe or polished enough for users. A clear diff/review queue for “agent-found doc drift” before publishing would make this much easier to trust.
Moxie Docs
@grace_lee26 that’s exactly what our focus is! Everything runs continuously but nothing happens automatically - the control to review and merge is 100% in your hands. Moxie Docs does the heavy lifting surfacing opportunities, creating changelog items, opening PRs updating docs, and aligning / checking engineer PRs, etc but the final step of merging is always in the hands of repo maintainers.
The only thing worse than no documentation, is incorrect documentation. We take this an extra step with the new public Knowledgebases since it’s an entry point for consumers - you first merge our proposed docs into your repo (no vendor lock in), then 1-click a button to publish them live on the knowledge base.
The PR check is the part I would lead with. Docs rot because nothing in the workflow ever tells you they rotted, so a check that fails loudly on the diff is worth more than any amount of generation quality.
One thing worth thinking about on the MCP side: how the docs get chunked matters as much as how they get written. An agent pulling repo context does much better with small single-topic sections it can retrieve precisely than with one long well written page, because a long page embeds as an average of everything in it and stops matching specific questions.
Congrats on the second launch.
Moxie Docs
@paul_crinigan Absolutely - and for the MCP when we index a repo we pull out and identify conventions (these get updated periodically as they can also change over time) and any agent requesting doc info gets the documentation that exists itself, it can provide or identify any source / cited files related to the doc (for either continued examination or for identifying if work it did may have affected a doc in the repo), and any codebase context that is relevant! You can check out more on our MCP here if you're curious: https://moxiedocs.com/mcp
Congrats on the launch. Living docs plus an MCP server for the same repo is a smart pairing, most tools solve doc-drift or agent-context but not both from one source of truth. Before I'd point Public Sites at a client's docs: is there a filter step before publishing that catches anything meant to stay internal, a staging URL or an internal-only heading written into the markdown, or does that rely on the team keeping the source clean themselves?
Moxie Docs
@vollos You can choose what repo docs get written to (where we open the PRs to) and that can be either public or private - and separate from the main repo or alongside your code. From there we have a layer of publishing before the doc goes live.
So the workflow is we propose a doc, you review / approve, any approved you click a button and we open a PR adding them, once you merge the last step is just clicking publish. At any time you can revoke published docs (they’d still be in your codebase though, just taken off the site).
@cadenjs Appreciate the walkthrough - the propose, approve, merge, publish chain is basically the filter step I was asking about. One follow-up on revoke: when you pull a doc off Public Sites, does that unpublish hit instantly at the edge/cache too, or can the old URL still resolve for a bit until it catches up?
Moxie Docs
@vollos Instantly updates! You can also "Pin" a public site doc so you can change it in-code / repo as much as you want and then the public site retains the stored version until you un pin it again.
@cadenjs Good to know it's instant. One more on Pin: when you unpin a doc, does that re-trigger the review/approve step, or does it just swap straight to whatever's currently in the repo?