從 curl 到 MCP：軟體串接的本質是「誰去讀文件」

「把 A 系統接到 B 系統，要多少錢？」

這是我們最常被問的問題之一。答案的落差可以到十倍，而落差的來源，用一句話就能講清楚：串接的成本，取決於誰去讀文件。

傳統模式：工程師讀文件，寫黏合程式

一次典型的 API 串接分三步。第一步，工程師讀對方的 API 文件——認證方式、端點、欄位、分頁規則、錯誤碼。第二步，用 curl 手動驗證，確認文件跟實際行為一致（經驗上，不一致是常態）：

# 先手動打一次,確認認證與回傳格式
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.example.com/v1/orders?page=2"

第三步，寫黏合程式：把回傳資料轉成自己系統的格式，處理重試、逾時、憑證更新。每接一個新服務，這三步從頭來一次——這就是串接報價的主體。文件寫得爛的服務，第一步和第二步的時間可以翻倍，這也是為什麼報價前我們一定先看文件品質。

而且這筆成本不是一次性的。對方改版、欄位改名、憑證換發，黏合程式就要跟著動——串接專案裡看不見的另一半，是上線之後的維護。

MCP 模式：服務自我描述，模型自己讀

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月開源的協定，它翻轉的正是「誰去讀文件」這件事。服務端把自己的能力寫成工具清單——每個工具有名稱、用途說明、參數格式；AI 模型連上來先問「你會什麼」，再依需求呼叫。文件不再是給工程師讀的 PDF，而是協定的一部分，模型執行時自己讀、自己判斷怎麼用。工具清單還是活的——服務端新增能力，模型下次連上來就看得到，不用等任何人回頭改黏合程式。

對使用端，接一個 MCP 服務從一個專案變成一行指令：

# 以 Claude Code 為例:一行接上一個 MCP server
claude mcp add --transport http some-service https://example.com/mcp

我們自己的實例是把 Search Console 接進 AI 工作流——接上之後，查排名、驗收錄用講的，不用寫程式。

curl 沒有死：它從施工工具變成驗收工具

要說清楚的是，MCP 不是取代 API——它是包在 API 外面的一層自我描述。底層還是 HTTP，所以 curl 依然是驗證的第一工具：我們驗收 MCP server 時，照樣手動發 JSON-RPC 請求，確認工具清單和回傳跟宣告一致。變的是分工：人負責驗證與授權，模型負責讀文件與組裝呼叫。換句話說，三步驟並沒有消失——是第一步和第三步換了執行者，而第二步的把關，仍然是人的責任。

傳統串接賣的是工程師讀文件的時間；MCP 把這段時間移給了模型。

對中小企業的實際意義

• 採購軟體時多問一句：「有沒有 API？有沒有 MCP？」兩個都沒有的封閉系統，未來每一次串接都是客製費用。
• 報價落差有了判斷基準：對方報的是「讀文件加寫黏合程式」的傳統工程，還是站在現成協定上的組裝？前者貴有貴的理由，但你要知道自己買的是哪種。
• 自家資料先整理好：模型再會讀文件，也讀不到你沒寫下、沒結構化的東西——這跟我們在案例研究裡一再強調的數據地基是同一件事。

給技術主管的三個自我檢查

1. 你們現有系統的清單裡，哪些有開放 API？哪些連匯出都做不到？
2. 上一次串接專案的工時，花在讀文件與對格式的比例是多少？
3. 如果明年供應商都出了 MCP，你們的資料準備好被模型讀了嗎？

你描述兩套想接起來的系統，我們告訴你走傳統串接還是等協定，哪條路划算。

預約 30 分鐘免費流程診斷 →