MCP: a base64 thumbnail in a reply is sent as it is

Under automation read roots, a reply's base64 `thumbnail` (a library
item's PNG in `library.get`, a page's PNG in `document.pdfInfo`) was
searched for hidden library paths like any other text, so a short path
that happened to occur in the encoded bytes was rewritten and the image
broke. `thumbnail` now joins `dataBase64`, `pngBase64` and
`thumbnailBase64` as encoded data that is left unchanged; text under it
that is not base64 is still searched.
This commit is contained in:
dotCooCoo
2026-11-12 09:12:40 -08:00
parent 89e52eaabc
commit c8a6b4d9c3
3 changed files with 11 additions and 6 deletions
+1 -1
View File
@@ -187,7 +187,7 @@ the suite) keep the agent to the folders you give it:
matched before the paths the request sent, so a sent path written over part of a hidden library's path does not
keep that path in the reply. A relative path is not replaced where it ends a longer path (`/work/data/icon.svg`
keeps `data/icon.svg`), and the absolute path it reads as from the app's working folder is replaced too. Encoded file data, a base64 string under `dataBase64`,
`pngBase64` or `thumbnailBase64`, is sent as it is.
`pngBase64`, `thumbnailBase64` or `thumbnail` (`library.get`, `document.pdfInfo`), is sent as it is.
- `swatch.library.list`, `brush.libraries`, `symbol.libraries` and `graphicStyle.libraries` list every library
but leave out the paths outside the read roots: a library's `path` and the user library folder in `userFolder`
are `null` there. A library loaded from a file outside the roots is listed as `loaded/<file name>`, numbered