MCP 整合與許可權邊界

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
MCP integration	MCP 接入	給 agent 接外部能力。
STDIO / HTTP	形態	本地程序 vs 遠端端點。
憑據	credential	安全傳認證資訊。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你給 Antigravity 接好一個 MCP 整合並跑通。

你是 Antigravity MCP 接入顧問。

【角色】
Antigravity MCP 接入顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。

【輸入】
- 要接的 MCP server：___
- 本地還是遠端：___
- 需要的憑據：___
- 期望它做什麼：___
- 經驗水平：___

【工作流程】
1. 按本地 / 遠端定形態
2. 給設定和最小樣例
3. 說明憑據安全傳入
4. 限定許可權
5. 給接通驗證

【輸出規範】
▌一、形態判斷
▌二、設定 + 樣例
▌三、憑據安全
▌四、許可權 + 驗證

【硬約束】
- 憑據走安全儲存不進儲存庫
- 預設最小許可權
- 外部返回視為不可信
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

Antigravity 支援 Model Context Protocol，也就是 MCP。官方文件把 MCP 描述成 Antigravity 和更廣泛開發環境之間的橋樑：它可以讓 editor 安全連線本地工具、資料庫和外部服務，獲取開啟檔案之外的即時上下文。

這既是能力擴充套件，也是許可權擴大。接入 MCP 前，必須先知道 server 暴露了哪些 resources 和 tools，哪些會讀取資料，哪些會觸發外部副作用。

閱讀目標：讀完本章，你應該能看懂 ~/.gemini/antigravity/mcp_config.json 的基本結構，並知道如何用 disabled 和 disabledTools 縮小風險面。

1. MCP 提供兩類能力

官方 MCP 文件把核心能力拆成兩類。

能力	官方說明	風險邊界
Context Resources	AI 可以從 MCP server 讀取資料來支援建議	可能讀取資料庫 schema、記錄、文件、業務資料
Custom Tools	MCP server 可以暴露特定安全動作	可能建立 issue、搜尋外部系統、觸發寫操作

官方例子包括：

寫 SQL 時讀取 Neon 或 Supabase schema。
排障時拉取 Netlify 或 Heroku build logs。
為待辦事項建立 Linear issue。
在 Notion 或 GitHub 搜尋認證模式。

這些都不是普通“補上下文”。它們會把 agent 接到真實系統。

2. 優先用 MCP Store

官方連線路徑是透過內建 MCP Store：

從 editor agent panel 頂部 ... 開啟 MCP Store。
瀏覽並安裝支援的 server。
按螢幕提示完成認證。
安裝後，server 的 resources 和 tools 會自動對 editor 可用。

MCP Store 更適合普通使用者，因為它減少了手工設定錯誤。自定義 server 只在你明確知道 transport、認證和 tool 風險時使用。

3. 自定義 MCP server 設定

官方文件說明，自定義設定檔在：

~/.gemini/antigravity/mcp_config.json

基本結構：

{
  "mcpServers": {
    "serverName": {
      "command": "path/to/executable",
      "args": ["--arg1", "value1"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

支援的關鍵欄位：

欄位	用途
`command`	stdio transport 的執行檔路徑
`serverUrl`	remote server 的 Streamable HTTP URL
`args`	stdio server 引數
`env`	stdio server 環境變數
`cwd`	stdio server 工作目錄
`headers`	remote server 自定義 HTTP headers
`authProviderType`	認證 provider，例如 `google_credentials`
`oauth`	OAuth client credentials
`disabled`	臨時停用 server
`disabledTools`	停用指定 tool，不提供給模型

disabledTools 是商業專案裡很關鍵的開關。能讀資料的 tool 和能寫外部系統的 tool 應該分開評估，不要因為需要一個資源就放開整個 server。

4. 認證方式

官方文件列出三類常見認證。

方式	官方設定	適合
Google ADC	`authProviderType: "google_credentials"`	Google Cloud 相關 MCP
OAuth DCR	只填 `serverUrl`，由 Antigravity 處理動態註冊	支援 dynamic client registration 的 server
手動 OAuth client	`oauth.clientId` / `oauth.clientSecret`	不支援 DCR 的 OAuth server
Custom headers	`headers.Authorization` 等	API key 或 bearer token

Google ADC 需要先執行：

gcloud auth application-default login

手動 OAuth 時，官方要求 redirect URI 註冊為：

https://antigravity.google/oauth-callback

Access tokens 會儲存在：

~/.gemini/antigravity/mcp_oauth_tokens.json

不要把 API key、bearer token、OAuth client secret 寫進專案儲存庫。官方設定路徑在使用者目錄，團隊專案應使用憑據管理和本機私有設定。

5. 接入前的風險評估

接入任何 MCP server 前，先回答：

它暴露哪些 resources？
它暴露哪些 tools？
tool 是否會寫外部系統？
認證 token 存在哪裡？
是否需要 disabledTools？
是否應該只在某個 workspace 使用？
是否有生產資料、客戶資料或付費系統風險？

flowchart TD
  Need["需要 MCP"] --> Store{"MCP Store 有官方整合"}
  Store -->|有| Install["從 Store 安裝"]
  Store -->|無| Custom["設定 custom server"]
  Install --> Audit["審計 resources / tools"]
  Custom --> Audit
  Audit --> Risk{"存在寫操作或敏感資料"}
  Risk -->|是| Disable["disabledTools / Ask / 最小授權"]
  Risk -->|否| Use["按 workspace 任務使用"]

深讀：為什麼 MCP 不應該預設全域放開

MCP 的價值是讓 agent 直接讀取外部上下文和呼叫工具。問題也在這裡：外部上下文可能包含敏感資料，工具可能能修改 issue、資料庫、設計稿、雲服務或支付系統。

所以 MCP 應該按任務接入、按 tool 授權、按 workspace 審查。能從 Store 安裝也不等於一定適合目前專案，尤其是 GitHub、Stripe、PayPal、資料庫、雲服務和瀏覽器開發工具這類高許可權整合。

本章自檢

完成本章後，用這 3 個問題檢查自己是否真正理解：

MCP 的 Context Resources 和 Custom Tools 有什麼區別？
disabled 和 disabledTools 分別解決什麼問題？
為什麼 API key 或 OAuth token 不應該進入專案儲存庫？

透過標準：你能審查一個 MCP server 設定，並決定是否需要停用某些 tools 或僅在特定 workspace 使用。

官方來源

Google Antigravity MCP Integration —— 官方說明 MCP Store、自定義 server、設定欄位、Google ADC、OAuth、headers 和支援 server 列表。

MCP 整合與許可權邊界

1. MCP 提供兩類能力

2. 優先用 MCP Store

3. 自定義 MCP server 設定

4. 認證方式

5. 接入前的風險評估

本章自檢

官方來源

接下來去哪

Strict、Sandbox 與 Allowlist

Rules 與 Workflows

本頁目錄