---
type: "post"
id: "exploring-file-uploads-and-downloads-in-mcp-98cc90"
slug: "exploring-file-uploads-and-downloads-in-mcp-98cc90"
title: "Exploring File Uploads and Downloads in MCP"
description: "The Model Context Protocol team has published an experimental extension for describing file inputs and moving files between clients, MCP servers, and external storage."
retrieval_nugget: "The Model Context Protocol team has published an experimental extension for describing file inputs and moving files between clients, MCP servers, and external storage. It proposes a standard path for common workflows such as saving a conversation PDF or sending a large CSV to a sandbox, but remains a draft without a reference implementation."
published_at: "2026-11-11"
updated_at: "2026-11-11"
record_date: "2026-11-11"
date_kind: "published_at"
topics: ["mcp"]
entities: ["Model Context Protocol","File Uploads Working Group"]
related_patterns: ["agent-protocols-become-interoperability-layer"]
novelty_label: "new_fact"
what_changed: "MCP’s File Uploads Working Group has published a rough experimental extension definition for standardized file transfers, inviting developers to test it."
prior_refs: []
source_url: "https://blog.modelcontextprotocol.io/posts/exploring-file-uploads-and-downloads-in-mcp"
source_urls: ["https://blog.modelcontextprotocol.io/posts/exploring-file-uploads-and-downloads-in-mcp"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:exploring-file-uploads-and-downloads-in-mcp-98cc90"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/exploring-file-uploads-and-downloads-in-mcp-98cc90/","markdown":"https://newruntime.com/posts/exploring-file-uploads-and-downloads-in-mcp-98cc90.md","json":"https://newruntime.com/posts/exploring-file-uploads-and-downloads-in-mcp-98cc90.json"}
markdown_url: "https://newruntime.com/posts/exploring-file-uploads-and-downloads-in-mcp-98cc90.md"
---

# Exploring File Uploads and Downloads in MCP

## Retrieval answer

The Model Context Protocol team has published an experimental extension for describing file inputs and moving files between clients, MCP servers, and external storage. It proposes a standard path for common workflows such as saving a conversation PDF or sending a large CSV to a sandbox, but remains a draft without a reference implementation.

## Summary

The Model Context Protocol team has published an experimental extension for describing file inputs and moving files between clients, MCP servers, and external storage. It proposes a standard path for common workflows such as saving a conversation PDF or sending a large CSV to a sandbox, but remains a draft without a reference implementation.

## What happened

The Model Context Protocol announcement says that developers increasingly need MCP servers to work with files, while current implementations of file-transfer scenarios require bespoke tool conventions and transfer mechanisms. In response to recurring requests in customer discussions, the project started a File Uploads Working Group and spent the preceding month developing a rough extension definition. The team invites developers to experiment with the draft and report what happens in practice; it explicitly describes the work as experimental and says its current shape may change.

The extension identifies itself as `io.modelcontextprotocol/files` and is designed for protocol revision `2026-07-28` and later. A server can advertise support in its `server/discover` response, including `upload` for out-of-band uploads and `maxInlineBytes` for the total inline-file allowance. A client declares relevant capabilities in request metadata, including `upload` when it can upload out of band and `download` when it accepts download targets. The announcement's examples focus on saving a file to cloud storage, bringing a large CSV into a code sandbox, and sending a presentation or a ZIP containing an HTML deck and its assets to a remote service.

For a tool argument that represents a file, the server marks its input schema with `x-mcp-file`. The illustrated schema can specify accepted MIME types and a per-file `maxSize`; the file object includes fields such as an identifier, name, MIME type, size, and data, and can optionally include a SHA-256 digest. Small files may be sent inline as base64, subject to the server's advertised `maxInlineBytes`. For larger files, the client can omit the data field and use the out-of-band transfer path when the server advertises upload support. The announcement emphasizes that the model need not read every byte: it can work with file metadata while the file goes to its destination.

Before a file is sent, the host obtains user approval; when no user is present, agent policy determines whether transfer is allowed. The client then calls the tool with file metadata rather than contents. A client that does not support the extension treats the marked argument as an ordinary object. If the client has not declared support, the server should omit the tool or offer an alternative, such as accepting a URL to a file that has already been uploaded. The project says there is no reference implementation yet, anticipating that implementation details may change while integrating with third-party file services. The extension is optional for clients and servers, and the team expects to finalize it and make it stable before the end of the year.

## What the archive adds

We have not covered this before; it opens a new thread.

## Trend signal

This proposal fits the pattern of agent protocols becoming an interoperability layer: file inputs and transfer targets are being described at the protocol boundary rather than left to each tool's bespoke conventions. The draft is not yet evidence of broad adoption or a settled standard. [Agent protocols become the interoperability layer](https://newruntime.com/patterns/agent-protocols-become-interoperability-layer).

## Why it matters

Files are often the actual payload in an agent workflow, but sending their contents through a model or embedding bespoke upload logic in every tool can complicate integrations. MCP's proposal separates the model's understanding of a file from the mechanics of transferring it: a tool can declare what file it accepts, while a client handles the user-facing selection, approval, and transfer capability. If implementations converge on this interface, teams could build file-aware MCP tools that work across clients without designing a new convention for every server.

The design also makes authorization a visible part of the flow. The host asks the user before sending, and unattended agents rely on policy. That is useful framing, not a complete security guarantee: teams will still need to decide which destinations are trusted, how file metadata and content are validated, and what permissions an agent has. Because the extension is optional and experimental, builders should treat it as an integration direction to test rather than a dependency for production systems.

## What happens next

- **The project will publish a stable version of the extension before the end of 2026.** (6 months, 65%). Watch for: a finalized specification or announcement from the MCP project.

## Limits and uncertainty

The MCP announcement calls the definition rough and experimental, and says the design may change. It reports no reference implementation, so compatibility, transfer reliability, performance, and adoption across clients and servers have not been demonstrated by the project in this announcement. The source also describes anticipated integrations with third-party file services as a reason implementation details may evolve. Stability is an expectation, not a guarantee. The approval flow is described, but the announcement does not establish how different hosts will enforce policy or handle security risks in production. Builders should verify the current draft and test any implementation before relying on it.

## Reader takeaway

MCP is sketching a common way for tools to declare file inputs and for clients to move large files without routing every byte through a model. The practical opportunity is real, but the extension is still experimental: follow the draft if you build MCP file workflows, and wait for implementations and a stable specification before making it a production assumption.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Mcp](https://newruntime.com/topics/mcp.md): Explore the mcp topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)