MCP resources

MCP 不只提供工具，也可以提供 resources。resources 更像“外部系統暴露出來的上下文材料”，工具更像“可以執行的動作”。

Gemini CLI 有兩個相關工具：list_mcp_resources 負責發現已連線 MCP server 暴露了哪些資源；read_mcp_resource 負責按 URI 讀取某個資源內容。它們都是隻讀能力，不需要確認。

官方引數很簡單：list_mcp_resources 可以用 serverName 過濾某個 server，read_mcp_resource 需要傳入具體 uri。列表結果通常會整理成 URI 和描述；讀取結果會按文本或二進位制處理，二進位制內容可能只返回型別佔位。

resources 適合什麼

• 文件片段。
• 資料庫 schema。
• 專案狀態。
• 服務元資訊。
• 只讀上下文。

和工具的區別

Resources 的價值在於“先理解，再行動”。例如資料庫 MCP server 可以先暴露 schema resource，讓 Gemini CLI 讀取表結構；只有當你確認理解正確後，再開放寫查詢或遷移工具。

使用流程

1. 用 list_mcp_resources 看有哪些 server 和 URI。
2. 選擇一個 resource URI，用 read_mcp_resource 讀取內容。
3. 讓 Gemini CLI 基於 resource 解釋外部系統狀態。
4. 如果需要執行動作，再單獨決定是否允許 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-flow

URI 穩定後，教程和 custom command 才能可靠引用它。否則每次資源名變化，agent 需要重新發現，自動化也會變脆。

不要把資源 URI 設計成含 token、時間戳或本機絕對路徑的字串。憑據應該走 MCP server 的環境變數或認證層，資源 URI 只表達資源身份。這樣教程、指令碼和審計日誌都更容易複核。

驗收方式

連線 MCP 後，不要直接讓 agent 執行工具。先列 resources，讀取一個已知資源，確認返回內容、URI、server 名稱和描述都正確。這樣能先驗證上下文鏈路，再驗證動作鏈路。

接下來去哪

官方來源

• Google Developers Gemini CLI
• Gemini CLI GitHub