Suggested way to pass files from the client

[nickwinder]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

👋
I’m exploring ways to enable LLMs to process files using MCP servers. As a first step, the client needs to pass or report the file to the server for processing.

From the specification, I see two potential approaches:

1. Ask the LLM to send a base64 blob as part of the tool call.
   • This approach is unreliable, particularly as file sizes increase.
2. Request the roots/list endpoint from the client to identify readable files in the file system.
   • This depends on the client correctly implementing the roots protocol. However, in my testing with version 0.7.1 of the Claude desktop app, the roots protocol doesn’t appear to be supported (requests fail with -32601 (Method not found)).

Does anyone have suggestions for better ways to pass files from the client to the server for processing? Am I overlooking something fundamental in the protocol?

[jerome3o-anthropic]

Hey @nickwinder - thanks for reaching out, I'm on the anthropic team and this is something that I've been looking into recently, and want to figure out a good way to implement this sort of thing at the protocol level. I don't think you're overlooking anything, your use-case is currently finicky in the current state of the protocol.

My initial thoughts/work have been about allowing MCP server tools to return "files" - basically a tool result content type that is not intended for the LLM's context window, but more for use in an conversation's workspace. For an example scenario, this is what I'd like to enable:

• A BigQuery (or other SQL/data warehouse tool) is used by an LLM to make an SQL query that returns too much data for the LLM context (say something in the order of ~10mb)
  • This is returned from the tool using a tool result content "file" type
  • The "file" tool result indicates to the MCP host that this shouldn't enter the prompt verbatim, but it's creation should be indicated to the LLM (i.e. by adding "file XYZ was created")
• The LLM uses another tool to process that file
  • The processing tool then saves a file, which is also returned to the MCP host as a tool result of the "file" type
• The LLM then loads this file back to the warehouse, or elsewhere, using the processed file

This effectively allows bespoke ETL style workflows to be done by the LLM using MCP (along with many other use cases).

My thinking so far is to extend the tool result format to have a FileContent type, with B64 encoded data as the content. This would solve the "Tools creating files" usecase, but I'm not sure how we could implement the intention for the model to provide a file to another MCP server - I'm open to ideas.

Some things that are top of mind here for me are:

• We don't want to make too many assumptions around this "meta-context" should work for other apps, i.e. do we expect most MCP hosts to maintain a filesystem?
• How should the model indicate that it wants to include a file, and how should we accommodate this in the protocol

[nickwinder]

Thanks for replying!
I follow what you're saying, but one thing I may suggest changing is the way "file" data is reported and recieved.
For the tool result you refer to, I feel it would make more sense to have a new URIResource which can refer to a URI, but importantly does not contain the content blob.
The client is then free to fetch that content blob from the Server if it feels the need to do so.
I see some concepts in the schema that already relate to this kind of behavior, namely ReadResourceResult, and ReferenceResource. These seem like they can be borrowed to make what you describe possible fairly easily.

As for the client to provide a file (or resource) to a server, I would imagine, a similar mechanism must be reported to the server in order to process.

• Model sends a tool request with a URI
• Server can query client for the given URI and retrieve a blob to work with

I believe I need to sit with the protocol for longer to fully understand its limitations, but this seems logical to me right now.

[evalstate]

I started a related discussion in the Specification area here: modelcontextprotocol/specification#90

I think this is what the "Audience" annotation is for -
https://github.com/modelcontextprotocol/specification/blob/bb5fdd282a4d0793822a569f573ebc36804d38f8/schema/schema.ts#L814-L836

But this doesn't quite answer how best to deal with the specific implementation (which could be Roots, Resource Templates, or custom handling).

At the moment, the Client doesn't expose Resource Templates to the server; having a symmetrical approach might make sense for this case where the client can offer Metadata and Resource Identifiers that are made available to the server (and potentially scoped to a session).

This feels cleaner than a shared file system via Roots.

Another thing I'm finding is that I'm enjoying playing with MCP Servers and having Claude orchestrate them - but in a lot of cases once I've seen 2 clients working together, I don't necessarily need inference between them - some way of chaining them might be good.