建立 Hugging Face MCP 伺服器

Hugging Face 已推出官方的模型上下文協定（Model Context Protocol，簡稱 MCP）伺服器（hf.co/mcp），讓 AI 助手能與 Hugging Face Hub 互動，並存取 Spaces 上數千個 AI 應用程式。此整合使用戶能即時自訂可用工具，並透過遠端可存取的 URL 簡化連線流程。

技術設計與客製化

Hugging Face MCP 伺服器採動態設計，使用者可透過專屬的 MCP 設定頁面 設定自己的工具。此方式確保伺服器能因應使用者的研究、開發或內容創作需求而調整。為了消除本機下載與設定的複雜性，伺服器以遠端方式託管，AI 用戶端只需透過簡單的 URL 即可存取。

遠端傳輸選項與取捨

在實作遠端 MCP 伺服器時，開發者必須在多種傳輸機制之間做選擇。雖然 Hugging Face 的開源實作支援多種變體，正式環境則採用 Streamable HTTP。

傳輸比較

傳輸方式 使用情境
STDIO 與用戶端在同一機器上執行的本機伺服器；可存取本機檔案。
HTTP with SSE 透過 HTTP 的遠端連線；自 2025 年 3 月 26 日的 MCP 版本起已棄用。
Streamable HTTP 現代且彈性的遠端 HTTP 傳輸，具優越的部署選項。

Streamable HTTP 通訊模式

使用 Streamable HTTP 的開發者可實作三種主要的通訊模式：

  1. 直接回應：標準的請求/回應模式（類似 REST API），適用於無狀態、簡單的操作，如搜尋。
  2. 請求範圍串流：與單一請求綁定的暫時性 SSE 串流，用於進度更新（例如影片生成過程）或伺服器需要向使用者徵求資訊時。
  3. 伺服器推送串流：長期存在的 SSE 連線，允許伺服器主動發送訊息，例如工具或提示清單變更的通知。此類型需要保活與恢復機制。

狀態管理

MCP 伺服器可以設定為 Stateless（無狀態）或 Stateful（有狀態）。無狀態伺服器將每個請求視為獨立，便於水平擴展。有狀態伺服器會回傳 mcp-session-id，並保留用戶端上下文，這對於在請求範圍串流中使用抽樣（Sampling）與徵求（Elicitation）請求等功能是必要的。

正式部署策略

在正式部署時，Hugging Face 採用了 Stateless、Direct Response 的配置，並使用 Streamable HTTP，原因如下：

  • 無狀態：使用者狀態（已選工具、Gradio 應用程式、ZeroGPU 配額）透過 HF_TOKEN 或 OAuth 憑證於每次請求時查詢，無需在請求間維持會話狀態。
  • 直接回應：此方式資源開銷最低，且足以因目前工具組不需要在執行期間進行抽樣或徵求。

實作洞見與用戶端行為

工具清單變更通知

Hugging Face 發現實作即時「工具清單變更」通知（透過 Server Push Streams）會增加過多複雜度。由於許多用戶端在閒置後會斷線，或在未使用時保持連線，讓用戶端在需要時自行重新整理連線與工具清單，比維持成千上萬的開放連線更有效率。

使用者體驗與瀏覽器偵測

為提升使用者體驗，Hugging Face 在 hf.co/mcp 加入了一個友善的說明頁面。但這導致 VSCode 在收到 HTML 頁面而非 HTTP 405 錯誤時，會每秒多次輪詢該端點。團隊透過實作瀏覽器偵測，確保只有真正的瀏覽器會收到 HTML 頁面，以解決此問題。

用戶端流量模式

2025 年 7 月第一週的分析顯示，有 164 個不同的用戶端存取伺服器。團隊觀察到每一次工具呼叫都伴隨約 100 條控制訊息的高比例。大量用戶端使用 mcp-remote 作為橋接，以連接遠端伺服器。

功能與應用案例

透過整合 Hugging Face Hub 與 Gradio Spaces，LLM 可擴充至最新的機器學習應用。目前的使用者實作包括：

  • 影片製作編排
  • 圖片編輯
  • 文件搜尋
  • AI 應用程式開發
  • 為既有模型加入推理能力

Sources