Webinar overview | Meet the XWiki MCP Server

The XWiki MCP Server already allows AI agents to perform many everyday wiki operations using natural language. They can search, create, edit, and delete pages, work with structured objects and classes, and interact with attachments.

Version 1.0.0 provides 18 built-in tools, with additional semantic search capabilities available through the LLM indexing module. The full list is available in the MCP tools reference.

Looking ahead, we're exploring deeper AI integration directly into XWiki. One idea is a built-in chat interface that would let users interact with their preferred AI model without leaving the wiki. It could understand the context of the current page and show proposed changes before applying them.

We're also considering an auditing interface that would make it easier to review AI actions performed across the wiki. These ideas are still being explored, and community feedback will help shape their development.

AI agents can create, read, edit, search, and delete XWiki pages, provided they have the necessary permissions.

They can also work with XWiki objects and classes, retrieve document history, inspect links between pages, and interact with attachments.

For example, you could ask an agent to create a documentation page, update an existing procedure, retrieve a file, or organize information into structured records.

These operations are available through the MCP Server's tools, so the agent can perform them without manually navigating the XWiki interface.

Yes, although the approach depends on what you want to rename.

If you want to change a page's displayed title, an AI agent can edit it directly.

Changing the page's URL or reference requires a workaround. The agent can recreate the page at the new location and delete the original.

This is different from XWiki's native rename operation. If preserving page history, existing links, or other relationships is important, those elements should be checked carefully before using this approach.

The MCP Server uses XWiki's Solr search capabilities, allowing agents to search page content and retrieve relevant results.

Agents can use the query_documents tool to search the wiki, then retrieve individual pages for further analysis.

This means they can answer questions based on information distributed across multiple documents instead of relying on a single page.

Agents can filter search results by the last person who modified a page, using the author parameter of the query_documents tool.

Finding pages by their original creator is also possible through a creator: clause in the search query, since the tool accepts Solr query syntax.

The available search parameters are documented in the MCP Server's built-in man tool.

Agents can retrieve document metadata, examine previous versions, and compare revisions.

They can also inspect links, backlinks, and attachment information.

This can be useful for understanding how documentation has evolved, identifying recent changes, or investigating which pages depend on a particular document.

Once an agent retrieves content from XWiki, it canOpen the annotation about this text. summarize, translate, rewrite, or draft documentation.

If write tools are enabled and the user has the necessary permissions the agent can also save the resulting content to XWiki. More advanced tasks, such as identifying duplicate, inconsistent, or missing documentation, are possible workflows. However, their accuracy depends on the model, the information retrieved, and the criteria provided.

💡They should not be treated as guaranteed automatic quality checks. Human review remains important, especially when changes affect shared or business-critical documentation.

AI agents can use page content, metadata, and document history to help assess which information is relevant.

However, determining whether a page is authoritative, outdated, or suitable for a particular task depends on how the organization's knowledge is structured.

For example, teams can use dedicated spaces, consistent document labels, or structured metadata to distinguish active documentation from archived material.

Agents can then be instructed to prioritize specific sources or exclude certain content.

Organizations can improve the reliability of these workflows by maintaining clear documentation structures, using consistent lifecycle metadata, and limiting the content available to the agent where appropriate.

An AI agent can assist with identifying documentation that needs review, but the criteria for what counts as authoritative or outdated should be defined by the organization.

AI-generated edits are marked with [AI] in XWiki's version history. Changes are also attributed to the user account associated with the agent.

This allows teams to distinguish MCP-generated modifications from regular edits.

For organizations that want clearer separation, a dedicated account for AI agents can make their contributions easier to identify.

This does not mean XWiki automatically detects all AI-generated content. For example, text written with an external AI tool and pasted into a page manually would not necessarily receive the same attribution.

Yes, through the separate LLM indexing module.

This module supports semantic similarity and keyword-based search over indexed collections. When installed alongside the MCP Server, it adds 2 tools: search_collections and list_collections.

These complement the standard Solr-based search capabilities already available through MCP.

The LLM indexing module can retrieve relevant content from indexed collections and provide it as context for language models.

The MCP Server also exposes tools for accessing XWiki documents, metadata, and structured objects.

Together, these capabilities allow AI agents to retrieve information from different parts of a knowledge base, including structured records and related documentation. The information returned depends on the retrieval method and the configured collections.

This is one of the main use cases for the MCP Server.

An agent can search XWiki, retrieve relevant pages, and use that information to answer questions.

For example, an employee could ask, "What is our process for approving a new supplier?" The agent could retrieve the relevant internal procedure and use it to prepare a response.

The information available to the agent remains subject to the permissions of the authenticated XWiki user.

💡 The result should still be checked, especially when the information is incomplete, contradictory, or used for important decisions.

The MCP Server can provide page references and related information that an AI agent can use when preparing an answer.

For example, an agent could summarize a technical procedure and include links to the XWiki pages it consulted.

Open the annotation about this text.

It depends on the AI model and its instructions. If the user configures the AI agent with the instructions "always add links to pages you reference" or similar, the agent will almost always include these links.

The LLM indexing module supports incremental indexing, so you don't need to rebuild the entire index whenever wiki content changes.

The AI index listens to XWiki document events. When a page is created or modified, it's automatically queued for indexing. When a page is deleted, its indexed content is removed immediately.

Permissions work differently. Access rights aren't stored in the index. They're checked when a search is performed. This means permission changes take effect on the next search, without requiring reindexing.

A full reindex is only necessary when you change a collection's scope or embedding model.

Performance depends on several factors, including the size of the knowledge base, the type of search performed, the available infrastructure, and the connected AI model.

A simple document retrieval will generally involve fewer operations than a request requiring multiple searches, comparisons, and generated summaries.

For larger deployments, we recommend testing representative queries against the organization's own documentation and expected usage.

This helps identify whether adjustments are needed to search configuration, indexing, infrastructure, or the AI workflow itself.

The MCP Server is part of our broader work on AI integration in XWiki. The LLM Application and its indexing capabilities already provide additional ways to connect language models to wiki knowledge.

We're also exploring a more integrated experience within XWiki itself, including a chat interface where users could interact with their preferred AI model while working on a page.

Such an interface could use the current page as context and let users preview AI-generated changes before applying them. These ideas could also help inform future approaches to AI-assisted search within XWiki.

In version 1.0.0, individual MCP tool descriptions and their built-in man documentation are defined in Java code. They cannot be edited directly through the administration interface.

We've opened an issue to implement this in a future version.Open the annotation about this text.

However, administrators can customize the server name and description through the MCP Server configuration. The server description is shared with connected AI agents as initialization instructions, allowing administrators to provide general guidance on how the wiki should be used.

For more advanced customization, developers can also create their own MCP tools with custom descriptions and behavior.

Making individual tool descriptions editable through the administration interface was suggested during the webinar and is being considered for future improvements.

AI agents search the content indexed by XWiki's Solr engine, which includes the text extracted from supported attachments such as PDFs and Office documents.

By default, the MCP Server's search tool matches page titles and page content. The standard wiki search also covers attachment text, but the MCP search tool does not yet. To search inside files, the agent prefixes its query with attcontent:, which targets the extracted attachment text. A match returns the page holding the file. The agent then lists that page's attachments and opens the relevant one.

Organizations can instruct their agents to use attcontent: through the AI client's configuration or the MCP Server's description, which most connecting clients receive. How consistently the agent follows that guidance depends on the connected model. We plan to bring it closer to the standard wiki search in the following releases.

It's useful to distinguish between 2 different types of tokens. Authentication tokens identify the XWiki user on whose behalf the agent performs operations and determine which permissions apply.

LLM usage tokens are managed by the AI tool and model provider you choose. Their consumption and any associated cost depend on the connected AI client and model provider. XWiki and the MCP Server do not handle token billing or charge for the tokens consumed by your language model.

We've also worked to make the MCP Server as token-efficient as possible, reducing unnecessary information exchanged between the agent and XWiki.

The MCP Server does not maintain the conversation history between requests.

Instead, the AI client or agent framework manages the conversation, including previous messages, relevant context, and tool results.

When additional information is needed, the agent can make another request to XWiki through MCP.

This separation allows the MCP Server to focus on providing access to wiki information and operations, while the AI client manages the ongoing interaction.

An AI agent operates with the permissions of the XWiki user account associated with its authentication token. If that user cannot view or edit a particular page, the agent cannot perform those operations either.

Currently, the agent's permissions are tied to the user account rather than to an independently configured set of token permissions.

We're considering more granular token permissions in future versions, which could allow administrators to restrict what an individual token can do without changing the user's underlying XWiki rights.

Administrators can further restrict what the agent can do through tool selection and access filters.

Yes, using XWiki's existing permission system. For example, an organization managing documentation for multiple customers can create dedicated user accounts with access limited to each customer's space.

Agents authenticated through those accounts can then access only the content available to the corresponding user.

This approach works, although it requires managing separate accounts and permissions. For organizations with a large number of customers, that administration may become complex.

More flexible token-level permissions are one of the improvements we're considering.

Administrators can configure MCP access restrictions using allowlists and blocklists for specific spaces and documents. These settings operate alongside the authenticated user's existing permissions.

For installations with multiple wikis, administrators can also configure cross-wiki access. For example, an agent could be limited to a particular documentation space while remaining unable to access other parts of the wiki.

One important distinction is that semantic-search collections have their own access rules, separate from the standard MCP space filters.

There are 2 important details:

• Whitelist mode with an empty list applies no restriction. Add at least one space or document for the filter to take effect.
• Semantic-search collection tools use collection access rules rather than the standard MCP space filter.

Tag-based restrictions were suggested during the webinar as another way to control what agents can read or modify.

For example, administrators could mark selected pages as accessible to AI agents without having to organize them into separate spaces.

The current MCP configuration supports restrictions based on spaces and documents rather than page tags. We've captured this suggestion as feedback for future improvements.

Using dedicated service or machine accounts is supported and was recommended during the webinar.

A dedicated account can be configured with only the permissions required for its intended use. For example, an AI assistant responsible for answering documentation questions might need read access to selected spaces, but no editing rights.

The MCP Server does not provide a separate sub-account mechanism. Dedicated service or machine accounts are regular XWiki user accounts and count toward the number of licensed users under your XWiki subscription.

The OpenID Connect Authenticator and the OpenID Connect Provider serve different purposes. The Authenticator allows users to sign in to XWiki through an external identity provider. The Provider allows XWiki to act as an identity provider for applications connecting to it.

The MCP browser authentication flow requires the OpenID Connect Provider. The Provider ships with a token-based authenticator, which you select in the wiki's authentication settings. It acts as a bridge, when a request carries an OAuth bearer token, it authenticates that user, and otherwise it hands over to a fallback authenticator so regular logins keep working.

If your instance already signs users in through the OpenID Connect Authenticator, the 2 can coexist. The token-based authenticator handles API requests from AI agents, and the OpenID Connect Authenticator is configured as its fallback for the browser login. Users who sign in through your external identity provider authorize their AI agent with the same account.Open the annotation about this text.

The MCP authentication guide explains the setup, including how to configure the fallback authenticator.

The MCP Server supports authentication through XWiki's OpenID Connect Provider. Once authenticated, an AI agent operates with the permissions of the corresponding XWiki user.

This allows each user to interact with the wiki through an AI agent without automatically receiving access to other users' content.

Using an existing OAuth token issued by a different identity provider depends on the authentication configuration and supported authorization flow.

Improving the OAuth authorization workflow is part of the team's ongoing work.

We're working with the OpenID Connect provider maintainers to make authentication easier and reduce the need for users to create tokens manually. The existing browser-based authentication flow already supports authorization through XWiki's OpenID Connect Provider.

Future improvements aim to make this experience more convenient, particularly for organizations connecting multiple users and AI tools.

These are separate integration paths with different access-control mechanisms.

The MCP Server authenticates callers as XWiki users and uses normal page permissions, together with enabled tools and applicable MCP filters.

AI Collections have their own authorization configuration and retrieval permissions.

A trusted external application may also use a JWT-based authentication approach to map an external identity to an XWiki user and group membership.

The MCP endpoint does not use the Collections permission system or the external JWT authentication path directly. It relies on XWiki user permissions.

Yes, organizations can introduce a review and approval process for AI-generated changes.

If the XWiki Change Request application is installed, you can instruct the AI agent to use it to propose changes rather than publishing them directly. Designated reviewers can then examine the proposed modifications, approve them, or request adjustments before they're published.

The MCP Server also allows administrators to control which operations agents can perform. Write tools are disabled by default, and organizations should configure permissions carefully if they want to ensure changes go through an approval workflow.

We're also exploring deeper AI integration within XWiki, including the possibility of previewing AI-generated changes before applying them.

When write tools are enabled, AI agents can create and update pages, modify structured objects, and manage attachments within the permissions granted to their XWiki user account.

The MCP authoring tools also include safeguards against accidental editing conflicts.

For example, targeted edits use exact text matching, while document replacement operations check the version previously retrieved by the agent.

Administrators decide which write capabilities to enable for each wiki.

The MCP Server builds on XWiki's existing permission system and adds controls over which tools and content areas an agent can access.

Write tools are disabled by default, and administrators must explicitly enable them when required.

The MCP extension's code is also open source and reviewed for security issues. Organizations can inspect the implementation themselves and report potential vulnerabilities.

For production environments, we recommend using dedicated accounts with limited permissions and avoiding script, programming, or administrator rights for AI agents.

These precautions are particularly important because AI agents may encounter untrusted content containing instructions that attempt to influence their behavior.

The MCP security guidance explains the risks associated with enabling write operations.

When an AI agent edits a page through MCP, the change appears in XWiki's version history with an [AI] label, making it easier to identify AI-generated modifications.

XWiki also logs every MCP tool call, including which tool was used, the user account involved, whether the operation succeeded or failed, and how long it took. The content passed to the tool isn't logged.

These logs provide basic visibility into agent activity, but they don't offer a complete view of everything an agent has accessed or changed.

We're also exploring a dedicated auditing interface to make it easier for administrators to review AI activity across the wiki.

Organizations can choose which AI client and language model they use with the MCP Server, including self-hosted models.

XWiki permissions and MCP access restrictions determine which wiki content an agent can retrieve.

If an external AI provider is used, its data processing, retention, and model training policies apply to any information the AI client sends to that provider.

For organizations handling sensitive information, using a local model can help keep inference within their own infrastructure, provided the entire AI workflow is configured accordingly.

The MCP Server runs as an extension within your XWiki instance. It does not require a separate XWiki-hosted AI service.

To get started, install the extension through XWiki's Extension Manager, configure authentication and permissions, and connect an MCP-compatible AI client to the endpoint provided by XWiki.

Gabriel demonstrated the connection process during the webinar. You can reproduce it using the MCP Server installation instructions and the AI assistant connection guides.

The MCP Server architecture documentation also explains how the integration works.

The MCP Server is available for both XWiki Cloud and self-hosted installations, including on-premises deployments.

The same MCP Server code runs in both environments, and the installation and configuration steps are identical. You can follow the MCP Server installation guide regardless of your deployment choice.

The MCP Server does not require a particular language model or provider.

You can use a self-hosted model or an external model, provided your preferred AI tool supports MCP and can connect to the model.

For teams that do not already have an AI client, Gabriel recommended OpenCode as an option.

Embedding models are a separate consideration when using the LLM indexing module for semantic search. The available embedding configurations depend on that module.

Markdown-based tools can be convenient when an agent needs to read and modify files stored locally.

XWiki provides additional capabilities designed for managing knowledge across teams and organizations, including granular permissions, structured data, document history, attachments, and relationships between pages. Through MCP, an agent can interact with these features using dedicated tools instead of relying exclusively on file operations.

For example, it can retrieve a document's revision history, query structured objects, or identify pages linking to a technical specification.

The choice depends on whether the organization primarily needs file-based knowledge management or a collaborative platform with structured information and centralized administration.

The XWiki MCP Server does not use Playwright. It relies on tools built on XWiki's Java APIs, allowing AI agents to interact directly with wiki content and perform supported operations without navigating the user interface.

Playwright, browser automation tools, and OpenCode extensions can be used alongside the XWiki MCP Server, but they serve different purposes. Browser automation tools interact with web interfaces, while the MCP Server provides direct access to XWiki's capabilities, such as searching, reading, creating, and editing pages.

Depending on the workflow, an AI agent can use both approaches together.

Enterprise AI agents can connect to XWiki through its MCP endpoint, provided their platform supports the required protocol and authentication.

For Microsoft Copilot, we provide a step-by-step tutorial for connecting Microsoft Copilot Studio to XWiki. It covers configuring the MCP connection, authenticating with XWiki, adding the available tools to a Copilot agent, and testing access to wiki content.

Similar connection guides are available for other AI clients, including OpenCode, Claude Code, and Codex.

A separate XWiki-specific Copilot agent isn't required. You can connect an existing Copilot Studio agent directly to XWiki using MCP.

The MCP Server administration documentation covers installation, authentication, permissions, tool configuration, and security considerations.

For enterprise deployments, we recommend establishing clear rules around which AI clients employees can use, what information agents may access, and which actions they are allowed to perform.

Dedicated accounts, restricted permissions, and read-only configurations are useful starting points.

Organizations should also review their model providers' data handling policies and decide which operations require human review.

The XWiki open-source project maintains a collection of AI skills, knowledge files, and scripts on GitHub to help developers work on XWiki-related projects.

These resources support tasks such as contributing to XWiki's core code, developing extensions, writing documentation, testing, and following XWiki's development conventions. They can be used with AI coding assistants such as Claude Code, OpenCode, and Kimi Code.

The MCP Server also includes a man tool that provides AI agents with information about available MCP operations, XWiki syntax, and App Within Minutes applications.

For Velocity scripting, the shared development resources include guidance related to XWiki APIs and code, although a dedicated Velocity-specific skill is not explicitly listed.

Managing permissions is currently one of the main challenges, especially when organizations want to give AI agents access to selected content while protecting sensitive information.

The existing permission system supports these scenarios, but some deployments may require dedicated accounts or additional configuration. We're looking into ways to make access management more flexible.

Another challenge comes from the AI models themselves. Agents can sometimes generate incorrect tool arguments or commands. The MCP tools provide guiding error messages that help agents identify problems and retry operations, although successful recovery depends on the connected model.

Compliance is partial. Some requirements depended on additional PKCE support in the OpenID Connect provider, with related development and community discussion underway.

The team is working with the provider maintainers on the necessary authentication improvements, and related discussions are taking place in the XWiki community.

The MCP Server extension is open-source software, distributed under the GNU Lesser General Public License 2.1. The MCP Server is available in support plans starting with the Business tier.Open the annotation about this text.

For customers with an existing Business subscription, the applicable commercial conditions and any additional costs should be checked against their subscription.

The same applies to licensing considerations for dedicated AI service accounts.

The XWiki community forum is a good place to ask technical questions, discuss use cases, and share feedback with other users and contributors.

Developers can also follow the XWiki MCP Server source code on GitHub and report bugs or feature requests through the XWiki issue tracker.

Feedback from real deployments is particularly useful for identifying integration challenges and improving future versions.