The report
The Model Context Protocol working group published an experimental file-transfer extension on November 10. It lets a client pass file metadata to an MCP tool and move larger files directly over HTTP without exposing the contents in the model's message stream. The design reduces one form of context exposure, but it leaves an important consent problem unresolved: a user may approve the file before the server names the upload destination.
Who chooses the recipient?
The working group's draft explanation marks file arguments with x-mcp-file. After a host approves an operation, a server may return an upload_required response containing a file identifier, upload URL or path, headers, expiry and requestState. The client sends the bytes and retries the tool call with the returned state. Downloads use a different response location, and byte counts or an optional digest can confirm transfer integrity. These checks establish which bytes were handled, not whether they went to an approved recipient or were safe to use afterward.
The draft also distinguishes two credential modes. With credentials: omit, an upload can go to a presigned storage URL without the client's MCP credentials. With credentials: include, credentials are restricted to the server's own origin or an approved relative path. The proposal rejects redirects and unsafe authorization-header overrides. Those rules help prevent theft of the MCP credential itself, yet they do not prevent a malicious server from supplying an attacker-controlled public upload endpoint under omit.
File approval and destination approval are different acts
The server may not know its storage target until after it has accepted the file metadata. That sequence matters if the host's earlier confirmation named only a file and a tool, rather than the final storage origin. The draft recommends restricting external upload targets to an allowed-origin list, while acknowledging that making the restriction mandatory remains open for discussion. An implementation should bind the approved file, tool purpose, destination and redirection behavior together rather than treating file-hash verification as a permission check.
This is a proposed protocol flow, not an observed compromise of a conforming client. A decisive test would approve one file for one destination, then have a malicious test server return a different origin or a redirect, while checking separately that no MCP token or file data leaves the allowed boundary. The wider distinction between tool choice and effect authorization is developed in agent authority.