使用说明
Python MCP Server
🚀 Python MCP Server 的連線方式
本專案示範 三種連線模式實作 Python MCP Server:
- STDIO: stdio-mode
- SSE: sse-mode
- Streamable HTTP: streamable-http-mode
🔍 三種連線模式比較
| 模式 | 傳輸方式 | 是否持續連線 | 資料輸出型態 | 適合場景 | 優勢 | 缺點 |
|---|---|---|---|---|---|---|
| STDIO | 標準輸入輸出 (stdin/stdout) | ❌ 無 | 一次性送出 | CLI 工具、local MCP server、原型開發 | 實作簡單、延遲低、不需 HTTP 伺服器 | 難支援串流回應 & 多用戶、無法跨網路 |
| SSE (Server-Sent Events) | HTTP /text/event-stream | ✔️ 單向持續 | 伺服器 ➜ 客戶端的訊息流 | Web UI 顯示 AI Token-by-token 回應 | 成熟瀏覽器支援、輕量、易實作串流 | 只能單向(無法雙向)、不支援 binary |
| Streamable HTTP | HTTP 雙向 / Chunked / Duplex | ✔️ 可雙向 | Chunk 形式傳輸 | AI 聊天、MCP 工具呼叫、多人協作 | 支援雙向串流、自然適合工具溝通 | 實作較複雜、需伺服器與框架支援 |
🔮 未來主流:為何推薦 Streamable HTTP?
Streamable HTTP 結合 SSE 的輕量 與 WebSocket 的雙向能力,特別適合 AI / MCP 的互動模式:
- ✔ 需要時才啟動串流,避免 SSE 長時間佔用連線資源
- ✔ 支援雙向傳輸,符合「AI ↔ Tool ↔ MCP」的交互流程
- ✔ 適合生成長文本、程式碼、推理過程等 AI Streaming Response
- ✔ 自然對應 MCP 的典型「多階段交流模型」:
User → AI → Tool → AI → Response
因此,隨著 AI 工具的複雜度提升,Streamable HTTP 更適合未來 MCP Server 的主流開發方式。
Remote MCP Architecture
---
config:
theme: base
---
flowchart LR
subgraph L["Local Computer"]
U["Browser"]
end
subgraph MM["MCP Marketplace"]
M["MCP Tool Server<br>(Cloud Run / GKE)"]
end
subgraph R["Remote Server"]
A["Agent Server<br>(Cloud Run / GKE)"]
MM
IS["Internal Services / Database / MQ"]
IA["Internal APIs"]
end
O["Authorization Server"]
%% Authentication flow
U -- Login → obtain access token --> O
%% User calls Agent Server with token
U -- Request + Access Token<br>(HTTP or WebSocket) --> A
%% Agent Server calls MCP Tool Server
A -- Tool call with access token<br>(SSE、Streamable) --> M
%% MCP Tool Server backend calls
M -- Service Calls --> IS
M -- API Calls --> IA
M@{ shape: procs}
---
config:
theme: base
---
sequenceDiagram
participant U as Browser / User
participant O as Authorization Server
participant A as Agent Server
participant M as MCP Tool Server
participant IS as Internal Services / DB / MQ
participant IA as Internal APIs
%% 使用者登入取得 Access Token
U->>O: Login request
O-->>U: Access token
%% 使用者帶 Access Token 請求 Agent Server
U->>A: Request + Access Token (HTTP / WebSocket)
A-->>A: Verify access token locally
%% Agent Server 呼叫 MCP Tool Server
A->>M: Tool call with access token (SSE / Streamable)
M-->>M: Verify access token locally
alt Access token valid and authorized
M->>IS: Call internal services / DB / MQ
M->>IA: Call internal APIs
M-->>A: Tool execution result
else Access token invalid or unauthorized
M-->>A: 403 Forbidden / error payload
end
%% 回傳結果給使用者
A-->>U: Response with tool result
MCP Marketplace
- 連線方式
- 採用 SSE / Streamable HTTP 與 MCP Tool Server 連接
- 不使用 STDIO 模式(僅適用於 local tool)
- MCP Tool Server 種類:
- 第三方 MCP Server
- 由外部社群或廠商提供
- GCP: https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services
- 自建 MCP Server
- 依業務需求自行開發與維運
- 可整合內部系統與資料來源
- API Proxy MCP Server
- 將既有 REST / RPC API 封裝為 MCP Tool
- 作為 MCP 與既有服務之間的轉接層
- 例如:
- Apigee
- https://cloud.google.com/blog/products/ai-machine-learning/mcp-support-for-apigee
- https://apigee.github.io/apigee-go-gen/
- https://www.youtube.com/watch?v=q9w39U0LVG4
- fastmcp
- https://gofastmcp.com/integrations/openapi
- 其他
- https://github.com/google/mcp-openapi-proxy
- https://github.com/harsha-iiiv/openapi-mcp-generator
- https://github.com/ivo-toby/mcp-openapi-server
- Apigee
- 第三方 MCP Server
MCP 安全性與存取控制
系統安全性
- 採用可信任的 MCP 實作
- 優先使用開源且經過社群或實務驗證的 MCP 專案
- 降低供應鏈攻擊與惡意程式碼注入的風險
- 執行環境隔離
- 建議將 MCP Server 運行於 Sandbox 或受限環境中(如 Container、VM)
- 限制其對主系統、網路與檔案系統的存取權限
存取控制
- 身分驗證(Authentication)
- MCP Server 應具備明確的身分驗證機制
- 可參考官方文件實作標準化驗證流程: https://google.github.io/adk-docs/tools-custom/authentication/
- Tool 使用授權(Tool-level Authorization)
- 控制 Agent 是否可存取特定 MCP Tool
- 可依角色、租戶(Tenant)或用途進行限制
- Tool 內部資料授權(Data-level Authorization)
- 即使 Tool 已通過存取授權,仍需在 Tool 內部實作資料層級的權限控管
- 確保僅能存取被授權的資源與資料範圍
