MCP 二進位檔案限制 | AI 傳圖卡關與 WordPress 解法

用 Claude Code 加 MCP 請 AI 把 WordPress 首頁的一張圖換掉，這種事聽起來十秒就該搞定，我們卻卡了快一小時。先直接講結論：MCP 搬不動二進位檔案，圖片、PDF 這類檔案別交給 AI 經 MCP 傳，它會壞在 base64 上，原因不是哪個設定填錯，是協定本身的限制，這篇就拆解它為什麼必定失敗，以及檔案操作該換到哪裡去做。

一個「換首頁圖片」的簡單需求，為什麼卡了一小時

需求很單純：客戶給了一張新的首頁主視覺，我們想直接在 Claude Code 裡對 AI 說「把首頁那張圖換成這張」，讓它透過 WordPress MCP 的 media_upload 工具上傳到媒體庫，再更新頁面。

第一次，AI 回報上傳成功，但媒體庫裡的圖打不開。第二次，換一張更小的圖再試，一樣壞。反覆試了快一小時，每次的失敗方式還不太一樣，這才意識到問題不在操作，在更下面的地方。

把過程攤開來看，卡點集中在一個環節：AI 要把圖片內容當成參數塞進工具呼叫，而圖片是二進位資料，塞不進去，只能先編碼成 base64 字串，麻煩就從這裡開始。

問題出在 base64：AI 不是複製，是逐字重寫一串亂碼

先看兩組實際數字。一張 39KB 的 JPEG，編成 base64 之後是 52,484 個字元。AI 寫到第 6,531 字就崩了，後面接不下去。換一張 6KB 的 PNG，編出來 8,084 個字元，這次長度對了，但把檔案抓下來一算 MD5，校驗值對不上，檔案還是壞的。

關鍵在於 AI 產出這串 base64 的方式。它不是把編碼結果複製貼上，而是一個 token 一個 token 重新生成那串字元。對語言模型來說，這等於要求它把一段高亂度、沒有語意規律的長字串「零容錯地逐字背出來」，這正好是語言模型最不擅長的任務。

而 base64 的容錯率是零。錯一個字元、少一個字元、順序顛倒一個字元，解碼出來的整個檔案就毀了。文字內容錯一個字讀者還能猜，base64 錯一個字，圖就是打不開。長度對不對是一回事，逐字正確又是另一回事，6KB PNG 那次就是敗在後者。

更底層的原因：MCP 的 JSON-RPC 沒有二進位型別

就算叫 AI 再小心也沒用，因為這是協定層的限制，不是它努力一點就能克服的。

MCP 底層走的是 JSON-RPC，工具呼叫的參數就是一包 JSON，而 JSON 本身沒有二進位型別，沒有檔案 handle，也沒有 HTTP 表單那種 multipart 上傳，一個位元組串想擠進 JSON，唯一的辦法就是編成字串，於是又繞回 base64 那條死路。

還有第二層限制。MCP 採同步的請求模型，一次呼叫要在一個回合內把結果吐完，不適合需要背景執行、分段串流的長時間任務。傳一個大檔案剛好就是這種任務，它天生跟 MCP 的節奏對不上。

順帶說明，這是現階段的協定限制，不是永久判決。社群已經在推 Binary Mode 的提案（SEP-1306），但到我們處理這個案子時它還停在 draft，正式落地還要等。在那之前，把檔案硬塞進 MCP 就是在跟協定作對。

那檔案該怎麼傳？三個繞過 AI 的 WordPress 解法

方向很清楚：別讓那串位元組經過 AI 的手。讓 AI 負責下指令，真正的搬運交給伺服器或傳輸工具。實務上分三種情況：

1. 檔案已經有公開網址：直接把網址交給伺服器，讓它自己抓。在 WordPress 端用一支 wp_remote_get 把圖抓回來寫進媒體庫，整段傳輸走的是伺服器到伺服器，AI 全程沒碰到位元組，只負責說「去抓這個網址」。
2. 檔案在本機、沒有公開網址：老實用 SFTP 或主機的檔案管理員上傳。這是最不性感、但最穩的做法，二進位傳輸本來就該交給為它設計的工具，而不是硬要塞進對話。
3. 要在 WordPress 端落地處理：用 execute_php 之類的能力，把「讀檔、寫入媒體庫、更新頁面」這串動作丟到伺服器端一次做完。AI 出的是一段 PHP 指令，跑的是伺服器，位元組始終沒進到 token 流裡。

三種解法的共同點都一樣：AI 下判斷、給指令，檔案本體走另一條不經過 AI 的管道。

判斷原則：MCP 管決策，檔案搬運交給伺服器

這次卡關真正的收穫，是把一條界線劃清楚：AI 適合下判斷、給指令、把流程串起來，不適合當搬運位元組的水管。

放到 WordPress AI 自動化的場景，我們的分工是這樣：結構化的資料操作（發文、改設定、查訂單、更新欄位）交給 MCP，因為那些本來就是 JSON 能表達的東西；檔案與系統層的操作（上傳媒體、搬檔、備份、跑批次）改走 SSH 加 WP-CLI 或伺服器端腳本，讓二進位資料走它該走的路。

這其實補上了我們先前談該選 MCP、REST API 還是 SSH 時漏掉的一條軸。那篇用「自主程度、信任邊界、可觀測性」三個維度分工，這次的教訓多加了第四個維度：資料型別。有些工作不是 AI 該不該做的問題，是那串位元組根本擠不進 JSON。想把檔案類操作交給 AI 的人，可以直接參考我們用 SSH 讓 Claude Code 管 WordPress 的做法。

這種「哪種工作交給哪個管道」的直覺，很難靠看教學影片累積，多半是像這樣卡過一次、把底層原因挖清楚之後才真的長出來。

延伸思考

這篇文章的結論建立在幾個前提上，值得進一步思考：

• 這是現階段的協定限制，不是永久判決——限制有兩層，「AI 重現 base64 會錯」跟模型版本相關，未來更強的模型可能改善，但「JSON-RPC 沒有二進位型別」是協定層，模型再強也繞不過。官方 Binary Mode 提案（SEP-1306）一旦落地，部分結論就會改寫。
• 有伺服器端能力才走得通——三個解法都假設你有 execute_php、SSH 或能讓伺服器抓網址。託管型 WordPress 沒有 SSH，選項會縮減，這時得回頭想別的路。

其他領域也有一樣的現象：

• 控制訊號 vs 電力線——AI 是控制系統，負責下指令、做決策，不是輸電線。工廠不會拿 PLC 的訊號線去送主電流，MCP 也不該拿來送檔案本體。
• 值傳遞 vs 參照傳遞——傳「檔案在哪」（URL、handle）而不是「檔案本身」（inline base64），是計算機科學處理大資料的老招，換個場景一樣管用。

關鍵概念：AI 代理介面選擇框架、MCP 外部工具整合、適切技術

常見問題

MCP 到底能不能上傳檔案？

現階段不建議。MCP 底層是 JSON-RPC，沒有二進位型別，檔案只能編成 base64 字串傳，而 AI 逐字重現這串長字元極容易出錯，導致檔案損壞。小檔案偶爾會成功，但不可靠。要傳檔案，讓伺服器自己抓公開網址、用 SFTP 上傳、或在伺服器端用程式處理，都比硬塞給 MCP 穩。

為什麼小圖片有時傳得成功、大圖片一定失敗？

因為 base64 字元數跟檔案大小成正比。大檔案編出來動輒好幾萬字元，AI 逐 token 重寫時中途就會斷掉或出錯；小檔案字元少，僥倖全對的機率高一些，但即使長度湊對了，只要有一個字元錯位，MD5 校驗就過不了，檔案照樣是壞的。

base64 為什麼特別容易被 AI 弄壞？

因為 base64 是高亂度、沒有語意規律的字串，而語言模型是靠語意預測下一個字。要它零容錯地逐字重現一段亂碼，等於逼它做最不擅長的事。加上 base64 容錯率是零，錯一個字元整個檔案就毀，不像文字錯字還能被理解。

那 WordPress 網站要導入 AI 自動化，界線該怎麼分？

原則是：結構化、能用 JSON 表達的資料操作（發文、改設定、查訂單）交給 MCP；檔案與主機層操作（上傳媒體、搬檔、備份）走 SSH 加 WP-CLI 或伺服器端腳本。讓 AI 負責決策與下指令，別讓它搬運位元組，是最省事也最穩的分法。

---

要把 AI 自動化導入 WordPress，又不想踩到這類工具邊界的坑？歡迎聯絡我們，或加入我們的 LINE 官方帳號聊聊你的專案。