Support File Uploads from Third-Party Clients

[qrnvttrl]

Describe the problem

The MCP server currently assumes that files to be uploaded are either available on the server's filesystem or accessible through a URL.

This becomes problematic when the MCP client allows users to upload files that are only available within the client session. For example, in OpenWebUI a user can attach an image to a prompt, but the MCP server has no way to access that file:

• The file is not exposed via a public URL.
• The MCP server has no access to the client's session storage.
• The MCP server does not share a filesystem with the client.

As a result, prompts such as:

Write a new article about dogs. Upload and include this attached image in the article.

cannot be fulfilled even though the user has provided the image.

Describe the solution

Add support for client-provided files so that MCP clients can pass uploaded files directly to the MediaWiki MCP server.

Possible implementations include:

• Support for MCP resources representing uploaded files.
• Accepting file content (e.g. base64 encoded) as tool arguments.
• Any other MCP-compatible mechanism that allows the server to receive file data without requiring a shared filesystem or a publicly accessible URL.

This would enable integrations with clients such as OpenWebUI and other MCP frontends where user-uploaded files exist only within the client session.

[alistair3149]

Thanks for the detailed writeup — the use case is clear and worth solving. We dug into the mechanisms end-to-end, and the honest conclusion is that there's no clean, portable way to do the client-session case today, so we're going to defer that part rather than ship something fragile. We did, however, ship the adjacent piece that unblocks the common variant — details at the end.

Base64 file content as a tool argument doesn't work. A tool argument is generated by the model, and for an attached image the model only ever sees the rendered pixels — never the underlying bytes — so it can't emit the base64. Even if a client framework injected the bytes, a base64 blob in the request bloats the payload and hits transport limits; it's a known anti-pattern (the same reason we avoid returning base64 blobs from read tools).

That leaves "the server fetches the file from a client-provided URL/handle" — essentially upload-from-URL aimed at a client-session URL. This hits three deliberate walls:

• SSRF protection — client-session file URLs (e.g. OpenWebUI's /api/v1/files/{id}/content) are private/internal addresses, which our SSRF guard is specifically built to block.
• Auth — reaching the client's file store needs credentials the MCP server doesn't have (OpenWebUI's working path requires a configured admin token).
• Portability — __files__ is OpenWebUI-specific, and is currently reported to arrive empty ([]) for external Streamable-HTTP MCP servers, so even the coupled path is unreliable upstream.

MCP-native options don't bridge it either: resources are server→client, client roots are inconsistently supported, and elicitation isn't a file channel.

What we did ship (#394): uploading from a URL no longer requires the wiki to have upload-by-URL enabled. The server now fetches the file itself (SSRF-guarded, size-capped) and uploads it directly, only asking the wiki to fetch the URL when the server can't reach it. Previously upload-file-from-url / update-file-from-url failed unless the wiki had $wgAllowCopyUploads enabled and the account held the upload_by_url right (both off by default). This is a stepping stone: in a deployment where the file is reachable at a public URL, that path now works end to end.

We'll revisit the client-session case if MCP standardizes a client→server file mechanism (modelcontextprotocol/modelcontextprotocol#1197), if OpenWebUI ships reliable __files__ forwarding for external HTTP MCP servers (open-webui/open-webui#19747), or for a specific deployment where the server can reach the client's file store on a known host. Leaving this open as the tracking issue for that.