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 协议、工具边界，以及把语言模型接到实时数据上的运营成本。
