你手上有一支內部 API。OpenAPI 規格早就寫好了，Swagger UI 打開，同事可以在上面點來點去、帶 token 試打。現在主管要讓 agent 也能用它。

照現在常見的做法，下一步是寫一個 MCP server：把每個 endpoint 包成一個 tool，參數對一次，回傳對一次，然後找地方部署它、監控它、跟著 API 升版。API 哪天多一個欄位，要改的地方從一處變成兩處。

做到一半會發現，這台 server 寫的程式碼，大部分只是在轉手。agent 把參數交給它，它把參數交給 API，API 的回應再原路送回去。它沒有替這支 API 增加任何能力，只是讓 agent 看得懂怎麼用。

複雜度通常是某個妥協留下的。這台 server 的妥協是：agent 不會讀你的 API 說明，所以得有人站在中間，用它聽得懂的協定翻譯一遍。

UTCP（Universal Tool Calling Protocol）問的就是，那個人一定得站在那裡嗎？它的文件首頁有一句話講得很白：

“If a human can call your API, an AI agent should be able to call it too - with the same security and no additional infrastructure.“

把翻譯的人換成一本說明書

家裡新買的洗衣機，你不會請一位專人站在旁邊替你按按鈕。你看說明書，自己按。

UTCP 的核心就是這本說明書，它叫 manual。manual 是一份 JSON 文件，描述某個工具要怎麼被呼叫。格式的精神接近 OpenAPI，另外替 agent 加了幾個欄位，例如 tags、average_response_size，也支援 HTTP 以外的協定。agent 讀完 manual，直接對目標端點發出呼叫，端點可以是 HTTP、CLI、WebSocket、gRPC。中間沒有常駐的協定伺服器。

官方有一份跟 MCP 正面比較的文件 docs/utcp-vs-mcp.md，裡面把兩邊的流程各寫成一行：

1
2
UTCP:  Agent discovers manual → Agent calls tool directly
MCP:   Agent → MCP Server → Tool → MCP Server → Agent

同一份文件的比較表，基礎設施需求那一欄，UTCP 寫 “None required”，MCP 寫 “Wrapper servers needed”。

回到開頭那支 API。它的 OpenAPI 規格本來就在那裡，UTCP 文件寫明既有的 OpenAPI 規格可以自動轉成 manual，原話是 “without requiring API changes or additional infrastructure”。照這個說法，那台只會轉手的 server，可以整台不用寫。

它沒有跟 MCP 翻臉

讀到這裡，很容易以為 UTCP 是來取代 MCP 的。看它 1.0 的套件怎麼拆，就知道沒這回事。

UTCP 1.0 把架構拆成「核心套件＋協定 plugin」，每一種呼叫方式各是一個獨立的 plugin，其中一個叫 utcp-mcp。裝了它，既有的 MCP server 就變成 UTCP client 可以呼叫的其中一種對象，跟 HTTP、CLI 並排。

它的意思比較像：本來就有 API 的工具直接打，已經寫成 MCP server 的，也照樣收進來用。你不用先選邊，也不用把手上的 MCP server 丟掉。

省下來的那台 server，麻煩搬去哪了

這一段是我讀這個專案最意外的地方，因為答案是它自己寫的。

中間人拿掉之後，原本中間人要扛的事並不會消失。官方的 docs/security.md 先列優點，”No middleman to compromise”、”Reduced attack surface (no proxy servers)”，接著在 Considerations 底下，把代價也列出來了：

官方 docs/security.md 自己承認的三個取捨：

  • “Clients must handle multiple authentication methods”
  • “Manual endpoints become discovery targets”
  • “Variable substitution introduces injection risks”

官方只列了這三句，沒有展開。下面是我照字面的讀法。

第一條，認證。以前 MCP server 替你面對後端，後端要 API key、OAuth 還是 basic auth，是那台 server 的事，agent 這一側只要會跟 MCP server 說話。現在 agent 直接打每一個工具，每個工具的認證方式各不相同，client 得全部都會。

第二條，manual 本身變成目標。manual 放在一個讓 agent 找得到的端點上，攻擊者也找得到。它描述的是「這個工具能做什麼、要怎麼呼叫」，改掉這份描述，就等於改掉 agent 對這個工具的認知。再往下推一步（這段官方沒寫）：這個風險跟協定走直連還是走中間人無關，只要工具的能力描述開放給呼叫方去發現，這份描述就會變成有人想竄改的東西。MCP 的工具描述也有同一個問題。

第三條最值得寫程式的人注意。manual 裡的呼叫範本會有變數，執行時才把實際的值代進去。只要是「把外部來的字串代進一個會被執行的範本」，就有注入的空間。呼叫的是 CLI 的時候，這件事的下場尤其難看。

這三條擺在一起看，UTCP 拿掉的那台 server，工作其實是移到 client 端了。server 端的維運省了下來，client 端要會的東西變多。對「API 已經有、認證方式單純、呼叫方就是自己團隊」的場景，這筆交換很划算。工具來自四面八方、認證五花八門，那台被省掉的 server 原本替你擋掉的東西，現在要自己擋。

一個會讓範例程式碼跑不動的改名

我只讀了規格文件和 python-utcp 的 README，沒有實際裝起來跑過。但 README 裡有一件事，照著網路上的教學做之前一定要先知道。

UTCP 1.0 是一次破壞性改版。舊版的術語 provider、provider_type，全面改名成 call_template、call_template_type。工具名稱也改成強制帶上來源的命名空間，格式是 manual_name.tool_name，這部分 client 會自動處理。安裝方式跟著變了，pip install utcp 只裝核心，要打哪種端點得另外裝對應的 plugin：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 核心
pip install utcp

# README 標示為 Stable 的協定 plugin，依需要擇一或多個
pip install utcp-http
pip install utcp-cli
pip install utcp-websocket
pip install utcp-text
pip install utcp-mcp

# 0.x → 1.0 的改名
# provider       → call_template
# provider_type  → call_template_type
# 工具名稱       → manual_name.tool_name

utcp-socket 和 utcp-gql 在 README 上還標著 In Progress。

實際的意思是：你搜到的 UTCP 範例，只要還在寫 provider_type，就是 0.x 時代的東西，照抄不會動。官方有寫一份 0.x 到 1.0 的 migration guide，看到舊術語直接跳過那篇教學，回去讀 README 比較快。

這個專案現在長什麼樣

數字上看得出它還在持續更新。這是 2026 年 9 月 29 日用 GitHub API 和 PyPI 查的資料：

python-utcp utcp-specification（規格庫）
授權（GitHub 偵測） MPL-2.0 NOASSERTION
建立日期 2025 年 6 月 24 日 2025 年 7 月 2 日
星數 652 313
最後一次 push 2026 年 9 月 16 日 2026 年 9 月 16 日

PyPI 上的 utcp 最新版是 1.2.0，發布時間也是 9 月 16 日，跟兩個 repo 的 push 同一天。組織底下有 23 個公開 repo，除了 Python，也看得到 TypeScript、Go、Rust 等語言的 SDK repo（這份語言清單是從 repo 名稱判讀的，不是官方列出的）。從組織建立到查詢當天，大約一年三個月。

另外兩件事比星數更能說明它的位置。

表裡規格庫那格 NOASSERTION，意思不是「沒有授權」，是 GitHub 認不出一份標準的授權條款。程式碼庫明確選了 MPL-2.0，規格庫那邊到底有沒有放授權條款、放的是什麼，我沒進一步查。一份想讓大家照著實作的規格，文字本身用什麼條件授權，是採用前會被法務問到的問題。

python-utcp 的 README 上掛著一枚「CDTM S23」的徽章，連到慕尼黑的 CDTM（Center for Digital Technology and Management）。這表示核心維護方帶有學生新創的背景，背後不是大型科技公司，也不是標準組織。CDTM S23 那一梯的細節我沒查。

沒查的東西也要講清楚。有哪些公司或專案在生產環境用 UTCP，官方有一頁 docs/showcase.md，我沒有讀它的內容，手上沒有這份名單。PyPI 下載量，README 有徽章，數字沒抓。MCP 的維護方有沒有公開回應過 UTCP，我只讀了 UTCP 這一方的文件，不知道。

回到那支內部 API

開頭那支 API 如果今天交到我手上，正式環境要接的工具，我照舊走 MCP。另外拿那份現成的 OpenAPI 規格轉一份 manual，在自己的機器上讓 agent 直接打一次，看轉出來的 manual 長什麼樣、認證要自己處理多少。再把 docs/security.md 那三條逐一對照這支 API 走一遍，特別是呼叫範本裡的變數，會代進哪裡。

兩條路並行，是因為我對 UTCP 的判斷分成兩半。一半是它對「工具本來就有 API」這件事看得對。多數內部 API 不需要一台專門的 server 來轉手，那台 server 存在，只是因為 agent 以前不會讀 API 說明。manual 把這件事補上了，還願意把 MCP 收進來，不逼人選邊。這個設計我認同。

另一半是那幾個還空著的欄位：生產環境的採用名單我手上沒有，規格庫的授權連 GitHub 都認不出來，維護方的背書也還小。規格庫哪天換上 GitHub 認得出來的標準條款，showcase 裡也出現能公開查證、在生產環境使用的案例，兩件事都到位，我才會把正式環境的工具呼叫壓到它上面。

那台只會轉手的 server，也許真的可以不用寫。先確認它原本替你擋掉的東西，你接得住。

參考來源