Repository navigation
Improvment: Use resources and resource urls with the filesystem MCP server #297
Description
Is your feature request related to a problem? Please describe.
The filesystem MCP server method for reading non-text files is to call the read_file tool and return a base64 encoded string of the contents of the file. This is of limited usefulness and on files of moderate size it maxes out the response size and crashes claude.
This pretty much prevents using the filesystem MCP to interact with image files on local storage as any modern image is too large to load as a base64 string (and pass all the text through the LLM consuming tons of tokens).
The modelcontextprotocol spec describes how binary resources can be used for images and documents: https://modelcontextprotocol.io/docs/concepts/resources#binary-resources
Describe the solution you'd like
As a reference implementation the filesystem MCP should return resource urls rather than raw contents for non-text files, or for files over a certain size.
Describe alternatives you've considered
Allow Claude to directly load images into its context based on a path to a file without needing to use MCP
Activity
xhiroga commentedon Apr 21, 2025
I too am interested in this issue.
Having said that, I think its uniqueness would be an issue if it returns a URI, since I thought MCP was probably designed to run both on a local machine and on a web app.
Is there a solution to this problem, such as
http://resource-name.mcp, where the mcp server is supposed to act as an HTTP server and pay out a local-machine-only domain?(Sorry if I am wrong in my assumptions, etc. I would like to hear other people's opinions...)
OR13 commentedon May 3, 2025
For small files, ideally we would have
read_file_as_data_uri.For larger files, the file needs to be a resource that is available to the mcp server that needs to process it.
This could be implemented many different ways... but ideally, a local MCP server would upload the file and create a short URI and then a remote MCP server could access that URI assuming it had correct permissions.
I suppose you could also serve local files via a dev tunnel to a remote MCP server... security issues with all of these options.
X1pheR commentedon Oct 13, 2026
A downstream filesystem implementation already provides a bounded file-transport bridge; I am reconciling it with this existing issue rather than opening a duplicate resource-link request.
The transport contract is deliberately separate from ordinary inspection:
Client-specific native file-parameter metadata and deployment-specific download origins need not be part of the reference server. A generic opt-in extension could expose a narrow file-reference contract while leaving those adapters to consumers.
The current 1.0.0 release provides the per-instance server factory and Roots barrier needed to keep such extensions confined. Our release-adoption candidate retains bridge regression coverage and adds per-session/Roots-revocation checks. This is not a claim that existing read_media_file embedded resources satisfy the complete transport contract.
Under the repository's maintainer-only PR policy, would maintainers prefer an opt-in reference-server capability or a documented factory/extension hook for a separate adapter? I can provide a deployment-neutral prototype and regression prompts if this direction fits the reference implementation. No duplicate PR is being opened.
cliffhall commentedon Oct 19, 2026
Triage: Priority Low (total 5)
Board: Servers V2 (#43), Status
Incoming, awaiting maintainer review (no milestone yet). Part of the backlog triage in #4875.cliffhall commentedon Oct 29, 2026
Shipped in #5368, merged into
v2/main; it releases with milestone v2.3.0. Tested together with the rest of the #5269 work in the rollup #5405.