用 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 誤配會擋掉收錄」的對照示例。
