MCP 和 Extensions

MCP（Model Context Protocol，模型上下文協議）和 Extensions 解決的是同一個方向的問題：讓 Gemini CLI 不只看本地檔案，而是能接入外部工具和能力。

MCP 是什麼

MCP 可以理解為 AI agent 和外部系統之間的標準工具協議。一個 MCP server 可以暴露工具、資源或 prompt，讓 Gemini CLI 呼叫。

典型場景：

• 查資料庫。
• 讀內部知識庫。
• 調 GitHub、Slack、Notion、Linear。
• 調瀏覽器自動化。
• 接公司自研服務。

Extensions 是什麼

Extensions 更像 Gemini CLI 的能力包，可以帶來配置、命令、工具、hooks 或文件。它適合把一組長期複用的能力打包分發。

可以這樣區分：

MCP          连接外部运行服务
Extension    打包 Gemini CLI 的本地能力和配置
Skill        让 agent 针对特定任务加载专门工作流

什麼時候用 MCP

當任務需要即時訪問外部系統時，用 MCP 更自然：

• 需要讀 GitHub issue。
• 需要查詢資料庫。
• 需要呼叫瀏覽器。
• 需要訪問內部 API。
• 需要把結果寫回第三方平臺。

如果只是固定規則或固定流程，先考慮 GEMINI.md 或 Skill，不要為了顯得高階強行上 MCP。

安全邊界

MCP server 的風險取決於它暴露什麼能力：

• 只讀資源風險低。
• 寫入工具風險中。
• 能刪資料、發訊息、釋出、付款的工具風險高。

生產環境裡，MCP 工具應該有明確 allowlist、日誌、許可權隔離和人工確認策略。

接入前的三問

1. 這個 MCP server 暴露的是隻讀能力還是寫入能力。
2. 憑據放在哪裡，日誌會不會列印 token 或內部資料。
3. 呼叫失敗時，Gemini CLI 是重試、降級、還是交給人工處理。

如果這三問沒有答案，就先不要把它接到真實專案。

最小接入思路

先接只读 MCP -> 跑低风险查询 -> 确认返回格式 -> 加写入工具 -> 加审计和人工确认

不要第一天就把所有系統都接進去。

什麼時候不用 MCP

這些情況通常先不用 MCP：

• 只是固定專案規則，用 GEMINI.md。
• 只是固定工作流，用 Skill 或 custom command。
• 只是本地命令，用 shell tool 或 script。
• 只是靜態資料，用文件或資原始檔。

MCP 應該服務於即時系統連線，不應該變成所有流程的萬能入口。

上線前驗收

MCP 接入前先驗收只讀 resource，再驗收低風險 tool，最後才開放寫操作。Extension 安裝前先看 manifest、commands、MCP 配置、hooks 和指令碼。兩者都不能繞過憑據管理和日誌審計。

如果只是教程內容，不需要即時系統，優先使用官方連結、靜態文件和可複核來源，不要為了“更自動”額外接 MCP。

配置落地提示

MCP server 通常放在 settings.json 的 mcpServers 中，可能使用 command、url 或 httpUrl 這類 transport。憑據應該透過環境變數或系統憑據管理傳入，不要寫進教程或儲存庫。

Extension 則至少要看 gemini-extension.json、commands、context file、MCP 配置和 excludeTools。安裝前先讀這些檔案，確認它沒有偷偷擴大工具許可權。

兩者都要有停用路徑。不能關閉的外部能力，不適合放進團隊預設配置。

資料型任務的替代方案

教程寫作、官方資料核驗、版本對比這類任務，不一定需要 MCP。用 Firecrawl 或官方網頁抓取事實，再把來源寫進文件，往往比接一個長期 MCP server 更簡單、更可審計。

MCP 適合需要頻繁讀寫外部系統的長期工作流，不適合一次性資料採集。

一次性官方資料採集還要保留抓取時間、來源 URL 和引用頁面。這樣後續內容過期時，只需要回到同一批來源複核，不必先排查某個長期 MCP server 是否還線上。

官方資料

• MCP servers：docs/tools/mcp-server.md
• Extensions：docs/extensions/index.md
• MCP 協議規範：modelcontextprotocol.io
• Settings（mcpServers 配置）：docs/cli/settings.md

下一篇