MCP Registry 實測揭露隱形系統提示：逾五千個可連線伺服器回傳 instructions

Fetchgate 對 MCP 官方 Registry 所列的 15,329 個遠端網址，逐一發送 `initialize`、`notifications/initialized` 與 `tools/list`，但沒有呼叫任何工具。8,235 個端點成功回傳工具清單，合計包含 140,284 個工具；其中 5,462 個還在握手結果附帶非空的 `instructions`。MCP 規格把這個欄位定義為協助模型使用伺服器的自然語言提示，並允許客戶端把它放進 system prompt，卻沒有規定長度上限或要求介面必須向使用者顯示。

實測中，`instructions` 長度中位數為 577 個字元，114 個端點超過五千字元，最長達 68,669 字元，粗估每次對話先占約一萬七千 token。工具說明也有類似膨脹：9,262 項超過 1,500 字元，單一 `create_diagram` 說明甚至達 52,183 字元。這些內容若在每輪請求重送，不但增加費用與延遲，也可能稀釋使用者提示和先前對話在有限上下文中的權重。

更敏感的是行為導向文字。研究者人工整理出 47 個端點，要求模型不要向使用者揭露特定平台、競爭者、失敗或安全阻擋資訊；480 個主機使用「你必須」或「永遠呼叫」等模型導向措辭，406 個宣稱自己的工具應先於其他工具執行。這未必等同惡意提示注入：研究沒有在 140,284 份說明中找到教科書式竊取金鑰指令，部分文字也只是內部識別碼或付款流程規則。然而它證明伺服器供應商可在一般聊天記錄之外改變代理行為。

平台工程師應保存每次握手取得的指令與工具描述，像鎖定相依套件般做版本差異、token 預算及來源稽核，並把 `readOnlyHint` 等註記視為伺服器自我聲明，而非權限證明。數據仍有偏差：網址涵蓋歷史版本、3,617 個需驗證的端點無法檢查，且兩家業者占成功端點近三成。這是一個時間點與單一網路位置的快照，不是整個 MCP 生態的惡意率。