[BUG] Drive MCP `create_file` silently truncates binary uploads around 10K base64 chars

Drive MCP create_file silently truncating binary uploads above ~8K bytes — returning success with a valid ID while delivering a corrupt file — is a data integrity failure that is worse than an explicit error. The caller has no way to detect the truncation from the response.

The size cliff you identified experimentally is the key diagnostic: ~8,700 base64 chars (≈6,500 bytes) succeeds intact, ~9,632 chars gets a false "not valid base64" error, and ~16,016 chars silently truncates. This pattern suggests there is a hard limit somewhere in the MCP tool's content handling (possibly a JSON field size limit, an HTTP request body limit, or a string buffer limit at ~8-9K chars).

The likely cause: The MCP protocol JSON body for create_file contains the base64 content as a string field. JSON string size limits or HTTP body limits in the MCP transport layer may be truncating the content without surfacing an error — the truncated content is still valid UTF-8 (base64 is ASCII), so no parse error fires.

The fix has two parts:

1. Detect and surface truncation. The create_file response should include a uploadedBytes field that the caller can compare against the expected size. If uploadedBytes < encodedSize, the caller knows the upload was truncated.

1. Chunked upload for large content. The Drive MCP should use Google Drive's resumable upload API for content above a threshold (e.g., 5MB), chunking the base64 content across multiple HTTP requests rather than sending it as a single JSON field. This removes the size cliff entirely.

Immediate workaround: Limit binary uploads to the known-safe range (~6,500 bytes / ~8,700 base64 chars) and split larger files into separate uploads, or use Drive's import feature for Office files rather than direct binary upload.

Hitting the same bug with .docx uploads — adding evidence to confirm the
issue isn't xlsx-specific:

• File: 11,673-byte .docx (single table, ~6 paragraphs, three named styles)
• Base64 length: 15,564 chars
• Same misleading "The file content is not a valid base64 string" error as

the OP's 9.6K-char rejection case (so the rejection threshold extends
upward at least to 15.5K chars, not just a narrow band)

• Confirmed valid base64 via round-trip: base64 -d → diff against source

reports byte-identical

• Smaller .docx (8,569 bytes / 11,428 base64 chars) uploads cleanly using

the exact same encoding pipeline

Use case: an automated meeting-notes pipeline that generates formatted .docx
files for Google Drive. Every typical-sized output blocks on this bug.

Confirms the cliff is real for any binary office format (xlsx, docx, presumably
pptx), not just spreadsheets. +1 on all five suggested fixes — especially
returning fileSize in the create_file response so callers can verify.

+1 confirming, different mime type.

Repro:

• 75 KB PNG, ~100,400 base64 chars (well past your ~16K truncation threshold)
• create_file({ contentMimeType: "image/png", base64Content: ..., disableConversionToGoogleType: true })
• Result: "The file content is not a valid base64 string" — encoding is valid (independently decoded fine from the same source).

Same connector, same failure shape, not xlsx-specific.

Adjacent finding worth flagging here, since it's the same "silent corruption with no error signal" pattern the issue calls out: without disableConversionToGoogleType: true, even a tiny valid PNG (1×1, 92 base64 chars) is silently routed through Drive's auto-conversion path and becomes an empty application/vnd.google-apps.document (fileSize: 1) with no error and a viewUrl pointing at an empty Google Doc shell. Setting the flag is effectively mandatory just to attempt a real binary upload — and once you do, the size cap you describe is the next wall.

So binary uploads through this MCP have at least two failure modes stacked: (1) silent conversion to an empty Google Doc when disableConversionToGoogleType is omitted, regardless of size; (2) the truncation/false-invalid-base64 errors you document above the ~10–16K char threshold. Both produce success-shaped responses for small inputs, no surface area to detect corruption from the agent side.

Hitting the same bug from a different angle — adding it here in case it helps triangulate the root cause.

Different manifestation: silent byte substitution well below the cliff documented above

• File: 6,127-byte xlsx (xlsxwriter, single sheet, standard sharedStrings.xml)
• Base64 length: 8,172 chars — comfortably under the ~9.5K "valid base64" rejection threshold reported in the issue body
• Tool: mcp__claude_ai_Google_Drive__create_file with contentMimeType: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

What I see:

1. create_file returns success with a valid id.
2. get_file_metadata reports the correct size (6,127 bytes — same as local source).
3. download_file_content returns 6,127 bytes — same size as upload.
4. But the downloaded XLSX has a different MD5 than the local original: 12 byte differences scattered across 4 clusters in the file.
5. unzip -t on the downloaded file fails: three .xml entries fail to inflate (invalid compressed data), one CRC mismatch. Sheets refuses to open it ("File could not open").

Diff'ing the base64 strings (sent vs returned) shows 12 character substitutions — all replacements are themselves valid base64 chars (0→1, 1→l, t→u, 5→+, etc.), and the largest cluster is 9 contiguous chars rewritten. The substitutions are deterministic — uploading the same b64 twice produces files with the same corrupted MD5.

Why this matters

• The bug isn't limited to >10K payloads. Smaller binaries get silently corrupted with no error and matching file sizes, so even the workaround of "stay under the cliff" doesn't help.
• Same-size + different-content = no client-side check can catch this without a full byte-by-byte round-trip diff.
• The substitution pattern (valid base64 chars replaced with other valid base64 chars in clusters) strongly suggests an encoding/tokenizer step in the upload pipeline rewriting parts of the blob, not a length-cap truncation.

Strongly seconding the suggested fixes in the issue body, especially:

• Return a checksum (sha256 or crc32) in the create_file response.
• Document the constraint in the tool description.

Repro file available on request.

Confirming this is still broken as of late May 2026. Blocking an agentic Claude Code workflow that updates an .xlsx tracker file on a recurring schedule via /schedule — the truncation forces a manual download/merge step that defeats automation entirely.

CSV-per-tab workaround doesn't fit my use case (fill colors and in-cell comments are load-bearing). Resumable upload above ~256 KB (as proposed earlier in this thread) would unblock this. Happy to test a fix when one lands.

Still relevant in my case, both docx and xlsx.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

We hit this exact bug in production in August 2026, four months after this report — it is still unfixed, and this issue appears to have been auto-closed as stale rather than resolved. Requesting a reopen: here are fresh measurements that also show the failure envelope has shifted over time, which makes it worse, not better (no client-side "safe size" heuristic can be trusted).

Upload direction (create_file, base64 PDF test files, 2026-08-06):

| Payload | Result |
|---|---|
| 5 KB | ✅ uploaded, exact size |
| 15 KB | ✅ uploaded, exact size |
| 25 KB | ⚠️ uploaded with exact size, but a round-trip hash check found 1 character corrupted out of ~34,000 — silent corruption that fileSize cannot detect |
| 50 KB | ❌ impossible (base64 exceeds single-response output limits; no chunked/resumable upload available) |

Real-world incident (2026-08-05): a 12,135-byte .xlsx arrived on Drive as 8,424 bytes — same signature as the OP (12 KB → 8,447 B): success response with valid id and viewUrl, correct name/icon/extension, zip central directory chopped off, discovered only on open. Since the connector exposes no delete or overwrite, the corrupted file then sits in the destination folder until a human removes it manually.

Download direction (2026-08-07): the same class of failure affects download_file_content. A 12,155-byte .xlsx (16,208 expected base64 chars) came through as 12,712 chars — truncated, unreadable zip.

Note the thresholds do not match the OP's April measurements (failures already at ~7 KB then; 15 KB clean for us now, 25 KB corrupted): the limit is not stable across time/conditions.

The OP's proposed fixes are exactly right: (1) fail loudly instead of returning success on a truncated write, (2) return fileSize/checksum in the create_file response, (3) document the limit in the tool schema, (4) chunked/resumable upload (Drive v3 supports it).

The read-side sibling of this bug (silent truncation of the Google Sheets markdown rendering at ~2,400–2,500 cells per tab, no marker) is now reported at anthropics/claude-ai-mcp#805. Also related here: #54137.

It still reproduces for me.

Closing for now — inactive for too long.

Yes, we need some activity with fixing it, not closing.

Please open a new issue if this is still relevant.

Why we need new issue, this one is describing the problem well.

This class of bug shows up when file bytes go through the model or JSON. Upload by URL or path and return a download URL instead.

Hosted MCP that does that: https://mcp.beecargo.net/mcp (beecargo_upload). Guest bootstrap is /mcp/guest if /mcp asks for auth.