Improvment: Use resources and resource urls with the filesystem MCP server

[snaggle-ai]

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

[xhiroga]

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]

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.