Google Home MCP 怎麼接 agent？先分清 OAuth、工具與權限

先分清楚兩條 MCP 產品路徑#

Google Home 的文件同時介紹 Home MCP 與 Home Developer MCP，但它們處理的資料和授權目的不同：

如果你的目標只是問「某個 API 怎麼用」，不需要先連到使用者的家庭。反過來，如果你要讓 agent 查燈、溫度或感測器狀態，則要明確告知使用者這是一條可以看到家庭資源的 OAuth 連線，不要用 Developer MCP 的設定方式取代它。

Home MCP endpoint 與工具範圍#

官方 Reference 目前列出的 Home MCP endpoint 是：

1
https://home.googleapis.com/mcp

它使用 OAuth 與使用者授權。成功連線後，先按照從觀察到控制的順序理解工具：

工具名稱本身不會替你完成權限設計。list_home_resources 的結果可能暴露裝置名稱、房間配置或家庭成員自行設定的語意；run_home_actions 則是從「讀資料」跨到「改變實體環境」的明顯邊界。

用 read-only 順序驗證連線#

建立 remote MCP connector 時，不要把整個家庭當成一個不可分割的測試目標。建議先做一個最小 smoke test：

1. 核對 endpoint：確認 client 連到 https://home.googleapis.com/mcp，OAuth 同意畫面屬於 Google，並且登入的是預期帳號。
2. 選定家庭：呼叫 list_homes 後，只選擇這次任務需要的家庭；不要讓 agent 自己在多個家庭中猜測。
3. 縮小資源：用 list_home_resources 找到一個測試用裝置，保存必要的 resource id，但不要把整份家庭圖譜送進一般分析資料庫。
4. 只讀取狀態：用 list_home_states 和必要的 list_home_history 驗證名稱、狀態和時間是否符合預期。
5. 明確停在控制前：若任務需要 run_home_actions，先向使用者列出家庭、裝置、動作、時間與回復方法；未取得確認就結束回合。

這個順序也延續 接 MCP 前的能力盤點：先確認 agent 原本能做到什麼，再新增一條具有資料與實體副作用的連線。

把實體動作做成審批，而不是自然語言猜測#

「把客廳燈打開」看起來簡單，但真正執行前至少要解析四個欄位：

可以把 agent prompt 固定成：「先列出你解析到的 home、resource、action 和參數；在我回覆確認前，不得呼叫任何會改變裝置狀態的工具。」如果你的 client 支援工具審批或 allowlist，初始設定只開列出和讀取工具，把 run_home_actions 保留在需要時才允許的範圍。

不要把 MCP 的 OAuth 登入當成「所有家庭操作都已經得到永久同意」。使用者授權、client 的工具批准、家庭成員對實體設備的實際期待，是三個不同層次；產品仍要在每次高風險操作前顯示具體目標。

Early access 要有降級方案#

Google Home MCP 目前不是穩定完成的 production contract。整合時要預先處理：

• 工具清單或欄位可能變更，將工具名稱與回應 schema 做版本化記錄。
• OAuth 失效或家庭授權被撤銷時，回傳需要重新授權，不要重試控制動作。
• 裝置離線、狀態延遲或歷史資料不完整時，顯示「未知」而不是推論成關閉或安全。
• run_home_actions 失敗時，先重新讀取狀態再決定是否需要人工介入，不要連續重送可能重複執行的 action。
• 所有家庭名稱、房間和裝置資訊都視為敏感資料，限制 log、分析事件和 prompt 儲存範圍。

這些設計不是在否定 Home MCP 的用途，而是把「觀察實體環境」和「操作實體環境」放在不同的可靠性與權限層級。

常見問題#