MCP proposes a standard way to move files between models and tools

A draft response to growing file use

MCP began as a way to connect models to tools, but projects built with the protocol have become more ambitious over the past two years. According to the Model Context Protocol Blog, many MCP servers now need to work with files as agent capabilities and autonomy increase.

The blog describes saving a PDF from a conversation to cloud storage and pulling a CSV into a sandbox as common requests from developers adopting MCP. Until now, supporting those workflows would require bespoke tool conventions and transfer mechanisms. The File Uploads Working Group was created after the request repeatedly came up in customer discussions, and has spent the last month developing a rough extension definition.

The group is asking developers to test the draft as it moves toward prototyping. The work remains experimental, and there is no reference implementation yet. The blog says the design may change after integration with third-party file services, including cloud storage and database import and export systems.

How the proposed extension handles files

The extension is identified as io.modelcontextprotocol/files and works with protocol revision 2026-07-28 and later. Servers can advertise support for out-of-band uploads and inline files, while clients can declare support for uploads and download targets.

In the proposed flow, a server marks a tool argument as a file with x-mcp-file. Small files can be sent inline as base64 data, subject to the server's maxInlineBytes limit. For larger files, a client can leave the data out and upload the file separately if the server advertises upload support. The schema can also specify accepted file types, a maximum size and an optional SHA-256 digest.

The model does not need to handle the file contents directly. Instead, the client sends metadata such as the file's ID, name, MIME type and size. The server can use that information to check permissions and storage quota before any upload begins.

Approval, direct transfer and a stateless retry

Before sending a file, the host obtains the user's approval. If no user is present, agent policy determines whether the transfer is allowed. After the metadata check, the server can return an upload_required result containing an upload location, instructions and a requestState value.

The client then transfers the file directly to the target using an HTTPS PUT request. The blog says an upload target can instead specify POST with a multipart/form-data body when required by a storage service. The file contents travel outside JSON-RPC, and the model does not receive either the bytes or the upload URL in its context.

After a successful upload, the client calls the tool again with the same arguments and the requestState value. The server verifies the state, confirms that the upload arrived, checks its size and type, and only then runs the tool. The requestState design allows another server instance to continue the job and can prevent a tool from running twice in scenarios where a duplicate result would be unwanted.

What the proposal means for MCP users

The extension remains optional. Clients and servers that do not plan to support it need to make no changes, while clients that do not recognize x-mcp-file can treat the argument as an ordinary object. If a client does not declare support in its tools/list request, the server should omit the tool or provide an alternative, such as accepting a URL to an already-uploaded file.

For developers, the proposal offers a shared pattern for file-based workflows instead of requiring a separate convention for each tool or service. For users and agents, it could reduce the need for large files to pass through a model while retaining approval and server-side checks. The blog says the group expects to finalize the extension and make it stable before the end of the year, but its current design is still subject to change.