El 10 de noviembre de 2026, los maintainers del Model Context Protocol (MCP) publicaron el borrador de una extensión experimental, io.modelcontextprotocol/files, que permite a un agente subir y descargar archivos de un servidor MCP sin que los bytes pasen por el modelo. El archivo va directo a su destino y el modelo solo ve el resultado. La extensión funciona con la revisión 2026-07-28 del protocolo, es opcional y todavía no tiene implementación de referencia.

In sintesi

io.modelcontextprotocol/files es un borrador experimental para entrada y salida de archivos, pensado para la revisión 2026-07-28 de MCP. El equipo quiere estabilizarlo antes de fin de año.
Los archivos pequeños van inline en base64 y los grandes con una subida fuera de banda: el servidor responde upload_required con una URL temporal y el cliente repite la llamada tras la subida.
El punto débil es el destino: la aprobación del usuario llega antes de conocer el objetivo, así que un servidor malicioso puede indicar cualquier endpoint público. El borrador propone una lista de orígenes permitidos, aún no obligatoria.
El 11 de noviembre MCP fijó un ciclo de lanzamientos semestral: la próxima especificación se prevé para el 30 de marzo de 2027 (2027-03-30).
Por ahora sirve para prototipos y feedback: el propio borrador avisa de que habrá cambios incompatibles.

Qué problema resuelve

Hoy cada servidor MCP que maneja archivos inventa su propia convención. La entrada del blog de MCP del 10 de noviembre de 2026, firmada por Den Delimarsky (lead maintainer) y Wil St. Charles (Google), cita dos casos típicos: guardar en un almacenamiento en la nube un archivo surgido en una conversación y llevar un CSV grande a una sandbox de código. Sin un estándar, cada desarrollador monta sus propias convenciones y mecanismos de transferencia.

El objetivo declarado es que el modelo "no tenga que leer cada byte ni manejarlo directamente". El trabajo nace del File Uploads Working Group, que el equipo de MCP formó tras peticiones repetidas de clientes.

Estado: borrador experimental, sin implementación

La extensión es un borrador. El repositorio experimental-ext-file-uploads dice que no forma parte de la especificación MCP, que no se ha propuesto como SEP y que hay que "esperar cambios incompatibles mientras el grupo de trabajo itera". La implementación de referencia vivirá en ese repositorio, pero aún no está. Cuando lo revisé, el repo tenía 6 commits.

Según la entrada del blog, el equipo espera finalizarla y estabilizarla antes de fin de año. El borrador de la especificación dice que se apoya en SEP-2356 y SEP-2631.

Cómo funciona el flujo de subida

El flujo tiene cinco pasos y el modelo no participa en la transferencia. Se apoya en el núcleo sin estado de la especificación 2026-07-28: como explica la entrada sobre la especificación, el handshake initialize y la cabecera Mcp-Session-Id desaparecen y cada petición lleva su propia versión, identidad de cliente y capacidades.

El servidor anuncia la extensión en su respuesta a server/discover: upload si acepta archivos fuera de banda, maxInlineBytes si acepta archivos inline. El cliente la declara en los metadatos io.modelcontextprotocol/clientCapabilities de cada petición que pueda necesitarla, incluida tools/list.
El servidor marca el argumento de archivo en el esquema de entrada con x-mcp-file, con accept (tipos MIME permitidos) y maxSize. El archivo es un objeto con id, name, mimeType, size, un digest SHA-256 opcional y un campo data en base64 para el modo inline.
El host pide la aprobación del usuario (si no hay usuario, decide la política del agente). El cliente llama a la herramienta solo con los metadatos del archivo. El servidor comprueba permisos y cuota enseguida, así que un fallo cuesta cero bytes subidos.
Si las comprobaciones pasan, el servidor responde con resultType: "upload_required", una lista uploads con fileId, url, headers, credentials y expiresAt, y un requestState opaco y protegido contra manipulación.
El cliente envía el archivo con un PUT HTTPS (o un POST multipart si el destino lo pide) y, ante una respuesta 2xx, repite la misma tools/call con los mismos argumentos y el requestState sin cambios. El servidor verifica el estado, confirma que los bytes llegaron, valida tamaño y tipo, y solo entonces ejecuta la herramienta.

Un ejemplo abreviado del esquema, adaptado del post oficial (150 MiB son 157.286.400 bytes):

"file": {
  "type": "object",
  "x-mcp-file": { "accept": ["application/pdf"], "maxSize": 157286400 },
  "required": ["id", "mimeType", "size"]
}

Reintentar con el mismo requestState sigue el patrón Multi Round-Trip Requests (MRTR) introducido por 2026-07-28, que según la entrada sobre la especificación sustituyó peticiones iniciadas por el servidor como elicitation/create y sampling/createMessage. En herramientas que no deben ejecutarse dos veces, como crear un archivo duplicado, el servidor marca el requestState como usado antes de ejecutar, en un almacenamiento compartido por todas las instancias.

Descargas y credenciales

Las descargas usan el campo _meta del resultado, sin reintento. El campo content le dice al modelo qué se ha producido (por ejemplo "Exported q3-orders.csv."), mientras el destino queda fuera del contexto del modelo. El cliente descarga con un GET HTTPS, compara el número de bytes con size y, si hay digest, verifica el hash: si no coincide, descarta el archivo. Si las descargas deben ir en _meta es una pregunta abierta para los autores.

Cada destino lleva un campo credentials para que el cliente no envíe credenciales MCP a URLs arbitrarias:

Valor	Qué envía el cliente	Cuándo encaja
`omit`	Ningún token MCP, cookies ni credenciales del entorno	Almacenamiento externo con URL prefirmada
`include`	La credencial MCP, solo hacia un `path` bajo la dirección MCP o una URL del mismo origen que el servidor	Gateways y clientes en sandbox que solo alcanzan el gateway

Los clientes deben rechazar redirecciones y destinos que aporten una cabecera Authorization.

Riesgos de seguridad que conviene conocer

La sección de seguridad del borrador es la parte más útil. Puntos clave, todos del borrador de la especificación:

La aprobación del host ocurre antes de conocer el destino. Un servidor malicioso puede indicar cualquier URL pública como destino omit y recibir el archivo. La aprobación limita qué archivos salen, no adónde van. La mitigación propuesta es una lista de orígenes permitidos.
Con destinos form, el servidor controla gran parte del cuerpo de la petición que el cliente envía desde su propia red.
En un origen compartido por varias aplicaciones, la comprobación de origen de include no las distingue. El borrador desaconseja alojar servidores MCP en orígenes compartidos.
Quien posea un destino escribible puede sustituir el archivo por bytes del mismo tamaño, y las URL prefirmadas a menudo no se pueden revocar. Mitigaciones: vidas cortas, destinos de escritura única, digest obligatorio.
Las descargas no requieren aprobación del usuario, y un archivo descargado puede contener instrucciones dirigidas al modelo. Un digest correcto solo muestra que los bytes coinciden con el hash, no que sean seguros: los clientes deben tratar los archivos como no fiables.
Destinos, cabeceras, campos form, requestState y datos inline deben eliminarse de logs, trazas e informes de error.

Para los formatos aceptados, el borrador remite a OWASP ASVS 5.0 V5.

Preguntas abiertas

El borrador enumera siete puntos sin resolver. Los más relevantes para quien construye: si la lista de orígenes para omit debe ser obligatoria (y si se admiten hosts con comodín), si digest debe exigirse en todos los archivos, si las descargas deben usar resource_link, cómo tratar archivos de generación larga y cómo exponen argumentos de archivo los gateways con una sola herramienta genérica. También está abierto si ampliar el flujo a los resources.

El nuevo ciclo de lanzamientos

La entrada del 11 de noviembre de 2026 de Delimarsky y David Soria Parra fija lanzamientos semestrales, por lo general el último martes de marzo y de septiembre. La próxima especificación se prevé para el 30 de marzo de 2027 (2027-03-30). El soft freeze cae 2,5 meses antes, las betas de los SDK Tier 1 1,5 meses antes y el hard freeze un mes antes. Una propuesta que no esté lista pasa a la siguiente versión sin retrasar la especificación. Según la entrada, solo cambia la preparación de los lanzamientos: los mensajes y la negociación de versión siguen igual, así que clientes y servidores no necesitan cambios.

El borrador no dice si files entrará en el núcleo. En opinión de Rayo, mientras siga siendo experimental conviene tratarla como una extensión opcional y tener siempre una alternativa, como aceptar la URL de un archivo ya subido.

Qué hacer ahora

Si tienes servidores MCP cuyas herramientas reciben o producen archivos, anota cuáles usan hoy una convención ad hoc y cuáles manejan archivos de más de unos pocos MB. Son los candidatos naturales.
Mantén el base64 inline para archivos pequeños. El base64 infla los datos en un tercio aproximadamente (3 bytes pasan a 4 caracteres), y maxInlineBytes existe para fijar el tope.
Si expones un destino omit, usa URL prefirmadas de vida corta, escritura única y digest obligatorio.
No alojes servidores MCP en orígenes que compartas con otras aplicaciones.
Prueba el borrador en un entorno de pruebas y envía feedback al grupo de trabajo mediante las issues del repositorio o su Discord. No ates flujos de producción a un formato que va a cambiar.
En las descargas, trata cada archivo como no fiable: sin ejecución automática, sin usar name como ruta directa, sin sobrescribir sin aprobación.

Fuentes

FAQ

¿Qué es la extensión files de MCP?

Es un borrador experimental, io.modelcontextprotocol/files, que define cómo los clientes MCP envían archivos a las herramientas y cómo estas devuelven archivos. Los bytes van directamente a un almacenamiento o al servidor, sin pasar por el contexto del modelo. Funciona con la revisión 2026-07-28 y es opcional.

¿Puedo usarla ya en producción?

Mejor no. El repositorio avisa de cambios incompatibles y aún no hay implementación de referencia. El equipo quiere estabilizarla antes de fin de año. Sirve para prototipos y feedback, no para flujos que no puedas reescribir.

¿Cómo funciona la subida de un archivo grande?

El cliente llama a la herramienta solo con metadatos. Si permisos y cuota están bien, el servidor responde upload_required con URL temporales y un requestState. El cliente sube el archivo con PUT y repite la misma llamada con el estado sin cambios. El servidor verifica que los bytes llegaron y ejecuta la herramienta.

¿Cuál es el principal riesgo de seguridad?

La exfiltración. El usuario aprueba el envío sin conocer el destino, así que un servidor malicioso puede indicar una URL pública como objetivo y recibir el archivo. El borrador propone una lista de orígenes permitidos para destinos sin credenciales, pero todavía no es obligatoria.

¿Cuándo sale la próxima versión de MCP?

El equipo de MCP anunció el 11 de noviembre de 2026 un ciclo semestral. La próxima especificación se prevé para el 30 de marzo de 2027, con la cadena de versión 2027-03-30. Las propuestas que no estén listas pasan a la siguiente versión.