Branch: refs/heads/main Home: https://github.com/xwiki-contrib/ai-llm Commit: 83f9ef0d172c611c3f7ce2ed46d632948da7b8a3 https://github.com/xwiki-contrib/ai-llm/commit/83f9ef0d172c611c3f7ce2ed46d63... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: A application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentSupport.java A application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetDocumentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/resources/META-INF/components.txt A application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentSupportTest.java A application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetAttachmentToolTest.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetDocumentToolTest.java Log Message: ----------- LLMAI-167: Add get_attachment tool (text/metadata/download paths) * New get_attachment read tool: metadata header (mimetype, size, attachment version, author, date, document version, download URL), text-mimetype content inlined under the ~6000-token cap with line-offset continuation, other types answered with metadata plus the download URL; exact filename matching (no fuzzy extension fallback); metadata=true probes without opening content * Streaming reads are heap-bounded: a single line longer than the budget is hard-cut and drained (mid-line cut note; the skip phase stores nothing), so newline-less text attachments cannot blow the output cap or memory * get_document header gains an Attachments: line (10 entries then +K more, human sizes, mimetypes) across all response shapes * Filenames and mimetypes are wiki-authored data: every echo is fragment-guarded (line breaks stripped, 200-char clamp) * New MCPAttachmentSupport helper holds text-mimetype detection, human sizes, header/list lines and the bounded window reader * mcp-server 941 tests, checkstyle 0, jacoco met Commit: 2935efeee2f8dbffdb9b707bfbadf53e19a4ecf9 https://github.com/xwiki-contrib/ai-llm/commit/2935efeee2f8dbffdb9b707bfbadf... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M application-ai-llm-mcp/application-ai-llm-mcp-server/pom.xml M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentSupport.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentSupportTest.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetAttachmentToolTest.java Log Message: ----------- LLMAI-167: get_attachment Tika extraction and inline image content * PDF/office/RTF attachments (incl. text/rtf) answer with Tika-extracted text, windowed under the same token cap and offset continuation as raw text; extraction failures degrade to the metadata header and download URL (store failures stay errors, like the text path); when extraction hits Tika's string cap the final window says the document continues beyond it * png/jpeg/gif/webp attachments up to 2 MB return a real image content block after the metadata header, so the model sees the image; larger or other image types fall back to metadata plus the download URL; reads are cap-bounded even when the declared size lies, with right-sized buffers for small images * image/svg+xml inlines as text (it is XML, not a vision format) * New dependency xwiki-platform-tika-detect for the shared platform TikaUtils (parsers ship in the XWiki WAR) * mcp-server 961 tests, checkstyle 0, jacoco met Commit: 4b7a81d987bc3f325702771579736215960a93f0 https://github.com/xwiki-contrib/ai-llm/commit/4b7a81d987bc3f325702771579736... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M application-ai-llm-mcp/application-ai-llm-mcp-server/pom.xml A application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentWriteSupport.java A application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/resources/META-INF/components.txt A application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentToolTest.java Log Message: ----------- LLMAI-168: Add write_attachment tool * Attaches a file to a document or overwrites an existing attachment: content (verbatim UTF-8 text - no trimming or line-ending normalization, content="" creates an empty file) XOR content_base64 (small binaries), both capped at 1M chars as the honest small-file ceiling; filenames refuse separators, semicolons and control characters * base_version discipline mirrors write_object: required when the document exists, omitted creates the document carrying the attachment; per-document lock and save-race recovery apply * Enforces the wiki's attachment policy via AttachmentValidator (Provider-injected, fail-closed refusal when the flavor-shipped implementation is absent); resets the stored mimetype after every write and clears the charset on binary overwrites of text files * Echoes attachment version (revisions kept in its history), document version with the base_version hint, size, mimetype, download URL and review line; [AI]-prefixed comment on document and attachment * New dependency xwiki-platform-attachment-validation-api * mcp-server 998 tests, checkstyle 0, jacoco met Commit: 8381b2202ca9c7f6c8530ace63583588795daec6 https://github.com/xwiki-contrib/ai-llm/commit/8381b2202ca9c7f6c8530ace63583... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M application-ai-llm-mcp/application-ai-llm-mcp-api/src/main/java/org/xwiki/contrib/llm/mcp/MCPToolSupport.java M application-ai-llm-mcp/application-ai-llm-mcp-api/src/test/java/org/xwiki/contrib/llm/mcp/MCPToolSupportTest.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetDocumentToolTest.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentToolTest.java Log Message: ----------- [Misc] Neutralize Unicode bidi controls in echoes and filenames * The shared line-break strip in MCPToolSupport also removes the 11 bidirectional formatting code points (U+202A-202E, U+2066-2069, U+200E/200F), closing intra-line spoofing of wiki-authored values in metadata lines (a filename whose bytes end .exe rendering as .txt); ZWJ/ZWNJ are deliberately kept for emoji and Indic/Persian text - hardens every tool's echoes at once * write_attachment refuses filenames containing directional formatting characters alongside the existing separator and control-character rule * mcp-api 66 tests, mcp-server checks green, checkstyle 0 in both Commit: 7332bf7c43870ae1858d42ee8a018ef0a7eefc4f https://github.com/xwiki-contrib/ai-llm/commit/7332bf7c43870ae1858d42ee8a018... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPAttachmentSupport.java A application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPDeleteAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPGetAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPManTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteDocumentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/resources/META-INF/components.txt A application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPDeleteAttachmentToolTest.java Log Message: ----------- LLMAI-169: Add delete_attachment tool * Deletes an attachment from a document behind Right.EDIT (the platform's own delattachment mapping), required base_version, the per-document lock and the sensitive-document denylist; refuses when the wiki has no attachment recycle bin, so deletion is always restorable via the UI; a miss lists the document's attachments * The removal stages through api.Document.removeAttachment so the attachmentsToRemove queue survives to the saved instance - XWikiDocument.clone() does not copy it, and staging on a manual pre-clone would silently drop the deletion at save time (adds are clone-safe, removals are not); the store contract is pinned by capturing the saved document's queued removal * Removals are recorded as minor versions with an [AI]-prefixed comment; echo carries size, mimetype, the restore note, the document version transition with the base_version hint and a Compare link * Man cross-link sweep: get/write/delete_attachment SEE ALSO chains, write_document NOTES points at the attachment tools, and the xwiki-syntax page links attach:/image: to get/write_attachment * mcp-server 1018 tests, checkstyle 0, jacoco met Commit: d4733419ed462021d4eddb5ec149b3d86b237fb8 https://github.com/xwiki-contrib/ai-llm/commit/d4733419ed462021d4eddb5ec149b... Author: Paul Pantiru <[email protected]> Date: 2026-08-18 (Tue, 18 Aug 2026) Changed paths: M application-ai-llm-mcp/application-ai-llm-mcp-server/src/main/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentTool.java M application-ai-llm-mcp/application-ai-llm-mcp-server/src/test/java/org/xwiki/contrib/llm/mcp/internal/tool/MCPWriteAttachmentToolTest.java Log Message: ----------- LLMAI-168: Fix stale attachment version in the overwrite echo * The real store bumps the attachment version on the api wrapper's internal save clone, never on the tool's staged copy, so the overwrite echo reported the pre-bump version while its own Download URL carried the new one; found in live validation * The echoed version, size, mimetype and Download URL now all come from the reloaded post-save document (with a staged-instance fallback that cannot fail a successful save); the overwrite test simulates the store's archive bump so the stale read fails it * mcp-server 1018 tests, checkstyle 0, jacoco met Compare: https://github.com/xwiki-contrib/ai-llm/compare/afc16b237f3c...d4733419ed46 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/ai-llm/settings/notifications