Google Search Console の MCP サーバーは、CSV を書き出さずにエージェントが検索データを読むための手段です。そこまでは簡単です。難しいのは、サーバー同士を見分けることです。どれも同じように自己紹介をし、違いは「実際に何ができるのか」を尋ねたときに初めて現れます。
そこで尋ねてみました。2026年9月12日、公開されている SEO 向け MCP サーバー4つを接続し、それぞれに tools/list リクエストを送り、返ってきた数を数えました。結果は 42、21、4、1 でした。
このばらつきは品質の順位ではありません。設計上の判断であり、エージェントにできること、コンテキストにかかるコスト、そしてどれだけのデータが社外に出るかが変わります。
何を、どう検証したか
方法：各サーバーは、それぞれのドキュメントが指示するとおりに起動しました。標準入出力経由、またはドキュメントがその方式を指定している場合は 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 | 不要 |
1つのサーバー、サードパーティ製の Search Console パッケージは、私たちの50秒の待ち時間内にハンドシェイクを完了せず、採点せず除外しました。ツールの一覧はリリースごとに変わるので、この数値はある朝のスナップショットとして扱うべきで、どのベンダーの恒久的な性質ではありません。
4つの設計と、それぞれの用途
ラッパー（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 を1つ、露出します。すべてのエンドポイントに名前を付ける代わりに、モデルにドキュメントを見つけさせ、そのうえで認証付きの呼び出しを行わせます。4つのツールで数百のエンドポイントを持つ API を覆い、モデルは具体性のコストを読み込み時ではなく呼び出し時に払います。私たちの検証では、HTTP エンドポイントは資格情報なしで invalid auth を返し、資格情報ありで正常に応答しました。これは望ましい挙動です。
単一ツールのサーバー（1ツール）。 seo-mcp-server はちょうど1つのツール、ai_content_detect だけを返します。小さなサーバーが悪いわけではありませんが、それが何であるかには正直であるべきです。デモ、あるいは単一のチェックであり、SEO の作業台ではありません。週次レポートを期待して導入すると、インストール手順が決して語らなかった形で失望します。
4つの原型。そのうち2つは実際のレポート業務まで拡張でき、しかも別方向に拡張します。
ツール数が見出しとして間違っている理由
同じ数を持つ2つのサーバーがまったく違う振る舞いをすることがあります。重要なのは境界の形であり、数ではないからです。
ラッパーはあなたの問いを前もって決めます。土台の API が厄介で、ラッパーが本物の専門知識を符号化しているとき、これは本当に役に立ちます。mcp-gsc の一覧はまさにそうしています。それが制約になるのは、あなたの問いがリストに載っていない最初の瞬間で、そこを回り込む手立てはありません。
ゲートウェイはほとんど何も決めず、作業をモデルに押し出します。より柔軟で、より脆い。モデルは何にでも到達できます。つまり、間違ったエンドポイントに到達し、レスポンスの形を読み違え、欲しかったフィールドが別の名前だということを突き止めるのに3回のツール呼び出しを使うこともできます。単純な問いではラッパーのほうが速い。新しい問いでは、そもそも答えるのはゲートウェイだけです。
実用的なテストは「ツールがいくつあるか」ではなく「毎週尋ねるあの事柄をサーバーが露出しているか」です。順位トラッキングの業務なら、通常は日付とデバイスの分割を伴う検索アナリティクス、そして URL 検査です。ラッパーもゲートウェイもそれを覆っています。42ツールのサーバーはそれを覆い、さらに今日使わない40の何かを覆っています。
何かを導入する前に確認すべきこと
機能一覧ではなく権限スコープを読む。 Search Console のサーバーは、OAuth 付与が許すものをそのまま引き継ぎます。プロパティを一覧でき、検索アナリティクスを取得できる読み取り専用の付与は、レポートと監視には十分です。設定の変更、サイトマップの送信、インデックス登録のリクエストを申し出るものはあなたのプロパティに書き込んでおり、それは「リポジトリにスターがある」よりずっと高い基準に値します。
あなたのマシンから何が出ていくかを確かめる。 API 資格情報をベンダーに転送するゲートウェイは、自分のトークンで Google の API と直接話すローカルのラッパーとは別のリスク特性を持ちます。どちらも問題ない場合があります。片方だけが、あなたが取得するすべてのキーワードを第三者が見ることを意味します。
空レスポンスのテストを走らせる。 データのない日付範囲、たとえばまだ公開していないプロパティをサーバーに尋ねてください。よく作られたサーバーは空の結果セットを返します。不出来なサーバーはエラーを返し、エラーを受け取ったエージェントは欠けたデータについてもっともらしい説明をでっち上げがちです。この1つのテストは、どんなコードレビューより多くの問題を捕まえます。
2つのサーバーが同じレポートを露出しても、あなたの資格情報を誰が見るかは異なり得ます。
ツールが失敗したときに何が起きるかを確認する。 レート制限は実在します。Search Console はサイトあたり毎分1,200クエリを許し、エージェントの再試行が集中すればそれだけで使い切ります。制限を表面化するサーバーは使えます。何も返さずに黙ってしまうサーバーは、インプレッションがゼロだとエージェントに教え込むことになり、エラーより悪い。同じ制限は自作の順位トラッカーにも形を与えるので、リクエストの予算は設定ファイルに一行を割く価値があります。
エージェントへの組み込み
設定は小さな部分です。価値が得られるかどうかを決めるのは配置です。
{
"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>" }
}
}
}私たちが使っている3つのルールを、防げる苦痛の大きい順に挙げます。
データソースごとに1つのサーバー。 どちらも順位の質問に答えられると主張する2つのサーバーは2つの答えを生み、エージェントは正しいほうではなく、よりもっともらしく聞こえるほうを選びます。Search Console はラッパーに、サードパーティの SERP データはゲートウェイに与え、どのフィールドについてどちらが権威かを書き留めてください。
レポートの定義をサーバーの外に置く。 ツールはエージェントにデータへのアクセスを与えます。あなたの定義は与えません。どのプロパティを数えるか、どのクエリが稼ぎ頭か、順位が期間の平均なのか日次のスナップショットなのか。それらはエージェントが何かを呼ぶ前に読む指示ファイルに属し、有用な要約と自信満々の誤りの分かれ目になります。週次レポートのワークフローは、定義をツールの外に置く実例です。
最初の実行は手で検証する。 サーバー経由で1週間分の検索アナリティクスを取得し、Search Console の画面で同じ週と比べてください。数値が合わなければ日付範囲かアトリビューションの問題があり、それ以降の自動レポートはすべてそれを引き継ぎます。
Auspia の見解：MCP の問いは「どのサーバーが最良か」ではありません。「エージェントとデータの間にどんな境界を引くか」です。ラッパーは前もって受け入れる契約です。ゲートウェイは毎回受け入れる責任です。どちらがより広い順位づけの流れに収まるかは、エージェント能力ガイドがタスクを整理しています。どちらも正当であり、やけどをするチームは、選んだことに気づかないまま選んだチームです。
よくある質問
Google は Search Console の公式 MCP サーバーを公開していますか？ 2026年9月12日時点で、私たちがパッケージレジストリで見つけられたものはありません。私たちが試した Search Console サーバーは、公式 API の上に載るコミュニティまたはベンダーのプロジェクトです。公式なのは API のほうなので、それ自体が自動的に問題になるわけではありませんが、そのサーバーはあなたが選ぶ保守依存であることは意味します。
1つのエージェントセッションにとって MCP ツールは何個から多すぎますか？ 決まった数はありません。実用的な限界は、ツール一覧がコンテキストウィンドウ内であなたの指示を押し出すかどうかです。そのうち2つしか要らないタスクに42ツールのサーバーを読み込めば、毎回の呼び出しで40の定義分を払っています。定型業務には狭いサーバーを、探索には広いサーバーを読み込んでください。
サービスアカウントなしでエージェントは Search Console で MCP を使えますか？ 使えます。サーバーが OAuth フローを実装していて、あなたが一度ローカルで完了させればよいのです。サービスアカウントの経路は自動化が容易で人に渡すのが難しいため、チームは通常どちらも走らせます。定期実行にはサービスアカウント、都度の作業には OAuth です。
どのサーバーを残しましたか？ ラッパーです。週次レポート用で、問いが既知だからです。ゲートウェイはラッパーが覆わないデータソースを要するもののために導入したままにしています。それは興味深い仕事のほとんどすべてであり、定型業務のどれでもありません。
著者：Julian Mercer、Auspia の40以上のエージェントツールチェーンを横断する MCP 統合研究者。エージェントプロトコル、ツールの境界、言語モデルを生きたデータにつなぐ運用コストについて書いています。
