編譯摘要：MCP 二進位檔案限制

第一步：濃縮

核心結論 1：MCP 搬不動二進位檔案，這是協定層的物理限制，不是設定問題。

• MCP 底層走 JSON-RPC，JSON 沒有二進位型別、沒有檔案 handle、沒有 multipart 上傳，檔案只能編成 base64 塞進字串參數。
• MCP 採同步請求模型，一個回合要吐完結果，不適合大檔案這種需要背景執行、分段串流的長時間任務。
• 官方 Binary Mode 提案（SEP-1306）到本案處理時仍停在 draft，是現階段限制而非永久判決。

核心結論 2：base64 交給 AI 必定出錯，因為 AI 是逐 token 重新生成而非複製，且 base64 零容錯。

• 39KB 的 JPEG 編成 base64 是 52,484 個字元，AI 寫到第 6,531 字就崩潰。
• 6KB 的 PNG 編成 8,084 字元，長度對了但 MD5 校驗失敗，檔案仍是壞的。
• 高亂度、無語意規律的長字串做「零容錯逐字重現」，正好是語言模型最不擅長的任務；base64 錯一個字元整個檔案就毀。

核心結論 3：解法是讓 AI 下指令，位元組走另一條不經過 AI 的管道。

• 三種 WordPress 解法：檔案有公開網址就讓伺服器 wp_remote_get 自己抓、本機檔案用 SFTP 上傳、要落地處理用 execute_php 在伺服器端一次做完。
• 分工原則：結構化資料操作交給 MCP，檔案與系統層操作走 SSH + WP-CLI 或伺服器端腳本。
• 補上 [[AI 代理介面選擇框架]] 缺的第四條軸：資料型別。

第二步：質疑

前提假設：

1. 模型當前能力。「AI 無法重現 base64」與模型版本相關，未來更強的模型或許能寫更長，但 JSON 無二進位型別是協定層限制，模型再強也繞不過——這條的「協定」部分永遠成立，「AI 重現」部分會隨模型弱化。
2. 現階段協定。SEP-1306 Binary Mode 若正式落地，「必壞」的部分結論會失效，這是明確的時間邊界。
3. 檔案大小。極小檔案偶爾僥倖成功，「必壞」在大檔案才絕對，小檔案是機率問題。
4. 伺服器端能力。三個解法假設有 execute_php、SSH 或 wp_remote_get 可用；託管型 WordPress（WordPress.com）沒有 SSH，解法選項會縮減。

換情境還成立嗎：

• 換平台（非 WordPress 的一般 SaaS）：wp_remote_get／execute_php 不適用，但「公開網址讓伺服器抓、走專用傳輸工具、AI 只下指令」的原則不變。
• 換資料型別（純文字、結構化 JSON）：整個限制消失，MCP 完全勝任——這反而證明界線就在「資料型別」這條軸。
• 換模型／未來協定：base64 重現困難可能被 binary mode 繞過，但同步請求模型不適合大檔案串流的限制仍在。

反例與邊界條件：

• 有些 MCP 實作把檔案存在 server 端、只在參數裡傳 reference／URL，AI 完全不碰 base64。這其實就是解法一的內建版本，反過來證明「別讓位元組經過 AI」是通則。

第三步：對標

跨域類比：

• 控制訊號 vs 電力線——AI 是控制系統（下指令、做決策），不是輸電線（搬運能量／位元組）。工廠不會拿 PLC 的訊號線去送主電流，MCP 也不該拿來送檔案本體。
• 服務生點餐 vs 送菜——服務生（AI）記單、下單、協調流程，但一大鍋湯不會端在他的記事本上（base64 塞進 JSON），重物走專門的送餐推車（SFTP／伺服器抓取）。
• 值傳遞 vs 參照傳遞——傳 reference（URL／handle）而非 inline blob，是計算機科學處理大資料的老招。MCP 的正解是傳「檔案在哪」，不是傳「檔案本身」。

知識庫定位： 既有 [[AI 代理介面選擇框架]] 的三條軸（自主程度、信任邊界、可觀測性）都在「權限與風險」層面回答「該不該讓 AI 做」。本文補上第四條軸「資料型別」，回答的是更前面的問題：這件事 AI 在物理上做不做得到。有些工作不是信任與否，是那串位元組根本擠不進 JSON。