Google Search Console MCP: מה ארבעה שרתי MCP ל-SEO חושפים בפועל

שרתי 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 בלי אישורים, והגיבה כראוי עם אישורים. זו ההתנהגות הרצויה.

שרת של כלי אחד (כלי אחד). seo-mcp-server מחזיר בדיוק כלי אחד, ai_content_detect. אין רע בשרת קטן, אבל הוא צריך להיות כן לגבי מה שהוא: הדגמה או בדיקה בודדת, לא שולחן עבודה של SEO. אם תתקינו אותו בציפייה לדוח שבועי, תתאכזבו בדרך שהנחיות ההתקנה מעולם לא הזכירו.

ארבעה ארכיטיפים. שניים מהם מתרחבים לעבודת דוחות אמיתית, וכל אחד מהם מתרחב לכיוון אחר.

למה מספר הכלים הוא הכותרת הלא נכונה

שני שרתים עם אותו מספר יכולים להתנהג אחרת לגמרי, כי מה שקובע הוא צורת הגבול, לא המספר.

העטיפה מחליטה את השאלות שלכם מראש. זה מועיל באמת כשהבסיס קשה והעטיפה מקודדת מומחיות אמיתית, והרשימה של 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, וזה כשלעצמו אינו פגם אוטומטי, אבל זה כן אומר שהשרת הזה הוא תלות תחזוקה שאתם בוחרים.

כמה כלי MCP זה יותר מדי לשיחה אחת של סוכן? אין מספר קבוע. הגבול המעשי הוא אם רשימת הכלים דוחקת את ההוראות שלכם מחוץ לחלון ההקשר. טעינת שרת של 42 כלים למשימה שצריכה שניים מהם משלמת על ארבעים הגדרות בכל קריאה. טענו שרתים צרים לשגרה ורחבים לחקר.

האם סוכן יכול להשתמש ב-MCP עם Search Console בלי חשבון שירות? כן, אם השרת מימש זרימת OAuth ואתם השלמתם אותה פעם אחת מקומית. מסלול חשבון השירות קל יותר לאוטומציה וקשה יותר למסור לאדם, ולכן צוותים מריצים בדרך כלל את שניהם: חשבון שירות להרצות מתוזמנות ו-OAuth לעבודה מזדמנת.

איזה שרת השארתם? את העטיפה, לדוחות השבועיים, כי השאלות ידועות. השער נשאר מותקן לכל עבודה שצריכה מקור נתונים שהעטיפה לא מכסה, וזה רוב העבודה המעניינת ואף אחד מהשגרה.

הכותב: Julian Mercer, חוקר אינטגרציית MCP ב-Auspia על פני יותר מ-40 שרשראות כלים לסוכנים. הוא כותב על פרוטוקולי סוכנים, גבולות כלים, והעלות התפעולית של חיבור מודלים לשוניים לנתונים חיים.