Google Search Console MCP: สี่เซิร์ฟเวอร์ SEO MCP เปิดเผยอะไรจริง ๆ

MCP เซิร์ฟเวอร์สำหรับ Google Search Console คือวิธีที่ทำให้เอเจนต์อ่านข้อมูลการค้นหาของคุณได้โดยไม่ต้องส่งออก CSV ก่อน นั่นคือส่วนที่ง่าย ส่วนที่ไม่ง่ายคือการแยกแยะเซิร์ฟเวอร์ออกจากกัน เพราะทุกตัวแนะนำตัวเหมือนกันหมด และความต่างจะปรากฏก็ต่อเมื่อคุณถามว่าจริง ๆ แล้วมันทำอะไรได้

เราจึงถาม ในวันที่ 12 กันยายน 2026 เราเชื่อมต่อ MCP เซิร์ฟเวอร์ด้าน SEO ที่เผยแพร่แล้วสี่ตัว ส่งคำขอ tools/list ไปยังแต่ละตัว แล้วนับสิ่งที่ได้กลับมา ตัวเลขคือ 42, 21, 4 และ 1

ช่องว่างนี้ไม่ใช่การจัดอันดับคุณภาพ มันคือการตัดสินใจเชิงออกแบบ และมันเปลี่ยนสิ่งที่เอเจนต์ทำได้ เปลี่ยนต้นทุนด้านบริบทที่คุณจ่าย และเปลี่ยนว่าข้อมูลของคุณออกจากขอบเขตของคุณไปมากแค่ไหน

เราทดสอบอะไร และอย่างไร

วิธีการ: แต่ละเซิร์ฟเวอร์ถูกรันตามที่เอกสารของตัวเองระบุไว้ทุกประการ ผ่านอินพุตเอาต์พุตมาตรฐาน หรือผ่าน HTTP เมื่อเอกสารระบุโหมดนั้น เราส่งแฮนด์เชก initialize ของ MCP ตามด้วย tools/list แล้วบันทึกจำนวนและชื่อเครื่องมือ เราไม่ใช้คีย์ API ยกเว้นกรณีที่เซิร์ฟเวอร์ปฏิเสธที่จะเริ่มทำงานหากไม่มีคีย์

เซิร์ฟเวอร์หนึ่งตัว ซึ่งเป็นแพ็กเกจ 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 เครื่องมือ) เซิร์ฟเวอร์ v3 ของ DataForSEO ไปในทางตรงกันข้าม มันเปิดเผย docs_index, docs_list_sections, docs_search และเครื่องมือคำขอทั่วไปหนึ่งตัวคือ api_request แทนที่จะตั้งชื่อทุกปลายทาง มันสอนให้โมเดลไปหาเอกสารแล้วจึงเรียกแบบมีสิทธิ์ยืนยัน สี่เครื่องมือครอบคลุม API ที่มีหลายร้อยปลายทาง และโมเดลจ่ายค่าความเฉพาะเจาะจงตอนเรียก ไม่ใช่ตอนโหลด ในการตรวจสอบของเรา ปลายทาง HTTP คืนค่า invalid auth เมื่อไม่มีข้อมูลรับรอง และตอบสนองปกติเมื่อมี นั่นคือพฤติกรรมที่ต้องการ

เซิร์ฟเวอร์เครื่องมือเดียว (1 เครื่องมือ) seo-mcp-server คืนเครื่องมือเพียงตัวเดียวคือ ai_content_detect เซิร์ฟเวอร์เล็กไม่ใช่เรื่องผิด แต่ก็ควรซื่อสัตย์ว่ามันคืออะไร: เดโมหรือการตรวจสอบเดี่ยว ไม่ใช่โต๊ะทำงาน SEO ถ้าคุณติดตั้งโดยหวังจะได้รายงานรายสัปดาห์ คุณจะผิดหวังในแบบที่คู่มือติดตั้งไม่เคยบอกไว้

สี่ต้นแบบ สองแบบขยายไปสู่งานรายงานจริงได้ และแต่ละแบบขยายไปคนละทิศ

ทำไมจำนวนเครื่องมือถึงเป็นพาดหัวที่ผิด

เซิร์ฟเวอร์สองตัวที่มีจำนวนเท่ากันอาจทำงานต่างกันอย่างสิ้นเชิง เพราะสิ่งที่สำคัญคือรูปร่างของขอบเขต ไม่ใช่ตัวเลข

ตัวห่อตัดสินคำถามของคุณไว้ล่วงหน้า มันมีประโยชน์จริงเมื่อ API ข้างใต้ยากและตัวห่อบรรจุความเชี่ยวชาญจริง ซึ่งรายการของ mcp-gsc ทำแบบนั้น มันกลายเป็นข้อจำกัดในวินาทีแรกที่คำถามของคุณอยู่นอกรายการ และไม่มีทางอ้อม

เกตเวย์แทบไม่ตัดสินอะไรเลย และดันงานไปที่โมเดล ยืดหยุ่นกว่าและเปราะบางกว่า โมเดลเอื้อมถึงอะไรก็ได้ ซึ่งหมายความว่ามันเอื้อมถึงปลายทางผิด อ่านรูปร่างการตอบกลับผิด และใช้การเรียกเครื่องมือสามครั้งเพื่อค้นพบว่าฟิลด์ที่ต้องการชื่ออื่น บนคำถามง่าย ๆ ตัวห่อเร็วกว่า บนคำถามใหม่ มีแค่เกตเวย์ที่ตอบได้ตั้งแต่แรก

การทดสอบที่ใช้ได้จริงไม่ใช่ "มีกี่เครื่องมือ" แต่คือ "เซิร์ฟเวอร์เปิดเผยสิ่งนั้นที่ฉันถามทุกสัปดาห์หรือไม่" งานติดตามอันดับมักหมายถึงการวิเคราะห์การค้นหาแบบแยกวันที่และอุปกรณ์ บวกการตรวจสอบ URL ทั้งตัวห่อและเกตเวย์ครอบคลุมสิ่งนั้น ส่วนเซิร์ฟเวอร์ 42 เครื่องมือครอบคลุมสิ่งนั้น และครอบคลุมอีกสี่สิบอย่างที่คุณจะไม่ได้ใช้ในวันนี้

การตรวจสอบที่สำคัญจริงก่อนติดตั้งอะไรก็ตาม

อ่านขอบเขตสิทธิ์ ไม่ใช่อ่านรายการฟีเจอร์ เซิร์ฟเวอร์ Search Console สืบทอดสิ่งที่การอนุญาต OAuth ของคุณยอมให้ การอนุญาตแบบอ่านอย่างเดียวที่แสดงรายการพร็อพเพอร์ตี้และดึงการวิเคราะห์การค้นหาได้ก็เพียงพอต่อการทำรายงานและการเฝ้าระวัง อะไรก็ตามที่เสนอแก้ไขการตั้งค่า ส่งไซต์แมป หรือขอให้จัดทำดัชนี กำลังเขียนลงในพร็อพเพอร์ตี้ของคุณ และนั่นคู่ควรกับเกณฑ์ที่สูงกว่าคำว่า "รีโปนี้มีดาว" มาก

ตรวจสอบว่าอะไรออกจากเครื่องของคุณ เกตเวย์ที่ส่งต่อข้อมูลรับรอง API ไปยังผู้ให้บริการมีลักษณะความเสี่ยงต่างจากตัวห่อในเครื่องที่พูดกับ Google API ด้วยโทเคนของคุณเอง ทั้งสองแบบอาจไม่มีปัญหา แต่มีเพียงแบบเดียวที่หมายความว่าบุคคลที่สามเห็นทุกคำค้นที่คุณดึง

รันการทดสอบการตอบกลับว่าง ขอช่วงวันที่ที่ไม่มีข้อมูลจากเซิร์ฟเวอร์ เช่นพร็อพเพอร์ตี้ที่คุณยังไม่เปิดตัว เซิร์ฟเวอร์ที่ทำมาดีจะคืนชุดผลลัพธ์ว่าง เซิร์ฟเวอร์ที่ทำมาแย่จะคืนข้อผิดพลาด และเอเจนต์ที่ได้รับข้อผิดพลาดมักแต่งคำอธิบายที่ฟังดูสมเหตุสมผลให้กับข้อมูลที่หายไป การทดสอบครั้งเดียวนี้จับปัญหได้มากกว่าการรีวิวโค้ดใด ๆ

เซิร์ฟเวอร์สองตัวเปิดเผยรายงานเดียวกันได้ แต่ต่างกันสิ้นเชิงในเรื่องว่าใครเห็นข้อมูลรับรองของคุณ

ตรวจสอบว่าเกิดอะไรขึ้นเมื่อเครื่องมือล้มเหลว ขีดจำกัดอัตราเป็นเรื่องจริง: 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>" }
    }
  }
}

สามกฎที่เราใช้ เรียงตามความเจ็บปวดที่มันป้องกันได้

หนึ่งเซิร์ฟเวอร์ต่อหนึ่งแหล่งข้อมูล เซิร์ฟเวอร์สองตัวที่ต่างอ้างว่าตอบคำถามเรื่องอันดับได้จะให้คำตอบสองแบบ และเอเจนต์จะเลือกอันที่ฟังดูน่าเชื่อกว่า ไม่ใช่อันที่ถูกต้อง ให้ Search Console กับตัวห่อ ให้ข้อมูล SERP ของบุคคลที่สามกับเกตเวย์ แล้วเขียนไว้ว่าฟิลด์ใดเชื่อถือฝ่ายไหน

วางนิยามการรายงานไว้นอกเซิร์ฟเวอร์ เครื่องมือให้สิทธิ์เอเจนต์เข้าถึงข้อมูล มันไม่ได้ให้นิยามของคุณ: พร็อพเพอร์ตี้ใดนับบ้าง คำค้นใดคือตัวขับเคลื่อนรายได้ และอันดับเป็นค่าเฉลี่ยช่วงหรือภาพนิ่งรายวัน สิ่งเหล่านั้นเป็นของไฟล์คำสั่งที่เอเจนต์อ่านก่อนจะเรียกอะไรก็ตาม และมันคือเส้นแบ่งระหว่างบทสรุปที่มีประโยชน์กับข้อผิดพลาดที่มั่นใจเกินเหตุ เวิร์กโฟลว์รายงานรายสัปดาห์ คือตัวอย่างที่มีชีวิตของนิยามที่อยู่นอกเครื่องมือ

ตรวจสอบการรันครั้งแรกด้วยมือ ดึงการวิเคราะห์การค้นหาหนึ่งสัปดาห์ผ่านเซิร์ฟเวอร์ แล้วเทียบกับสัปดาห์เดียวกันในหน้าจอ Search Console ถ้าตัวเลขไม่ตรงกัน คุณมีปัญหาช่วงวันที่หรือการระบุแหล่งที่มา และรายงานอัตโนมัติทุกฉบับหลังจากนั้นจะสืบทอดมันไป

มุมมอง Auspia: คำถามของ MCP ไม่ใช่ "เซิร์ฟเวอร์ใดดีที่สุด" แต่คือ "คุณอยากลากเส้นขอบเขตแบบใดระหว่างเอเจนต์กับข้อมูลของคุณ" ตัวห่อคือสัญญาที่คุณรับไว้ล่วงหน้า เกตเวย์คือความรับผิดชอบที่คุณรับในทุกการรัน อันใดเข้ากับเวิร์กโฟลว์อันดับที่กว้างกว่านั้น คู่มือความสามารถของเอเจนต์ จัดเรียงตามงาน ทั้งสองแบบชอบด้วยเหตุผล และทีมที่ถูกไฟลวกคือทีมที่เลือกโดยไม่ทันสังเกตว่าตัวเองเลือก

คำถามที่พบบ่อย

Google เผยแพร่ MCP เซิร์ฟเวอร์อย่างเป็นทางการสำหรับ Search Console หรือไม่ ณ วันที่ 12 กันยายน 2026 เราไม่พบในรีจิสทรีแพ็กเกจ เซิร์ฟเวอร์ Search Console ที่เราทดสอบเป็นโครงการของชุมชนหรือของผู้ให้บริการที่วางอยู่บน API ทางการ สิ่งที่เป็นทางการคือชั้น API ซึ่งตัวมันเองไม่ใช่ข้อบกพร่องโดยอัตโนมัติ แต่มันหมายความว่าเซิร์ฟเวอร์นั้นเป็น dependency ด้านการดูแลที่คุณเป็นคนเลือก

MCP เครื่องมือกี่ตัวจึงจะมากเกินไปสำหรับหนึ่งเซสชันของเอเจนต์ ไม่มีตัวเลขตายตัว ขอบเขตที่ใช้ได้จริงคือรายการเครื่องมือดันคำสั่งของคุณออกจากหน้าต่างบริบทหรือไม่ การโหลดเซิร์ฟเวอร์ 42 เครื่องมือให้งานที่ต้องการแค่สองตัวหมายถึงคุณจ่ายค่าอีกสี่สิบนิยามในทุกการเรียก โหลดเซิร์ฟเวอร์แคบสำหรับงานประจำ และตัวกว้างสำหรับการสำรวจ

เอเจนต์ใช้ MCP กับ Search Console ได้โดยไม่ใช้บัญชีบริการหรือไม่ ได้ หากเซิร์ฟเวอร์ทำขั้นตอน OAuth ไว้และคุณทำจนจบในเครื่องหนึ่งครั้ง เส้นทางบัญชีบริการง่ายต่อการทำงานอัตโนมัติและยากต่อการส่งต่อให้คนอื่น ทีมจึงมักรันทั้งสองแบบ: บัญชีบริการสำหรับงานตั้งเวลา และ OAuth สำหรับงานเป็นครั้งคราว

คุณเก็บเซิร์ฟเวอร์ใดไว้ ตัวห่อ สำหรับรายงานรายสัปดาห์ เพราะคำถามเป็นที่รู้จัก เกตเวย์ยังติดตั้งไว้สำหรับงานใดก็ตามที่ต้องการแหล่งข้อมูลซึ่งตัวห่อไม่ครอบคลุม และนั่นคือส่วนใหญ่ของงานที่น่าสนใจ และไม่ใช่สักอย่างของงานประจำ

ผู้เขียน: Julian Mercer นักวิจัยการผสานรวม MCP ที่ Auspia ครอบคลุมสายเครื่องมือเอเจนต์มากกว่า 40 สาย เขาเขียนเกี่ยวกับโปรโตคอลเอเจนต์ ขอบเขตของเครื่องมือ และต้นทุนดำเนินงานของการต่อโมเดลภาษาเข้ากับข้อมูลที่มีชีวิต