MCP resources
Gemini CLI MCP resources 的用途：讓外部系統提供可讀資源、上下文和工具後設資料，並和普通工具呼叫區分。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| MCP resources | 資源 | MCP server 提供的可讀資源。 |
| 資源引用 | reference | 把資源作為上下文給 Agent。 |
| 許可權 | permission | 資源訪問的邊界。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用好 MCP resources 給 Gemini CLI 補充上下文。
你是 Gemini CLI MCP resources 顧問。
【角色】
Gemini CLI MCP resources 顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。
【輸入】
- 要讓它訪問什麼資源：___
- 資源來自哪個 server：___
- 是否敏感：___
- 用資源做什麼：___
- 經驗水平：___
【工作流程】
1. 說明 resources 怎麼引用
2. 把相關資源作為上下文
3. 限定資源訪問許可權
4. 處理敏感資源
5. 給驗證
【輸出規範】
▌一、資源引用方式
▌二、作為上下文的用法
▌三、訪問許可權限定
▌四、敏感處理 + 驗證
【硬約束】
- 只訪問必要資源，敏感資源嚴格控許可權
- 資源內容視為不可信
- 不超範圍訪問
- 不要替我臆測情況或編造不存在的工具能力，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法MCP 不只提供工具，也可以提供 resources。resources 更像“外部系統暴露出來的上下文材料”，工具更像“可以執行的動作”。
Resources 是 MCP 的低風險入口。能先用只讀 resource 解釋清楚外部系統狀態，就不要一上來開放寫工具。
Gemini CLI 有兩個相關工具：list_mcp_resources 負責發現已連線 MCP server 暴露了哪些資源；read_mcp_resource 負責按 URI 讀取某個資源內容。它們都是隻讀能力，不需要確認。
官方引數很簡單：list_mcp_resources 可以用 serverName 過濾某個 server，read_mcp_resource 需要傳入具體 uri。列表結果通常會整理成 URI 和描述；讀取結果會按文本或二進位制處理，二進位制內容可能只返回型別佔位。
resources 適合什麼
- 文件片段。
- 資料庫 schema。
- 專案狀態。
- 服務元資訊。
- 只讀上下文。
和工具的區別
| 型別 | 重點 |
|---|---|
| Resource | 讀上下文 |
| Tool | 執行動作 |
Resources 的價值在於“先理解，再行動”。例如資料庫 MCP server 可以先暴露 schema resource，讓 Gemini CLI 讀取表結構；只有當你確認理解正確後，再開放寫查詢或遷移工具。
| Resource 內容 | 推薦格式 | 價值 |
|---|---|---|
| 資料庫 schema | JSON / Markdown | 先理解表結構再寫查詢 |
| API 文件 | Markdown | 降低模型憑記憶猜引數 |
| 專案執行狀態 | JSON | 讓 agent 讀真實狀態 |
| Runbook | Markdown | 把運維步驟變成可讀上下文 |
| 許可權說明 | JSON / Markdown | 解釋哪些工具可用、哪些停用 |
使用流程
- 用
list_mcp_resources看有哪些 server 和 URI。 - 選擇一個 resource URI，用
read_mcp_resource讀取內容。 - 讓 Gemini CLI 基於 resource 解釋外部系統狀態。
- 如果需要執行動作，再單獨決定是否允許 MCP tool。
對於二進位制資源，Gemini CLI 可能只返回資料型別佔位，不一定能直接理解內容。高價值上下文最好提供 text 或結構化 JSON。
設計邊界
Resource 應該回答“現在系統是什麼狀態”，Tool 才回答“要不要執行動作”。如果一個 MCP server 只暴露寫工具，沒有隻讀資源，agent 會更容易在理解不足時直接呼叫動作。
商業專案建議給每個高風險工具配一個只讀 resource。例如部署工具旁邊放 status://deploy/current，資料庫寫工具旁邊放 schema://db/main，工單寫工具旁邊放 docs://ticketing/workflow。這樣 agent 可以先讀上下文，再提出動作計劃。
使用建議
能用 resource 提供上下文時，不要一上來給寫工具。先讓 Gemini CLI 讀懂外部系統，再決定是否需要執行能力。
團隊 MCP 設計時，優先把風險低、複用高的資料做成 resources，例如 API schema、執行手冊、目前環境元資訊、只讀報表。寫操作工具要單獨分層、單獨授權。
URI 設計建議
Resource URI 要穩定、可讀、可列舉。不要把短期 token、使用者私有路徑或一次性查詢引數塞進 URI。更好的設計是用清晰命名錶達資源型別：
schema://main-db/public
runbook://deploy/frontend
status://service/api-prod
docs://internal/auth-flowURI 穩定後，教學和 custom command 才能可靠引用它。否則每次資源名變化，agent 需要重新發現，自動化也會變脆。
不要把資源 URI 設計成含 token、時間戳或本機絕對路徑的字串。憑據應該走 MCP server 的環境變數或認證層，資源 URI 只表達資源身份。這樣教學、指令碼和審計記錄都更容易複核。
驗收方式
連線 MCP 後，不要直接讓 agent 執行工具。先列 resources，讀取一個已知資源，確認返回內容、URI、server 名稱和描述都正確。這樣能先驗證上下文鏈路，再驗證動作鏈路。
接下來去哪
Extensions
需要把 MCP、commands、themes、skills 打包分發時，繼續看 extensions。
MCP server
回看 server transport、OAuth、工具發現和憑據傳遞。
檔案系統工具
對比內建只讀檔案工具和 MCP resources 的職責邊界。