[BUG] Drive MCP download_file_content: small binary payloads are unusable — results spill to disk only above a size threshold, so small files are *harder* to read than large ones

### What happened?

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet


• This is a single bug report


• I am using the latest version

Related but distinct (upload side, create_file): anthropics/claude-code#50358 and #54137.
This report is about the download side.

What's Wrong?

download_file_content returns base64 into the model context. Large results are spilled to a
file under /mnt/user-data/tool_results/*.json, which the code-execution container can read.
Small results are not spilled — they exist only in context, and there is no supported way to
move them onto the container filesystem.

The practical effect is inverted from what anyone would expect: large files are usable and
small files are not.

Measured in a single session:

So the threshold sits somewhere between ~57K and ~256K base64 characters.

Why this matters (not cosmetic)

For any binary whose meaning lives in formatting, the text alternative is not equivalent.
read_file_content on File B returned 54 strikethrough runs — 3,299 characters of deleted
text — as ordinary live text, with no marker of any kind. Four underlined runs were likewise
dropped. Five literal [[...]] sequences did survive, which makes the loss actively
deceptive: it looks like markup is being represented.

File B is a redlined document of the kind used across legal, contract, and regulatory work,
where deletions are conventionally shown by strikethrough and additions by underline. Dropping
them silently yields a grammatically perfect, plausible, wrong document: text the author
deleted comes back as live text. In our case nine sections were silently reverted. There is no
way to detect this from the text output alone, and the surviving [[...]] markers make it look
as though markup is being handled correctly.

No workaround exists inside the container

Verified in the execution environment:

• No credentials. No GOOGLE_*/token/oauth/secret env vars; no ~/.config/gcloud,
  /run/secrets, .netrc, or service-account JSON anywhere.


• Network blocked. drive.google.com, www.googleapis.com, docs.google.com all return
  403 with x-deny-reason: host_not_allowed. Allowed hosts (e.g. pypi.org) return 200, so
  egress works generally.


• No conversion escape hatch. copy_file takes no mime parameter, so a .docx cannot be
  copied into a Google Doc server-side and exported as HTML (which would preserve strikethrough
  as CSS).

The only working path is to re-emit the base64 from context into a bash heredoc and base64 -d
it. That works, but costs roughly 19K output tokens per 43 KB document and scales linearly —
absurd for something the connector already does for free above the threshold.

### What did you expect to happen?

Any of these would resolve it; (1) is smallest:

Always spill download_file_content results to /mnt/user-data/tool_results/, regardless of size. The plumbing already exists and already fires above the threshold. The current behaviour looks like an unintended consequence of a context-size guard rather than a design choice.
Add an explicit output-path / saveTo parameter.
Make read_file_content markup-preserving for .docx (e.g. ~~struck~~ / __added__), or support exportMimeType: text/html for non-Google files. This would remove the need for the binary round-trip entirely.

Additionally, please document the threshold in the tool description, and return fileSize/checksum in the response so callers can verify integrity client-side.

### Steps to reproduce

Put a small (<100 KB) .docx containing strikethrough text in Drive.
Call download_file_content on it. Observe the base64 arrives inline; nothing appears in /mnt/user-data/tool_results/.
Call read_file_content on the same file. Observe the struck-through text is returned as ordinary text with no marker.
Repeat with a >200 KB file. Observe the payload spills to /mnt/user-data/tool_results/ and is readable from the container.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell

```

### Additional context

_No response_