This is AI generated, but gave me the ability to bypass this issue until it is fixed.
Analysis (source review, not yet verified on a running instance)
Where the problem is: The issue is in the space picker UI of the MCP configuration page. The MCP server's filter logic (DefaultMCPSpaceFilter) is not involved and has no size limit on the configured lists.
The picker in AI.MCP.Code.MCPServerConfigSheet is rendered with the platform documentTree macro:
No limit is set, so the tree falls back to the platform default of limit: 15 (documentTree_macros.vm). Children are then loaded page by page through "x more" (SpaceTreeNode#getChildrenQuery uses setOffset/setLimit).
Suspected cause (unconfirmed): The paginated loading probably interacts badly with the jsTree checkbox handling in AI.MCP.Code.MCPSpacePickerJSX. Two code paths look relevant:
The changed.jstree handler re-selects chippedNodes on deselect_all (triggered by the finder).
preselectStoredReferences calls openTo() on the stored references. Both can cause re-loads and re-selection, which would explain why a different number of entries shows up each time and why the page "jumps" when a finder result is selected. showOnlyViewable=true (the default) may also affect what each page returns.
Proposed fix:
Short term: set an explicit, higher limit on the documentTree macro in MCPServerConfigSheet, e.g. limit="1000". The trade-off is a slower tree on wikis with very many spaces.
Proper fix: make the picker's selection and chip reconciliation robust against lazy loading and pagination. Do not reconcile on partial or re-loaded selections, and do not rely on the finder's deselect_all workaround.
Workaround for affected users: The filter is stored as an object of AI.MCP.Code.MCPServerConfigClass on AI.MCP.Code.MCPServerConfig, in the spaceFilterSpaces / spaceFilterDocuments StaticList properties (relational storage). These can be edited directly in the object editor (/bin/edit/AI/MCP/Code/MCPServerConfig?editor=object):
Separate entries with |.
Write entries for the current wiki without a prefix, and entries for other wikis as wiki:Space. The sheet renders stored values as chips with hidden inputs, so they are kept when the form is saved later. Editing the database directly is not recommended: it bypasses the document cache and MCPConfigChangeEventListener.
Reviewed against application-ai-llm master @ e3c0e01 and xwiki-platform stable-17.10.x.
Jörg M on 14/Oct/26 11:42
h3. This is AI generated, but gave me the ability to bypass this issue until it is fixed.
Analysis (source review, not yet verified on a running instance)
*Where the problem is:* The issue is in the space picker UI of the MCP configuration page. The MCP server's filter logic ({{{}DefaultMCPSpaceFilter{}}}) is not involved and has no size limit on the configured lists.
The picker in {{AI.MCP.Code.MCPServerConfigSheet}} is rendered with the platform {{documentTree}} macro: {code:java} {{documentTree id="mcp-space-picker-tree" links="false" checkboxes="true" finder="true" showRoot="false" showWikis="$mcpReachOn" showSpaces="true" showAttachments="false" showTranslations="false" /}} {code} No {{limit}} is set, so the tree falls back to the platform default of {{limit: 15}} ({{{}documentTree_macros.vm{}}}). Children are then loaded page by page through "x more" ({{{}SpaceTreeNode#getChildrenQuery{}}} uses {{{}setOffset/setLimit{}}}).
*Suspected cause (unconfirmed):* The paginated loading probably interacts badly with the jsTree checkbox handling in {{{}AI.MCP.Code.MCPSpacePickerJSX{}}}. Two code paths look relevant: * The {{changed.jstree}} handler re-selects {{chippedNodes}} on {{deselect_all}} (triggered by the finder). * {{preselectStoredReferences}} calls {{openTo()}} on the stored references. Both can cause re-loads and re-selection, which would explain why a different number of entries shows up each time and why the page "jumps" when a finder result is selected. {{showOnlyViewable=true}} (the default) may also affect what each page returns.
*Proposed fix:* # Short term: set an explicit, higher {{limit}} on the {{documentTree}} macro in {{{}MCPServerConfigSheet{}}}, e.g. {{{}limit="1000"{}}}. The trade-off is a slower tree on wikis with very many spaces. # Proper fix: make the picker's selection and chip reconciliation robust against lazy loading and pagination. Do not reconcile on partial or re-loaded selections, and do not rely on the finder's {{deselect_all}} workaround.
*Workaround for affected users:* The filter is stored as an object of {{AI.MCP.Code.MCPServerConfigClass}} on {{{}AI.MCP.Code.MCPServerConfig{}}}, in the {{spaceFilterSpaces}} / {{spaceFilterDocuments}} StaticList properties (relational storage). These can be edited directly in the object editor ({{{}/bin/edit/AI/MCP/Code/MCPServerConfig?editor=object{}}}): * Separate entries with {{{}|{}}}. * Write entries for the current wiki without a prefix, and entries for other wikis as {{{}wiki:Space{}}}. The sheet renders stored values as chips with hidden inputs, so they are kept when the form is saved later. Editing the database directly is not recommended: it bypasses the document cache and {{{}MCPConfigChangeEventListener{}}}.
_Reviewed against application-ai-llm master @ e3c0e01 and xwiki-platform stable-17.10.x._
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
