AI makes it incredibly easy to generate documentation, meeting summaries, reports, and pretty much any kind of written content.
But does that mean organizations are actually getting better at managing their knowledge?
Think about how much documentation already gets forgotten in company wikis. Outdated instructions, duplicated pages, decisions nobody remembers making, and information that's technically available but almost impossible to find.
Now imagine AI generating even more of it.
We were using Confluence org-wide and it was not coping up for agentic workflows. I think this one would be more optimized for AI.
https://xwiki.com/en/comparisons/alternative-to-confluence — More needed on the AI side.
@vijayanandkailash We are working to develop more on the AI side, while also taking care of keeping the control in the hands of the documentation owner (organization) rather than handling control to the vendor.
Confluence announce this year that they'll train AI on user documentation. It's something we completely do not agree with.
That's why the XWiki MCP server keeps control in hands of users, with freedom to host as needed. It is disabled by default and you can enable anything you'd need and decide.
@lorina_balan Understood. Ultimately, enterprises need to build context layer on top of org-wide knowledge-base, to transit from human-focused to agent-focused systems.
@vijayanandkailash I'd say that the focus would be to remain human-focused but improve discoverability and efficiency with the help of agents. We're building XWiki in the open-source ecosystem since 2004 and we're always focused on keeping control in the hands of user.
@vijayanandkailash Another benefit of XWiki is that it's fully open source, as is the MCP server. If something is missing from the MCP, it's probably already doable with the REST API (and agents are quite good at using it). If something is missing from the API, well, the project is open-source, so you can relatively easily hack together an extension to fix your issue, or contribute the changes upstream. We also have a repo of skills and knowledge for agents to use (xwiki/xwiki-dev-llm on GitHub).
Starting with read access gives a team room to see what the agent does with its wiki. I'd want to review the proposed page edits before enabling writes.
@oleksii_sekundant you can totally do that. In fact, that's the default. Destructive tools such as write, delete, and page creation are disabled by default. But they're also extremely easy to turn on by ticking a box on the config page.
Hey, my experience with knowledge systems is that at some point they become write-only. SO MCP might help with that if people just connected them to their agent of choice. Does XWiki have any deconflicting mechanism?
@pronskiy Yes! XWiki has several deconflicting mechanisms. When collaborative editing is disabled, pages are locked when someone edits them. When collaborative editing is on, page saves are propagated to all users. If conflicts do appear, you get to choose weather to merge the changes, or keep one or the other.
XWiki also offers unlimited version history for pages, so you can revert to a previous version if necessary.
And the software also has scripting capabilities, on top of being open-source, which makes it possible for you to define and use your own decondlicting strategies.
Keeping write operations disabled by default feels like the right starting point, and the unlimited version history is reassuring. If an agent edit does go wrong, does reverting restore the whole page to the previous version, or can you roll back just that one change while keeping later edits?
@jcbuilds Reverting restores the whole page. As a work around to partial reverts, you can preview any version of the page, then copy-paste changes to the latest version.
So if an agent deleted an important paragraph, but otherwise did good work, you can preview the previous version of the page, copy-paste the paragraph in the newset version, then save the page. 🙌
@jcbuilds @gabriel_cio thanks for clarifying that!
Helloo Product Hunt! 👋👋
I'm Gabriel, Product Manager @ XWiki.
XWiki has been around for over 20 years. That's plenty of time for organizations to build up A LOT of knowledge in their wikis. Documentation, internal procedures, custom applications full of structured data... you name it. In XWiki you can have all that, and more.
As AI agents become ingrained in daily workflows, we started thinking of ways to make all that internal knowledge available to them.
That's what we're sharing today: the XWiki MCP Server!
It's a free, open-source extension that connects XWiki to AI agents like Claude Code, Codex, OpenCode, Pi, MS Copilot, and anything else that speaks MCP.
When you connect your agent to your wiki, you may expect it to be able to find out about that old project decision, update some pages or even attached documents, maybe build a small internal app. And your expectations would be fulfilled, because your agent can now do all of that, and more. Since XWiki supports structured data, agents can also work with objects and classes, not just read and write pages. That's what makes XWiki and AI such a good combo!! (especially if you're a dev)
When we started thinking about adding an MCP server to XWiki, making it optional and self-hostable was our default choice. We believe it's your right to choose whether you want to use these tools, and if you do, in what capacity. You decide if and when to install it, which model to connect through it, and where everything runs. You can self-host everything (XWiki, MCP, AI model), if that's what you need. Write operations are disabled by default, so you don't make any accidental oopsies, and the agent navigates the wiki with the same permissions as your user account.
We're still actively developing the extension. We'd love to get more people experimenting with it, maybe even on use cases we haven't even thought of yet.
If you want to give it a spin:
🔧 Installation guide
💻 Source code on GitHub
🗣️ Feedback on JIRA
I'm curious: Now that you can give your AI agent access to your team's wiki, what are you going to have it do first?
If you try the extension, I'd also love to hear what works, what's confusing, and what's missing. Feedback, bug reports, wild ideas... all welcome.
I'll be in the comments. Thanks for checking out our product!! 😋
Thanks so much for hunting us, @fmerian! 🙌
@fmerian Thank you for hunting the MCP Server!
@gabriel_cio Let's goo! We have been working on this for some time now, and I know how much passion you put into it.
Thank you, @lorina_balan !! I'm also super duper excited about the launch :))
@fmerian @gabriel_cio are you using standard oauth to mirror the user account permissions for agents like claude code? keeping write operations disabled by default is a smart move btw.
@fmerian @gabriel_cio @mohsinproduct Yes. The MCP endpoint is an OAuth protected resource: it advertises the XWiki OIDC Provider through the standard RFC 9728 metadata and a WWW-Authenticate header on 401. Clients such as Claude Code or Claude Desktop discover it, run the normal OAuth authorization code flow against the OIDC Provider, and send a Bearer token. XWiki validates the token and the agent acts as that user, with that user's rights. You need the XWiki OIDC Provider extension installed for this.
Hello all, and thanks for your support!
If you want to learn more about the XWiki MCP Server, @gabriel_cio hosted his first live session yesterday and did a live demo. You can check it on @YouTube: https://youtu.be/Bwxx3eR9OsM
Really happy to see this live as I know how much effort went into it and as always it's really interesting to interact with XWiki this way. Kudos to the team!
@dascalita_neculai Thanks for being here and supporting the launch!
@dascalita_neculai Thank you, Nicu!! 🫶🫶