Google Ads 開了官方 MCP，卻只給 AI「看」不給「動」：2026 讀懂唯讀背後的設計選擇
Google 開源了官方 Google Ads MCP server，讓 AI 用自然語言查廣告帳戶，卻刻意設成唯讀：能看報表、不能改預算。這不是技術做不到，是設計選擇。這篇拆解 MCP 是什麼、三個工具、唯讀的理由、自架與寫入的路徑，最後收斂到一件真正卡住台灣品牌的事：餵給 agent 的第一方數據夠不夠乾淨。
你把廣告帳戶接上 AI，第一句話卻換來一句「我只能看，不能動」
想像一個場景：行銷團隊終於把 Google Ads 帳戶接上了 AI 助理。負責人打字問：「上週哪一組廣告 ROAS 掉最多？」幾秒後，AI 回了一份乾淨的清單，連跌幅原因的假設都列好了。團隊很興奮，接著下第二個指令：「把那組表現差的預算砍一半，省下來的加到轉換最好的那組。」
這一次，AI 停住了。它回覆的不是一個動作，只是一句話：「我可以幫你分析，但我沒有權限改動這個帳戶。」
不是網路斷線，也不是權限沒開。是 Google 官方那台 Google Ads API MCP server 在設計上就只給 AI「看」的能力，不給「動」的能力。它能跑報表、能診斷、能回答問題，但它不能改預算、不能加關鍵字、不能開關任何一組廣告。
問題來了。Google 自家的 Ads API 明明支援寫入，代理商用了十幾年的自動化工具都在改帳戶，為什麼官方第一版 MCP 反而把手綁起來，只留一雙眼睛？這個「看得到卻動不了」的落差，藏著 2026 年整個廣告自動化真正的關卡。
團隊的聲音
我們 91APP 團隊第一次在內部把這台 server 接起來時，會議室裡的反應很誠實：有人覺得「這也太雞肋了吧，只能查」，也有人鬆了一口氣說「還好只能查」。這兩種反應同時成立，正好說明了唯讀其實是一個需要被讀懂的選擇。我們花了一個下午釐清它，這篇文章就是那場討論的整理。
MCP 是誰都能接的開放標準，Google 只先放行了「讀」這一半
要看懂這件事，先把它拆成三層，一層一層往下走。
最上面一層，先搞懂 MCP 是什麼。MCP 全名 Model Context Protocol，是 Anthropic 在 2024 年 11 月開源的一套開放標準（Anthropic, 2024）。它解決的問題很單純：過去每接一個資料來源給 AI，就要寫一套客製整合，M 個模型乘上 N 個工具，整合數量爆炸。MCP 把它變成一個共通接口，讓任何相容的 AI 應用都能用同一套規格插上任何資料源，業界常把它比喻成 AI 世界的通用連接埠。它是開放標準，不是 Google 專屬的東西。Google 只是照這個標準，做了一台專門連到 Google Ads 的 server。
往下一層，看這台 server 給了哪些工具。根據 Google 廣告開發者部落格 2025 年 10 月 7 日的公告（Google Ads Developer Blog, 2025）與官方文件，它對外開放的核心工具只有三個：
| 工具名稱 | 它能做什麼 |
|---|---|
| search | 用 GAQL（Google Ads 查詢語言）跑報表，撈成效、預算、狀態等數據 |
| get_resource_metadata | 查某個資源（例如 campaign）有哪些欄位可查，等於一份即時的資料結構說明書 |
| list_accessible_customers | 列出這個帳號有權限存取的所有 Google Ads 客戶 ID 與名稱 |
三個工具全是「查詢類」動作，沒有一個能寫入。你可以把它想成一位很會讀報表的分析助理：它能回答任何關於帳戶現況的問題，但它手上沒有那支能按下「儲存」的筆。
再往下挖到最關鍵的一層：唯讀是一種刻意的設計選擇，跟技術能不能做到沒有關係。Google Ads API 本身完全支援寫入，代理商工具改預算、批次上關鍵字改了十幾年。官方在文件裡把這一版明確定位為 read-only，是刻意先只放行讀取。原因不難理解：一個能自然語言下指令的 AI，如果直接握有改動百萬預算的權限，一句話說錯就是真金白銀燒掉。先讓 AI 學會看、學會診斷、學會被信任，再談讓它動手，是比較穩的順序。
這三個工具聽起來樸素，實際能回答的問題卻不少。你可以問它「過去三十天哪些關鍵字花了錢卻零轉換」、「哪幾組 campaign 的每次轉換成本比上個月高兩成」、「這個帳戶還有哪些受預算限制的廣告群」，它會把 GAQL 查詢組好、把結果整理成人看得懂的清單。對每天要盯十幾個帳戶的行銷團隊來說，光是用一句話取代十次後台點擊，就已經省下大把時間。它做不到的，只有最後那一下：把游標移到欄位上、改個數字、按下儲存。
換個方式看，這台唯讀 server 把行銷團隊的日常拆成了兩半：問問題、看數據、找問題這一半，AI 已經能扛；下判斷、改設定、負責任這一半，還牢牢握在人手上。對每週要交十幾份帳戶報表的團隊來說，光是把前面這一半自動化，就足以把人力從複製貼上做報表，釋放到真正思考策略。這也是為什麼就算只給看，這台 server 仍然值得認真接起來用。
Google 選擇先給眼睛再給手，多數對手一步到位就給手
把時間軸拉開看，這件事就更清楚了。
先看 Google 自己。依 Google 廣告開發者部落格 2025 年 10 月 7 日的官方公告（Google Ads Developer Blog, 2025 年 10 月），它在 2025 年 10 月開源這台 MCP server，走的是最保守的路：官方 repo 放在 github.com/googleads/google-ads-mcp，免費、開源、唯讀，而且不提供託管版本，你得自己在本機或雲端跑起來（Search Engine Land 的報導也記錄了同一個時間點）。這裡把開源時間點明確標成 2025 年 10 月很重要：後面整條「Google 最早、最謹慎」的對比敘事都以這個日期為錨，部分二手整理把它記成 2026 年 4 月，會讓時間軸對不上，一切以官方部落格為準。
把時間往後推半年，來到 Google Marketing Live 2026（Google, 2026），時間是 2026 年 5 月 20 到 21 日。這場大會的主軸是「Gemini 成為 Google Ads 的作業系統」，幾乎每一項新功能都掛著 agentic 或生成式 AI。這裡要特別分清楚哪些是 2026 新發、哪些是 2025 先發後延續，免得張冠李戴：
- Ask Advisor 是 2026 新發：一個橫跨 Google Ads、Analytics、Merchant Center 與 GMP 的統一 Gemini agent，目前 beta 且英文先行。這台是「會動手」的 agent，和唯讀的官方 MCP server 是兩回事。
- AI Mode 內兩種 Gemini 廣告格式是 2026 新發：其中一種是廣告內嵌 AI agent，使用者能在廣告裡直接問答、AI 從廣告主官網抓答案，甚至交出預填名單表單，目前在部分產業與市場先行測試、尚未全面開放。
- Universal Cart 與底層的 AP2、UCP 協定是 2026 新發：一個橫跨 Search、Gemini、YouTube、Gmail 的持久購物車，屬於正在鋪路的基礎建設，不是今天就能用的功能。
- AI Max、Smart Bidding Exploration 這類是 2025 先發、2026 延續強化：這裡最容易張冠李戴的一點要說清楚，AI Max for Search 早在 2026 年 4 月中就正式 GA、走出 beta（Google, 2026 年 4 月），比 5 月下旬的這場大會早了約一個月，並不是「在 GML 上畢業」；GML 2026 上 AI Max 的真正動作，是把這套框架延伸到 Shopping 與 Travel。想搞懂 AI Max 怎麼運作，可以參考我們先前整理的Google AI Max 完全解析。
這裡有個容易混淆的點要講白：Ask Advisor 這種會動手的 agent，和本文主角那台唯讀 MCP server，是 Google 在同一個方向上的兩個不同產品。前者由 Google 自己託管、自己控管風險、逐步開放權限，是封閉的 agent；後者丟在 GitHub 上任你自架，卻只給讀取。Google 一手緊握寫入型 agent 的開放節奏，一手把唯讀能力大方開源，這個雙軌安排本身就說明了它對「讓 AI 動手」有多謹慎。
再看競爭對手這一邊。進入 2026 上半年，Meta、TikTok、Amazon 陸續推出自家的官方 Ads MCP，一場平台軍備競賽開打。其中 Meta 走得最激進：它在 2026 年 4 月底推出官方的 MCP OAuth server（Meta for Developers, 2026 年 4 月），一上線就提供近三十個工具、當天即支援讀取與寫入，也就是 AI 能直接改動帳戶，寫入能力有官方文件佐證。相較之下，TikTok 這一邊到 2026 年初仍停留在公告階段，還沒有正式 GA 與開發者文件，關於它的寫入規格目前多為媒體與社群轉引，實際能力請以官方後續釋出為準。如果你在同時經營多平台廣告，Meta 這邊的變動值得盯緊，我們在Meta 2026 歸因大改版指南裡有更完整的脈絡。
對台灣的品牌與代理商來說，這場軍備競賽帶來一個很現實的問題：你不會只投一個平台。當 Google 給唯讀、Meta 直接給寫入、TikTok 與 Amazon 各有各的規格與時程，你的團隊很快就要面對「同時管理好幾套 AI 存取權限」的局面。哪一個平台先接、接到什麼程度、誰有權限放行寫入，這些治理問題會比工具本身更早浮上檯面。
想像一個很具體的畫面：一家同時投 Google、Meta、TikTok 的美妝品牌，行銷團隊只有三個人，卻要在半年內決定每一個平台的 AI 要開到哪一格。Google 那台可以放心讓資淺的同事接來練手，因為它動不了帳戶；Meta 那台一接上就能改預算，權限給誰、能不能夜間自動執行，就得先問過主管。同一批人、同一批帳戶，卻要維護三套鬆緊不一的規則。這不是工具好不好用的問題，是誰來訂規則、規則寫在哪、出事誰負責的問題。先把這件事想清楚的團隊，接下來每一次開放權限都會比別人穩。
把這三個時間點放在一起，一條線就浮出來了：Google 選擇先給眼睛、再給手，而部分競爭對手選擇一步到位給手。誰對誰錯還沒有答案，但這正好逼出一個更根本的問題。
真正卡住廣告自動化的，是餵進去的數據乾不乾淨
先看表象。大家看到唯讀，直覺反應是「功能不完整、Google 太保守」。想補上寫入能力，眼前有兩條路。
一條是回到 Google Ads API 本身。API 支援寫入，你或你的工程團隊可以自己串，也可以用市面上第三方的 connector，例如 Scalekit 或 Composio，它們補上了寫入動作與 token 生命週期管理。要注意的是，第三方 connector 等於把帳戶的寫入權交到 Google 以外的一方手上，選用前得把資安與權責邊界想清楚。另一條是自己決定怎麼跑官方那台 server：它是自架、非託管的，你可以用 Python 加 stdio 在本機跑，也可以自己部署到 Cloud Run，但無論哪種，都仍需要 developer token 加 OAuth 授權。
這兩種跑法的取捨可以簡單對照：
| 跑法 | 適合誰 |
|---|---|
| Python 加 stdio 在本機跑 | 個人或小團隊做分析，資料不出自己的電腦，設定最快、最省事 |
| 自行部署到 Cloud Run | 團隊共用、要接進排程或自動化報表流程，需要多人同時穩定存取 |
還有一件事得誠實講：唯讀本身並不會自己把事情做完。它給你的是一份精準的診斷，接下來改不改、怎麼改，仍然要靠人、靠 API、或靠另一個有寫入權的工具去執行。也就是說，它縮短了「發現問題」的時間，卻沒有縮短「解決問題」的最後一哩。真正想把這最後一哩也交出去的品牌，遲早要回答同一個問題：敢不敢放手讓 AI 動手？而敢不敢，最後取決於它讀到的數據可不可信。
再往下看機制。MCP 的運作是 client 對 server 的兩端結構，AI 應用是 client，這台 server 負責把 GAQL 查詢丟給 Google Ads API、把結果整理回來。你會發現，無論唯讀還是寫入，這台 server 做的事情本質上是「把 AI 的意圖翻譯成對帳戶的操作」。它是一條管線，一個翻譯官。管線本身乾不乾淨、翻得準不準，取決於兩端：一端是 AI 讀不讀得懂你的意圖，另一端是帳戶裡的數據值不值得信任。這裡也常有人把 MCP 和 RAG 混為一談，我們在CDP AI 的迷思：MCP、RAG 與行銷自動化裡把兩者的分工講清楚了。
值得補一句的是，MCP 之所以重要，在於它是開放標準，不綁單一廠商。這代表同一套「用自然語言問資料」的技能，你在 Google Ads 上練會了，換到未來任何一個支援 MCP 的平台幾乎都能沿用。Google 選擇用這套開放標準、而且先開源唯讀版本，等於用最低的風險，讓整個生態圈的行銷人提早熟悉「對著帳戶說話」這件事。等大家習慣了、也信任了，再把寫入的閘門一格一格打開。
把這件事放回一個行銷人真實的一天，感受會更清楚。過去要回答「這個月哪三組廣告的每次轉換成本惡化最多」，一位資淺投手可能要開五、六個後台分頁，一格一格複製數字進試算表，一個上午就沒了。接上這台唯讀 server 之後，同一個問題變成一句話，答案幾秒內就整理成清單。省下的不只是時間，更是那種「盯著報表卻抓不到重點」的焦慮。但也正因為它答得又快又順，團隊很容易升起一種錯覺：既然它這麼懂帳戶，乾脆讓它直接改算了。這正是 Google 用唯讀踩下的那一腳煞車，先讓人看清楚 AI 讀懂了什麼、又漏看了什麼，再決定要不要把方向盤交出去。
挖到最底層，真正的關卡浮現了：卡住廣告自動化的，從來不是那台 server 能不能寫入，而是餵給它的數據乾不乾淨。這一點在 Google Marketing Live 2026 的分析中（WordStream, 2026）被反覆強調，多位分析師的共同結論是：當投放、創意、出價都交給 AI，決定成效的關鍵已經移到「輸入品質」，也就是你餵給 AI 的第一方數據、brief 與衡量訊號夠不夠好。這也是 Media.Monks 對這次大會的觀察（Media.Monks, 2026）點出的方向：人的價值從「操作帳戶」移到「餵養與掌舵 AI」。
舉個更具體的例子。一位客人早上在官網把一雙鞋加入購物車卻沒結帳，中午走進門市用會員條碼買了同一雙，晚上又在 LINE 官方帳號問了尺寸建議。如果這三筆行為在系統裡對不起來，廣告 agent 看到的會是三個人：一個放棄購物車的網路訪客、一個門市熟客、一個 LINE 潛在客。它很可能同時對「其實早就買過的人」再投一次促購廣告，把預算浪費在已經成交的顧客身上。會犯這種錯，源頭在於它拿到的顧客輪廓從一開始就是碎的，跟 agent 聰不聰明沒有關係。
這裡要把因果鏈講精準一點，免得誤會。這台唯讀 MCP 用 GAQL 讀的，是你 Google Ads 帳戶裡的成效與設定資料，它並不會直接伸手進你的 CDP 讀顧客輪廓。第一方數據的品質是先透過轉換回傳、受眾名單這些訊號流進廣告平台，再間接決定出價、受眾與未來寫入型 agent 的判斷品質。所以真正的邏輯是這樣：如果你帳戶背後的顧客數據是破碎的、同一個人在官網、門市、LINE 各自算成三個陌生人，餵進平台的訊號就跟著失真；就算 Google 明天把寫入權限開給 AI，agent 拿到失真的訊號，只會給你破碎的答案，然後用它握有的寫入權，把破碎的判斷更快地執行成破碎的結果。工具給不給動，反倒是次要的。
當 agent 能動手，數據品質就是那道護欄
把上面的邏輯接下去，一個很實際的方法論就成形了。廣告自動化這件事，可以拆成兩個層次來看：一個是「動作層」，也就是 MCP、agent、API 這些能對帳戶下指令的能力；另一個是「輸入層」，也就是餵進去的第一方數據品質。動作層現在跑得飛快，Google、Meta、TikTok 半年內全部到位。真正還沒被大多數品牌補上的，是輸入層。
我們在服務台灣零售品牌時，最常遇到的不是「AI 不夠聰明」，而是同一位會員的身分在不同系統裡對不上：官網一組 ID、POS 一組會員、LINE 又一組 UID，廣告平台看到的只是零散的裝置。這種情況下，你把帳戶接上任何 agent，它看到的都是拼圖缺了一半的顧客輪廓。
顧客數據平台（CDP／CDMP）在這裡扮演的角色，就是把 agent 動手之前該有的那道地基先鋪好。以 91APP CDMP 的實務為例，它做的第一件事是 OMO 歸戶：把同一個人在線上與門市的行為併回同一個身分，形成一份乾淨、去重、可被信任的第一方數據。這裡要說清楚它的角色很單純：把散在各系統的第一方數據收攏、歸戶、清乾淨，再以乾淨的樣貌交給下游的廣告 agent 使用，讓 agent 的每一個判斷都建立在可信的顧客輪廓上。當這份數據乾淨了，你再把它接給 Google Ads MCP、接給 Ask Advisor、接給任何寫入型 agent，AI 讀到的才是完整的顧客，做出的判斷才值得放行去動預算。這套「先歸戶、再自動化」的順序，我們在OMO 資料整合與 CDMP 實務裡有更完整的拆解；如果你更想理解 agentic 時代裡 CDP 與 CDMP 的定位差異，Agentic Commerce 與 CDP／CDMP 的關係這篇可以接著看。
再把畫面拉回那個被拆成三個人的顧客。歸戶完成之後，agent 看到的是同一個人：她加了購物車、當天到店消費、事後還在 LINE 追問尺寸，是一位高意圖而且已經成交的忠誠客。這時廣告該做的判斷就完全不同了：不需要再花錢投促購，應該把她放進新品預告或會員回購的受眾。同一個 agent、同一台 MCP、同樣的寫入權限，換上乾淨的第一方數據，輸出的決策品質天差地遠。這也是為什麼把地基鋪好的優先順序，會高於急著把帳戶交給 AI 動手。
更重要的是，歸戶不是做完一次就結束的專案。顧客每天都在產生新的行為：今天在官網瀏覽、明天到門市消費、後天在 LINE 領了優惠券，這些新資料如果沒有持續被歸進同一個身分，乾淨的第一方數據很快又會變髒。這也是把歸戶交給平台、少用人工試算表的理由：它需要一套能天天自動維護的機制，撐住廣告 agent 每天要吃的乾淨燃料。
方法論講到底很樸素：agent 是引擎，第一方數據是燃料。引擎再強，燃料髒了照樣跑不動。唯讀這一版官方 MCP，某種程度上替品牌爭取了一段緩衝期，讓你趁 AI 還只能看的時候，先把燃料濾乾淨。這段緩衝期怎麼用，決定了寫入權限開放那天，你是準備好放手的人，還是還在手忙腳亂補資料的人。
趁 AI 還只能看，先把第一方數據整理到能被信任
在 Google 把寫入權限逐步放開之前，台灣品牌可以先做幾件具體的事，順序是有意義的。
- 先盤點身分歸戶的斷點。花一週時間，把官網、POS、LINE、廣告平台這四個來源的會員 ID 對照一次，算出同一個人被重複計算成幾個身分。這個數字通常會嚇到自己，也是後面所有自動化的起點。
- 用官方唯讀 MCP 先跑一輪帳戶健檢。它免費、唯讀、零風險，適合拿來當第一個練習：讓團隊習慣用自然語言查帳戶、驗證 AI 給的診斷準不準，建立對 agent 的信任感，同時不用擔心它手滑改壞東西。這一步幾乎沒有導入成本，卻能讓團隊對「AI 讀我們的帳戶」這件事先建立起肌肉記憶。
- 建立乾淨的轉換與微轉換訊號。QFC（Qualified Future Conversions）是 Google 在 Google Marketing Live 2026 新發、目前仍為限量 pilot 的預測型指標（WordStream, 2026），它讓 Gemini 預測一名使用者未來 180 天內的轉換價值，吃的都是你回傳的第一方轉換數據。訊號髒，預測就歪。可以先從盤點自己的微轉換（Micro Conversions）設定開始。
- 把第一方數據歸戶交給顧客數據平台處理，別靠人工試算表硬撐。三個以上來源、幾十萬會員的規模，人工比對不只慢，還會累積錯誤。這是唯一一項會直接動用到 CDMP 能力的建議：讓平台把 OMO 歸戶做成可持續維護的資產，而不是一次性專案。
- 訂一條放行寫入的內部準則。想清楚未來哪些動作可以交給 agent 自動執行、哪些必須人工簽核，例如「單日預算調整 10% 以內可自動、跨組搬移必須人工確認」。趁現在還只能看的時候把規則寫好，等寫入權限開放那天才不會手忙腳亂。這條準則不必一次寫到完美，先有一版，之後隨著對 agent 的信任累積，再逐步放寬即可。
看得到，不等於動得了；而動得了，不等於做得對
回到開頭那個會議室。AI 說「我只能看，不能動」的那一刻，很多人聽到的是限制。但換個角度，這句話其實是一個提醒：看得到，不代表你已經準備好讓它動；而就算有一天它動得了，動得了也不代表它做得對。
廣告自動化這幾年跑得太快，快到我們容易把注意力全放在工具能不能再多做一點。可是真正決定成效的，一直是那些不性感的基本功：你的顧客是不是同一個人、你的數據是不是乾淨、你的訊號是不是可信。Google 這一版唯讀 MCP，像是特意留給整個產業的一段喘息，讓大家在 AI 全面接手之前，先把地基補好。
先讓 AI 學會看懂你，再放心讓它替你動手。這個順序，值得慢一點。
常見問題 FAQ
Q1: Google Ads 官方 MCP server 到底是什麼？ 它是 Google 開源的一台伺服器，讓相容的 AI 應用能用自然語言查詢 Google Ads 帳戶的數據。它照 MCP（Model Context Protocol）這套開放標準做出來的，本質上是 AI 與 Google Ads API 之間的翻譯管線，官方 repo 免費開源。
Q2: 為什麼官方版本只能看不能改？是技術做不到嗎？ 不是技術問題。Google Ads API 本身支援寫入，官方刻意把第一版設成唯讀，是為了安全。一個能自然語言下指令的 AI 若直接握有改動預算的權限，一句話說錯就是真金白銀的損失，先讓 AI 學會讀取與診斷、建立信任，是比較穩健的順序。
Q3: 那我要怎麼讓 AI 真的動手改帳戶？ 有兩條路。一是回到 Google Ads API 自己串寫入功能，或使用第三方 connector 補上寫入與授權管理；二是等待官方後續版本或改用其他支援寫入的 agent。無論哪一條，都建議先把帳戶背後的第一方數據整理乾淨再放行。
Q4: 這台 server 要架在哪裡？本機還是雲端？ 兩種都行。它是自架、非託管的：可以用 Python 加 stdio 在本機跑，適合個人分析、資料不出自己的機器；也可以自己部署到 Cloud Run，適合團隊共用與接進自動化流程。兩種都需要 developer token 加 OAuth 授權。
Q5: MCP 和廣告自動化 agent 是同一件事嗎？ 不是。MCP 是連接 AI 與資料源的開放標準與管線，Google Marketing Live 2026 發表的 Ask Advisor 才是會跨平台動手的 agent。可以把 MCP 想成道路規格，agent 想成路上跑的車。
Q6: 我是台灣零售品牌，第一步該做什麼？ 先盤點官網、門市 POS、LINE、廣告平台之間的會員身分有沒有對上。多數品牌會發現同一個人被算成好幾個身分。這種破碎的第一方數據會讓任何 AI 的判斷失準，建議透過顧客數據平台做 OMO 歸戶，把地基補好，再談把帳戶交給 agent。