Google Search Console MCP 伺服器，是讓 agent 不必先匯出 CSV 就能讀取你搜尋資料的方式。這點很簡單。不簡單的是分辨不同伺服器，因為它們都用同樣的方式介紹自己，差異只在你問它們到底能做什麼時才顯現出來。
於是我們問了。2026 年 9 月 12 日，我們連接了四個已發布的 SEO MCP 伺服器，各發一個 tools/list 請求，並統計回傳的數量。結果是 42、21、4、1。
這個差距不是品質排名。它是一個設計決策，並且改變了 agent 能做什麼、在上下文上花你多少成本，以及有多少資料離開你的機房。
我們測了什麼，怎麼測的
方法：每個伺服器都完全依它自己文件指示的方式啟動，透過標準輸入輸出，或在文件指明該模式時透過 HTTP。我們送出 MCP initialize 握手，然後送 tools/list，記錄工具數量和名稱。除伺服器無金鑰就拒絕啟動之外，不使用任何 API 金鑰。
伺服器 | 版本 | 回傳的工具數 | 列出工具是否需要認證 |
|---|---|---|---|
Ahrefs MCP | 0.0.11 | 42 | 否 |
mcp-gsc | 0.3.2 | 21 | 否 |
DataForSEO MCP | 3.1.1 | 4 | 是，透過 HTTP |
seo-mcp-server | 3.0.5 | 1 | 否 |
有一個伺服器，一個第三方 Search Console 套件，在我們 50 秒的視窗內始終沒有完成握手，因此被排除而不是計分。工具清單會隨每個版本變化，所以請把這些數字當作某天早晨的快照，而不是任何廠商的永久屬性。
四種設計，以及各自的用途
包裝器（21 個工具）。 mcp-gsc 接收 Search Console API，把各個報告包裝成具名工具。它的清單讀起來像搜尋分析師的工作職責：search_analytics、inspect_url、top_movers、quick_wins、cannibalization、content_decay、device_country_breakdown、ctr_anomalies、weekly_seo_report、indexing_coverage。優點是模型永遠不必建構查詢。代價是你繼承了別人關於一份報告該包含什麼的想法，而且清單之外的東西你一樣都要不到。
全平台鏡像（42 個工具）。 Ahrefs 的伺服器逐個端點地暴露該廠商的產品面：rank-tracker-overview、rank-tracker-competitors-overview、keywords-explorer-matching-terms、keywords-explorer-volume-history、batch-analysis。這是我們測到的能力最強的清單，也是上下文最貴的，因為每個工具定義都會被載入，無論它與任務是否相關。它也最清楚地說明了這項取捨：能力的廣度，換來對每一次提示的永久課稅。
閘道（4 個工具）。 DataForSEO 的 v3 伺服器走了相反方向。它暴露 docs_index、docs_list_sections、docs_search，以及一個通用 api_request。它不給每個端點命名，而是教模型去找到文件，然後發起一次帶認證的呼叫。四個工具涵蓋了有數百個端點的 API，模型把具體性的代價付在呼叫時而不是載入時。在我們的探測中，HTTP 端點在無憑證時回傳 invalid auth，有憑證時正常應答，這正是你想要的行為。
單一工具伺服器（1 個工具）。 seo-mcp-server 只回傳一個工具，ai_content_detect。小伺服器本身沒有錯，但要誠實看待它是什麼：一個示範或單項檢查，不是 SEO 工作台。如果你裝著它期待每週報表，你會以安裝說明從未提及的方式失望。
四種原型。其中兩種能擴展到真實的報表工作流，而且是朝不同方向擴展。
為什麼工具數量是錯誤的標題
數量相同的兩個伺服器可以有完全不同的表現，因為重要的是邊界的形狀，不是數字。
包裝器提前替你決定了問題。當底層 API 很棘手、而包裝器編碼了真正的專業經驗時，這確實有用，mcp-gsc 的清單就是這樣。當你的問題第一次不在清單上時，它就變成了限制，而你繞不過去。
閘道幾乎什麼都不決定，把工作推給模型。這更靈活也更脆弱。模型能夠到任何東西，這也意味著它能夠到錯誤的端點、誤讀回應結構，並花掉三次工具呼叫才發現它想要的欄位叫別的名字。對簡單問題，包裝器更快。對新穎問題，只有閘道能答得上來。
實用的檢驗不是「有多少工具」，而是「這個伺服器是否暴露我每週都要問的那件事」。對排名追蹤工作流來說，通常就是帶日期和裝置拆分的搜尋分析，加上網址檢查。包裝器和閘道都涵蓋了。而 42 個工具的伺服器涵蓋了它，還涵蓋了你今天不會用的另外四十件事。
安裝任何東西之前真正重要的檢查
讀權限範圍，不要讀功能列表。 Search Console 伺服器會繼承 OAuth 授權所允許的一切。一個能列出資源和拉取搜尋分析的唯讀授權，對報表和監控已經夠了。任何提供修改設定、提交網站地圖或要求編入索引的東西，都是在寫入你的資源，那值得比「這個倉庫有星號」高得多的門檻。
核實什麼東西離開了你的機器。 把 API 憑證轉發給廠商的閘道，與用你自己的權杖直接和 Google API 通訊的本機包裝器，風險性質不同。兩者都可能沒問題。但只有一個意味著第三方會看到你拉取的每一個關鍵字。
跑一次空回應測試。 向伺服器要一個沒有資料的日期範圍，比如一個你還沒上線的資源。做得好的伺服器會回傳空結果集。做得差的會回傳錯誤，而收到錯誤的 agent 常常會為缺失的資料編出一個聽起來合理的解釋。這一個測試抓到的問題比任何程式碼審查都多。
兩個伺服器可以暴露相同的報告，卻在誰能看到你的憑證上截然不同。
檢查工具失敗時會發生什麼。 速率限制是真實存在的：Search Console 允許每個網站每分鐘 1,200 次查詢，而 agent 的一波重試就能自己把它燒光。把限制暴露出來的伺服器是可用的。悄悄什麼都不回傳的伺服器，會教會你的 agent 你沒有曝光，這比報錯更糟。同樣的限制也塑造任何自建排名追蹤器的形態，所以請求預算值得在設定檔中佔一行。
接入 agent
設定是小的那部分。決定你能不能拿到價值的是擺放位置。
{
"mcpServers": {
"gsc": {
"command": "npx",
"args": ["-y", "mcp-gsc"],
"env": { "GSC_CREDENTIALS": "/path/to/service-account.json" }
},
"dataforseo": {
"url": "http://localhost:3000/mcp",
"headers": { "Authorization": "Basic <base64 login:password>" }
}
}
}我們用的三條規則，按能避免多少痛苦排序。
每個資料源一個伺服器。 兩個都聲稱能回答排名問題的伺服器會產生兩個答案，而 agent 會選聽起來更好的那個，而不是正確的那個。把 Search Console 給包裝器，把第三方 SERP 資料給閘道，並寫清楚哪個欄位以哪個為準。
把報表定義留在伺服器外面。 工具給 agent 的是資料存取權。它不給你定義：哪些資源算數、哪些查詢是賺錢查詢、排名是區間均值還是每日快照。那些屬於 agent 在呼叫任何東西之前先讀的指令檔，它們是有用摘要和自信錯誤之間的差別。每週報表工作流就是定義活在工具之外的實例。
第一次執行手動核驗。 透過伺服器拉一週的搜尋分析，和 Search Console 介面裡同一週對比。如果數字對不上，你就有日期範圍或歸因問題，而此後每一份自動化報表都會繼承它。
Auspia 觀點：MCP 的問題不是哪個伺服器最好。而是你想在你的 agent 和資料之間設立什麼樣的邊界。包裝器是你提前接受的合約。閘道是你每一次執行都要接受的責任。至於兩者各自如何嵌入更廣的排名工作流，agent 能力指南梳理了這些任務。兩者都正當，而吃虧的團隊，是沒注意到自己已經做了選擇就做出選擇的團隊。
常見問題
Google 是否發布 Search Console 的官方 MCP 伺服器？ 截至 2026 年 9 月 12 日，我們在套件註冊表裡找不到。我們測的 Search Console 伺服器都是架在官方 API 之上的社群或廠商專案。官方的是 API 那一層，所以這本身不自動構成問題，但這確實意味著該伺服器是你主動選擇的一項維護依賴。
一個 agent 工作階段裡多少個 MCP 工具算太多？ 沒有固定數字。實用的界限是工具列表是否在上下文視窗裡把你的指令擠出去。如果為一個只需要其中兩個工具的任務載入了 42 個工具的伺服器，你就在每次呼叫時為四十個定義付費。日常活兒載入窄的伺服器，探索時用寬的。
agent 能否不用服務帳戶就配合 MCP 使用 Search Console？ 可以，只要伺服器實作了 OAuth 流程且你在本機完成過一次。服務帳戶這條路更容易自動化，也更難交給一個人，所以團隊通常兩條都跑：定時任務用服務帳戶，臨時工作用 OAuth。
你們留下了哪個伺服器？ 包裝器，用於每週報表，因為問題都是已知的。閘道留著，給任何需要包裝器涵蓋不到的資料源的事用，那是大部分有意思的工作，也是所有日常工作中一件都沒有的部分。
作者：Julian Mercer，Auspia 的 MCP 整合研究者，跨越 40 多個 agent 工具鏈。他寫 agent 協議、工具邊界，以及把語言模型接到即時資料上的營運成本。
