--- title: Images and other assets description: Understand how non-text files appear in a Knowledge Base and which parts agents can search. owner: markus last-reviewed: 2026-09-12 --- # Images and other assets A Knowledge Base can store non-text files alongside Markdown and text. Three states matter: - **Accepted** means Atmina stored the bytes and cataloged the file. - **Previewable** means Atmina can produce a safe browser rendition for that file and version. - **Searchable** means the current search provider produced derived text or another searchable projection. One state does not imply the next. The Files reader shows the file's current state; keep essential facts in a text page when agents must reliably recall them. The accepted and converted MIME families are defined by the running service, so consult the upload response rather than assuming an arbitrary file extension works. ## Upload from an agent The current Files view is for inspection. An authenticated MCP agent uploads assets. For content up to 1 MiB, it can use `upload_file` with the Knowledge Base, path, MIME type, and base64 bytes. For larger files, and as the preferred binary path: 1. Compute the exact byte count and SHA-256 locally. 2. Call `request_uploads` with `kb_id` and the path, MIME type, byte count, and hash for each file. 3. PUT each exact file to its returned URL, including every required header. 4. Call `confirm_uploads` with the returned batch token. 5. Inspect the per-file result, then open the file in **Files**. Indexing may complete after confirmation. The presigned single-PUT path accepts at most 50 files per request. Accepted Asset formats are JPEG, PNG, WebP, GIF, BMP, TIFF, HEIC, SVG and PDF. Declare the standard MIME type for the format; aliases such as `image/jpg` are not accepted. Images and PDFs have a 25 MiB Asset limit; other admitted file types retain the 100 MiB upload limit. An expired URL requires a new request. A hash or byte mismatch requires recomputing integrity from the exact uploaded bytes. See [MCP Memory Tools](https://atmina.ai/docs/mcp-tools-reference) for complete calls and recovery behavior. ## The Companion page A successful Asset upload creates a Markdown Companion at `.md`. It records intrinsic file facts and provides **Notes** for people or agents and **Description (generated)** for enrichment. Moving or deleting the Asset moves or deletes its Companion. Important searchable facts belong in the Notes. Asset listings can state who is responsible for searchable text. `atmina` means the Team's current policy assigns description ownership to Atmina; it does not mean a description has already been generated. `provider-native` means the retrieval provider may index its own conversion, which Atmina cannot read back, edit, or cite. `none` means neither route describes the Asset. An agent reading an Asset receives its Companion text and, by default, a medium image rendition when one is available. Set `include_image: false` for text only. This agent read does not return the original Asset bytes. ## Social previews on published pages An authored page can nominate one image for link previews with `social_image` in its frontmatter. Use a relative path to an Asset in the same Knowledge Base. For a page at `wiki/getting-started/setup.md` with an image at `images/setup.png`: ```markdown --- title: Set up your workspace description: Connect an agent and save your first team note. social_image: ../../images/setup.png --- # Set up your workspace ![An agent connected to the workspace](../../images/setup.png) ``` The image must belong to the current public collection: include it in a published page, as above, or in an explicitly included folder. Naming `social_image` alone does not publish an Asset. External URLs, absolute paths, query strings, fragments and paths that escape the Knowledge Base are not accepted. Atmina checks the current anonymous medium rendition before adding image metadata. The preview uses that safe WebP rendition, never the original download or a private signed URL. Its dimensions come from the returned image bytes. Alt text comes from the first matching image in the public page; when none matches, Atmina omits the alt metadata. Missing, unsupported or unavailable images leave a text-only card. The same applies while public renditions are disabled. Pages currently request a standard summary card; an image does not promise a large card or that every social platform will display it. Atmina rechecks access on new page and image requests. A social platform may retain an earlier preview in its own cache after you change or unpublish a page. Atmina cannot recall those third-party copies. ## Preview, download, and history Open a supported image in **Files** to view its medium rendition. Renditions remove metadata that should not be exposed in a browser preview. Some admitted assets cannot be transformed by the current rendition provider; the original can still be stored even when the preview reports unavailable. The current rendition adapter accepts JPEG, PNG, WebP, GIF, HEIC and SVG within its 20 MB input limit. BMP, TIFF and PDF can be stored but do not yet have image renditions. An accepted Asset between the provider's limit and the 25 MiB upload limit can also lack a preview. New previews can pause when Atmina reaches its shared monthly image transformation allowance or the provider is unavailable. Previously generated previews remain readable while you still have access to the Asset. Image descriptions use a separate limit; a description can be available while a new preview is unavailable. Original bytes are restricted to members of the owning Team, through the authenticated Files or REST download. A person who reaches a KB through a share can receive allowed thumbnail or medium renditions but cannot download the original. Anonymous public-KB readers follow the same narrower rendition rule, and the Asset must also belong to the current public collection. An unavailable or pruned version appears absent rather than revealing original-file existence to a caller who cannot receive it. Assets participate in file history. Choose a retained version to preview or restore; restoring creates a new head instead of rewriting the recorded version. Asset history keeps fewer recent versions than text history, so keep a separate archive when one is required. See [file history and recovery](https://atmina.ai/docs/file-history-and-recovery). ## Images in a public page Upload the image into the same [published Knowledge Base](https://atmina.ai/docs/publish-a-knowledge-base) as its Markdown page, then reference its relative path. For example, a page at `wiki/start.md` can use `![Team diagram](images/team-diagram.png)` for an image at `wiki/images/team-diagram.png`. Keep the exact filename case and use alt text that explains the image. A permitted asset referenced by a published page joins that Knowledge Base's public collection, even when it is stored outside `wiki/`. Its current Companion, linked to the permitted asset by its catalog path, can supply safe text and search results; it does not become an extra rendered wiki page. Unreferenced assets remain unavailable anonymously unless an owner explicitly includes their folder. Removing the final qualifying reference revokes access unless a folder opt-in or another allowed reference still includes the asset. References cannot include another Knowledge Base's assets or override system-folder exclusions. The public reader serves medium renditions in the article. Public image addresses support only thumbnail and medium output; a private Knowledge Base, a different Knowledge Base, or a request for original bytes cannot supply a public image. External image embeds are shown as links. Keep essential information in text because a stored asset may still lack a supported rendition. Storing an image, rendering it and making its contents searchable remain separate capabilities.