MCP Working Group Publishes an Experimental Draft for Moving Files Between Clients and Tools Outside Model Context; No Reference Implementation Yet

Overview

The Model Context Protocol (MCP) project has published an experimental draft for moving files between clients and tools. A post on the MCP blog, dated November 10, 2026 (09:00 UTC in the page’s metadata), introduces an extension identified as io.modelcontextprotocol/files that works with protocol revision 2026-07-28 and later. The post calls the work “still very much an experimental effort”, says there is no reference implementation yet, and says the authors expect to finalize the extension and make it stable before the end of the year. The New Stack reported on the draft on November 11, 2026.

What the draft specifies

The Herald read the draft specification at commit 8a859b8, the latest on the repository’s main branch when checked on November 13. It is a draft, not a tagged release, and the draft says anything in it can change.

• File arguments. A server marks a file argument in a tool’s input schema with x-mcp-file, according to the MCP blog.
• Inline or out of band. Per the draft, a client can send a file inline if it fits within the maxInlineBytes total the server advertises, and sends the rest out of band only if the server advertises upload. A server that advertises upload without maxInlineBytes accepts files only out of band, and x-mcp-file.maxSize limits each file however it travels.
• Out-of-band uploads. For a file sent out of band, the client first calls the tool with the file’s metadata only. The server either rejects the call on that metadata or returns an upload_required result with an upload target and a requestState value, per the draft. The client sends the bytes to the target, by PUT or, for storage services that need it, POST including a multipart/form-data body, then retries the call with the same arguments and the unchanged requestState, as the MCP blog describes. The draft requires the server to confirm that the bytes arrived before it runs the tool.
• Model context. The draft says hosts must not place any target in model context, or place file bytes there to fill a file input, and the blog’s walkthrough says neither the bytes nor the upload URL entered the model’s context.
• Downloads. For a client that declared download support, a tool can list download targets in the _meta of its result, and the client fetches them with GET, per the draft. The client checks the size and, if one is supplied, the SHA-256 digest, and discards a file that fails. The blog cautions that “a matching digest confirms that the bytes match the supplied hash, not that the file is safe”. The draft itself notes that “The working group has discussed downloads but has not reviewed this shape.”
• Credentials. Each target carries a credentials field, according to the draft. With omit, the blog says, the client does not attach its MCP token, cookies or other credentials from its environment. Per the draft, a client honors include only for a path under the MCP address or a URL on the server’s own origin, and must not follow redirects.

The proposals that came first

The Herald’s own reading of the GitHub records (timestamps in UTC) shows three earlier proposals, all now closed; the two pull requests among them were not merged. SEP-1306, an exploratory proposal opened on 2025-08-05, was closed on 2026-03-12 with the comment “Superseded by #2356”. SEP-2356, opened 2026-03-05, was closed on 2026-06-26 with a comment saying it was closing “in favor of #2631 which will likely be the more durable solution.” SEP-2631, opened 2026-04-22, was closed on 2026-10-14 with a comment saying it was closed in favor of the extension. All three comments came from the account @localden, the handle the draft lists for Den Delimarsky.

The extension’s first draft pull request was opened on 2026-10-14 and merged on 2026-11-07. The repository README says the extension “has not been proposed as a SEP” and that the reference implementation will live in the same repository, while the draft says the working group plans to submit it as an Extensions Track SEP once a reference implementation exists.

Security and open questions

The New Stack reports that the host asks the user to approve an upload before the MCP server supplies the destination, so the user may not know where the file will go. The MCP blog says the credential safeguards “don’t by themselves control where the file goes”, and that the draft recommends hosts restrict omit targets to an allowlist of permitted origins, leaving open whether that should be mandatory.

By the Herald’s count, the draft’s Open Questions section lists seven items. Among them are whether the omit allowlist should become mandatory and whether wildcard hosts should be allowed, whether download targets should use resource_link instead of _meta, and whether the digest field should be required. For tools behind an executor, where a gateway exposing a single generic tool hides the inner tool’s schema, the draft says “The group needs to answer this before the extension leaves the experimental phase.”

Feedback since publication

When the Herald checked at 07:11 UTC on November 13, the extension repository had four open issues, all opened on November 12 and none with a comment:

• Issue 7 says two of the draft’s requirements on when clients must declare the extension for inline uploads “appear inconsistent”.
• Issue 8 says a gateway that does not know the extension can forward a client’s declaration upstream, and suggests that gateways remove it unless they implement the draft’s gateway section.
• Issue 9 addresses open question 4, suggesting that a host acting under operator policy with no user present must restrict omit targets to an operator-provided allowlist, and that wildcard hosts be allowed.
• Issue 10 asks clients to apply the operating system’s mark-of-the-web to downloaded files.

What is not known

Neither the blog, the draft, the README nor The New Stack gives a date for a reference implementation. The blog expects the inner workings to differ once the extension is integrated with third-party file services, and neither the blog nor the draft names clients or servers that plan to support it. Whether the group will adopt any of the four suggestions is not stated in the sources.

Context and disclosures

The New Stack describes Delimarsky as lead maintainer of MCP and a member of technical staff at Anthropic, says Anthropic launched MCP some two years ago, and says the working group was initially made up of members from Anthropic and OpenAI. The Herald’s contributor model is built by Anthropic. The New Stack’s pages state that its owner, Insight Partners, is an investor in OpenAI and Anthropic. The MCP blog and the draft are the project’s own documents; The New Stack is the only outlet independent of the project among the cited sources.