Can chat uploads be handed to MCP/custom tools as the original file?

[SamTanna]

I’m evaluating Odysseus as a possible foundation for a self-hosted “Maker Assistant.”

The critical workflow is:

1. A user uploads an image, PDF, SVG, STL, or other maker file in chat.
2. Odysseus preserves the original file bytes and metadata.
3. An MCP server or custom tool receives a usable reference to that exact uploaded file.
4. The tool processes it and returns derived files or previews to the conversation.

The required attachment information would ideally include:

• original filename
• MIME type
• file size
• stable file ID, local path, or temporary download URL
• access to the original unmodified bytes

My questions are:

1. When a user attaches a file to a chat message, where is the original file stored, and what attachment metadata reaches the agent/tool/MCP dispatch layer?
2. Can an MCP server or custom tool directly retrieve the original attachment associated with the current message, or would this require changes to Odysseus?
3. Can tool-generated files such as PNG previews, PDFs, SVGs, or STL files be returned and displayed as downloadable artifacts in the same conversation?

I have tested Open WebUI, LibreChat, and AnythingLLM for this workflow. They generally treat uploads as model context or RAG input, but do not reliably expose the original uploaded artifact to external tools.

I’m mainly trying to determine whether Odysseus already has the necessary file lifecycle, whether the relevant code paths are cleanly extensible, or whether this would require a substantial architectural change.

[alteixeira20]

This is a very useful capability, but I think it should be treated as an explicit attachment/artifact contract rather than a one-off “pass the local path to the tool” feature.

The core idea seems right: if a user uploads a file, Odysseus should preserve the original bytes and metadata, and tools/MCP servers should be able to work with that original artifact when the user asks them to. That would unlock exactly this kind of maker workflow: images, PDFs, SVGs, STLs, previews, conversions, validation, slicing helpers, etc.

But I would be careful about the shape of the API. I do not think MCP/custom tools should casually receive arbitrary raw filesystem paths by default. A safer contract would probably look more like:

• chat uploads are stored once as first-class attachments;
• each attachment has a stable ID plus metadata: original filename, MIME type, size, checksum, created time, owning message/session;
• the agent/tool layer receives attachment references, not embedded base64 payloads;
• tools can request access to specific attachment IDs through a controlled file-access API;
• access is scoped to the current conversation/task unless explicitly granted otherwise;
• generated files are returned as artifacts with their own IDs, metadata, MIME type, and optional preview/download representation;
• chat rendering knows how to display returned artifacts without forcing tools to inline large blobs.

That would also line up with the storage issue discussed in #4762. If uploads become first-class artifacts, then messages can persist references instead of duplicating original file bytes in chat_messages.content, and search indexing can index only a sanitized text projection rather than raw base64.

I would frame the first implementation slice as something small and testable:

1. define the attachment metadata shape;
2. ensure original uploaded bytes are retained once and addressable by stable ID;
3. expose a read-only attachment lookup/access path to tools;
4. add one simple tool/MCP proof case that reads an uploaded file and returns a derived artifact;
5. document lifecycle rules: retention, deletion with chat/session, orphan cleanup, and whether artifacts are private to a session.

The important design point is that this is not just an upload convenience. It is a core contract between chat messages, storage, tools/MCP, and returned artifacts. If that contract is clean, it helps maker workflows, plugin/MCP integrations, and DB/storage hygiene at the same time.