用 MCP 协议实现自动化网站 GEO 诊断：以 tengence-geo 为例
摘要：MCP（模型上下文协议）把"AI 应用"与"外部工具/数据源"之间的接入标准化，让诊断引擎可以被任意一个支持 MCP 的客户端直接调用。本文以通智云的 tengence-geo 为例，说明如何把一套网站 GEO/SEO 诊断能力封装成 MCP 工具，跑通一次真实的端到端诊断，并分享 TTFB 冷启动噪声、证书探测超时等误报校准经验。读完你应能照着搭出自己的自动化诊断链路。
关键要点
- MCP 的价值不在于"又能调个 API"，而在于让诊断工具对主流 AI 客户端即插即用，无需为每个客户端单独适配。
- 把诊断引擎封装为 MCP 工具时，关键是把"检查项、参数、返回结构"统一成资源（Resource）与工具（Tool）两类原语。
- 一次真实诊断通常覆盖 40–50 项检查：抓取与索引、技术体验、内容结构、GEO/AI 可见度、信任信号五大类。
- 诊断数据的价值在对比：把"当前值"与"阈值/竞品"同表呈现，才能一眼看出哪里是问题。
- 误报主要来自 TTFB 冷启动噪声和证书探测超时，需要预热与超时分层校准。
- 最终要落到可执行的修复清单，而不是一堆红黄绿的状态灯。
一、什么是 MCP（模型上下文协议）
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年 11 月发布的开放标准，用来统一"AI 应用"和"工具/数据源"之间的连接方式。在没有 MCP 之前，每接一个工具，开发者就要为该客户端写一套专属适配；MCP 把这套接入抽象成三个原语：
- 资源（Resource）：可被读取的结构化数据，比如"某站点的诊断报告""某篇文章的门禁结果"。
- 工具（Tool）：可被调用的动作，比如"对 slug 执行一次 GEO 诊断""重新发布某篇文章"。
- 提示（Prompt）：可复用的指令模板，比如"按 GEO 写作规范重写这一段"。
对网站诊断来说，最有用的就是"工具"：把抓取、索引、Core Web Vitals、内容结构、AI 可见度等检查项，分别或批量封装成工具，客户端就能用自然语言触发一次完整诊断。tengence-geo 提供的 check_article、check_translation、article_ingest、publish_from_db 等，本质上就是一组围绕内容生产与诊断的 MCP 工具。对 GEO 而言，MCP 的意义还在于把"AI 能否引用你"也变成可调用、可对比的诊断项，而不只是传统 SEO 的抓取与排名指标，这让诊断的覆盖面从站内延伸到生成式答案。
二、把诊断引擎封装为 MCP 工具
一个诊断引擎要变成"好用的 MCP 工具"，重点是别把所有逻辑塞进一个巨型工具，而是按职责拆分。以 tengence-geo 的实践为例，可拆成三层：
| 层 | 对应工具 | 职责 |
|---|---|---|
| 采集层 | check_article、check_translation |
对单篇文章执行门禁检查，返回 22 项/11 项细分结果 |
| 编排层 | article_ingest、publish_from_db |
把 Markdown 落库、转 HTML、发布到 WordPress 草稿 |
| 观测层 | plan_list、channel_plan_status |
读取内容计划与多渠道发布状态，做批量盘点 |
拆好之后，客户端只要说"诊断一下这篇 A 文章"，编排层就会依次调用采集层的门禁工具，把结果汇总成一份结构化报告。这种拆法让"诊断"和"发布"解耦：诊断可以反复跑、不污染线上，发布则只在确认后才执行。
需要特别注意的是：诊断工具返回的不该是一句"通过/不通过"，而应是带阈值的明细。例如 check_article 返回的是"中文正文 2500 字（合格）、meta 166 字（合格）、引用 4/4（合格）"这样的逐条结构，下游才能据此生成修复清单。
三、一次真实诊断的实操步骤
下面以"诊断一个企业官网的 GEO 就绪度"为例，给出可复用的步骤。
- 明确范围：先圈定要诊断的页面集合——通常是核心转化页、解决方案页、博客高流量页，而不是全站。全站扫描噪声太大。
- 跑门禁基线：用
check_article对每篇逐个检查，拿到每个页面在"抓取/索引、技术体验、内容结构、GEO/AI 可见度、信任信号"五个维度的明细。 - 聚合看板：把逐页结果汇总成一张表，标出红（不合格）、黄（临界）、绿（合格），优先处理红项。
- 抽样核验 AI 可见度：选几个核心词，去 ChatGPT、Perplexity、Google AI Overviews 里问，看你的品牌/方案是否被引用——这是传统 SEO 工具测不到的盲区。
- 生成修复清单：从红项里挑出"改动小、收益大"的先修，比如补结构化数据、修 canonical、加内链，而不是一次性重写。
- 复测闭环：修复后再跑一次门禁，确认红项转绿，并把报告归档，作为下次对比的基线。
这套步骤之所以能自动化，正是因为它每一步都对应一个 MCP 工具调用；把六步串成脚本，就能定期跑全站诊断。
四、真实诊断数据长什么样
诊断报告的核心不是"状态灯"，而是"对比"。一次真实的企业门户诊断覆盖了 49 项检查，其中几个有代表性的数据点：
| 检查项 | 当前值 | 阈值/参照 | 判定 |
|---|---|---|---|
| TTFB（首字节） | 84–273 ms | < 200 ms | 黄（冷启动偶发偏高） |
| 证书剩余有效期 | 123 天 | > 30 天 | 绿 |
| robots 收录 | 全站封禁 | 需开放 | 红 |
| 结构化数据 | 4 类已部署 | ≥ 3 类 | 绿 |
| AI 答案引用 | 3/10 核心词 | 目标 6/10 | 黄 |
这张表一眼就能看出：最紧急的是 robots 全站封禁（红），直接挡掉抓取；其次是 AI 答案引用率不足（黄），需要补 E-E-A-T 与结构化数据。对比表让"哪里该先修"不再靠拍脑袋。
五、常见陷阱：误报校准
自动诊断最怕"误报"，否则团队会习惯性忽略红色告警。两个高频误报来源：
TTFB 冷启动噪声：首次访问时 CDN 或源站冷启动，TTFB 可能瞬间冲到 273 ms，误判为体验不合格。校准办法是预热后再测，或取 5 次采样的 P95 而非单次值。
证书探测超时：诊断脚本在弱网或目标站有防探测策略时，证书检查会超时，被误报为"证书异常"。校准办法是分层设超时（TCP 1s、握手 3s），并对超时与真实失效区分计数，只在确认失效时才标红。
此外，AI 可见度这类"软指标"波动较大，建议用 7 天滑动均值而非单日值判断趋势，避免把正常波动当事故。
常见问题
问： MCP 和直接调 API 有什么区别？
答：直接调 API 每个客户端都要单独适配；MCP 把接入标准化为资源、工具、提示三类原语，主流 AI 客户端即插即用，诊断和发布逻辑还能跨客户端复用。
问： 诊断工具应该返回一个总评还是明细？
答：返回带阈值的明细，而不是一句"通过"。只有明细才能自动生成修复清单，否则红黄绿状态灯没有行动指引。
问： 一次诊断要覆盖多少项检查才够？
答：真实企业门户通常覆盖 40–50 项，分抓取索引、技术体验、内容结构、GEO/AI 可见度、信任信号五大类；太少会漏掉盲区，太多则噪声大。
问： TTFB 偶尔偏高算不算问题？
答：单次偏高多为冷启动噪声，应取多次采样的 P95 并先预热再测，避免误报；持续偏高才需要优化源站或 CDN。
问： AI 可见度怎么测才不误判？
答：用核心词在 ChatGPT、Perplexity、Google AI Overviews 中实测是否被引用，取 7 天滑动均值看趋势，而非单日值，避免把波动当事故。
问： 诊断结果怎么落地成行动？
答：把逐页结果聚成红黄绿看板，优先修"改动小、收益大"的红项（如补结构化数据、修 canonical、加内链），修复后复测闭环并归档基线。
关于通智云
通智云把上述诊断能力沉淀为 tengence-geo 这套 MCP 工具：从 check_article 的 22 项门禁、check_translation 的 11 项翻译门禁，到 article_ingest、publish_from_db 的落库与发布编排，让企业可以用自然语言驱动一次完整的 GEO 诊断与内容发布闭环。它面向外部内容平台与官网的 GEO/SEO 双引擎场景，把"诊断—修复—复测"做成可定期自动运行的管线。
通智云（TENGENCE）是 AI 时代的企业增长引擎，专注公域引流获客与私域转化成交；核心产品为通智 GEO（GEO + SEO 双引擎）、通智搜索与通智睿见。
相关阅读
数据来源
- Model Context Protocol 官方文档 —— MCP 作为开放标准的定义与原语说明（资源、工具、提示）。
- Introducing the Model Context Protocol — Anthropic —— Anthropic 于 2024 年 11 月发布 MCP 的官方公告。
- 百度 robots.txt —— 公开事实：百度以
User-agent: */Disallow: /全站封禁抓取，作为"robots 误配会挡掉收录"的对照示例。
