אודות
איך האינדקס הזה נבדק
כל שירות שמופיע כאן נבדק מול הקבצים הציבוריים שלו: קובץ ה-llms.txt, מניפסט ה-MCP, תיאור ה-API שפורסם או ההודעה שלו עצמו. בנוסף, מתבצע חיבור אחד לכל שרת MCP מרוחק, כדי לבדוק אם הוא משיב ללחיצת היד של MCP ואילו כלים הוא מפרט. כל רשומה מתעדת מה נמצא, מתי והיכן.
בדיקה חיה של שרתי MCP מרוחקים
ב-5 באוקטובר 2026, 9,860 מתוך 16,682 שרתי MCP מרוחקים השיבו ללחיצת היד של MCP, עם 154,231 כלים בסך הכול; 4,996 דרשו התחברות (3,930 מהם הפנו למטא-נתוני OAuth), 52 נקודות קצה SSE ישנות פתחו את הזרם שלהן ו-1,774 לא השיבו כשרתי MCP. לא נשלחה בקשה לעוד 194 שרתים: כתובת ה-URL שלהם במרשם מכילה מציין מקום שיש למלא, או שאינה כתובת https ציבורית.
מה נבדק. לכל נקודת קצה מרוחקת ברשומה של שרת במרשם, האינדקס הזה שולח בקשת initialize אחת של MCP (גרסת פרוטוקול 2025-06-18) ב-Streamable HTTP. אם השרת משיב, נשלחת הודעת initialized, נשלחת בקשת tools/list (עד חמישה עמודים) ונרשמים שם השרת והגרסה שלו, גרסת הפרוטוקול שבה השיב, מספר הכלים ועד 50 שמות כלים; לאחר מכן הסשן מסתיים. נקודות קצה בשכבת התעבורה הישנה יותר SSE רק נפתחות, בהמתנה של עד עשר שניות לאירוע שמציין את נקודת הקצה שלהן להודעות.
מה לא נבדק. אף כלי לא מופעל, אף משאב או פרומפט לא נקרא ולא מתבצעת התחברות לשום חשבון: נקודת קצה שמשיבה HTTP 401 או 403 נרשמת כדורשת התחברות, עם ציון אם היא מפנה למטא-נתוני הרשאה של OAuth. הבדיקה לא אומרת דבר על מה שהכלים עושים, כמה טוב או כמה בבטחה, והיא תמונת מצב: שרת שהשיב עשוי להיות לא זמין מאוחר יותר, ושרת שנכשל אולי היה לא זמין לזמן קצר.
איך נשלחות הבקשות. הבקשות מזדהות כ-AgentReadyDirectoryCheck/1.0 עם קישור לדף הזה, לא נושאות פרטי גישה או קובצי Cookie, ממתינות לכל היותר 15 שניות, נשלחות שוב רק פעם אחת אחרי חיבור שנותק, ונשלחות למארח אחד בכל פעם. לכתובות URL עם מצייני מקום, לכתובות HTTP רגילות, ל-localhost ולכתובות פרטיות לא נשלחות בקשות.
למה משמשים שמות הכלים. מלבד ההצגה שלהם בדף של כל שרת, שמות הכלים משייכים שרת לקטגוריה כשהשם והתקציר שלו עצמו לא מתאימים לאף אחת: אם לפחות שלושה משמות הכלים שלו מציינים נושא אחד - נסיעות, אוכל ומשלוחים, נדל״ן, בריאות, מפות ותחבורה, פיננסים, קניות או מדיה - פי שניים מכל נושא אחר ולפחות רבע מכל הכלים שלו, השרת מופיע שם, והדף שלו מציין שהקטגוריה נקבעה לפי שמות הכלים. ערכות כלים שמופיעות זהות אצל 20 שרתים או יותר (כלי gateway וכלי תבנית) ומילים כלליות כמו search, get ו-list מוסרות קודם. איך נקבעות הקטגוריות.
למה בדיקות נכשלו. שגיאת HTTP 4xx: 786, לא ניתן היה להתחבר: 491, שגיאת HTTP 5xx: 243, אין תשובה תוך 15 שניות: 181, השיב, אך לא כשרת MCP: 41, חריגה ממגבלת הבקשות (HTTP 429): 20 ודחה את לחיצת היד: 12.
מי פרסם שרת. ה-MCP Registry מקבל שמות תחת io.github.<account> רק ממי שהתחבר אליו עם GitHub כמשתמש הזה, או בשם הארגון הזה, ושמות תחת דומיין הפוך כמו com.example רק ממי שהוכיח שליטה ב-example.com - ברשומת DNS, שמכסה גם את תת-הדומיינים שלו, או בקובץ בנתיב /.well-known/mcp-registry-auth (תיעוד המרשם). כל דף שרת מציין באיזו דרך אומת מרחב השמות שלו. זה מראה מי פרסם את הרשומה, לא שהמוצר שהיא מציינת ממליץ עליה.
מקורות ורישיונות
| מקור | שימוש | רישיון |
|---|---|---|
| ה-MCP Registry הרשמי | שרתי MCP: שמות, נקודות קצה, חבילות והתקציר של המפרסם עצמו | פורסם עבור אגרגטורים; עובדות בלבד, התקצירים נכתבו מחדש |
| התיעוד של כל שירות | אילו אינטגרציות AI שירות מציע, עם קישור לדף שבו זה נאמר | עובדות בלבד; לא הועתק טקסט |
| נקודת הקצה של כל שרת MCP מרוחק | הבדיקה החיה: האם נקודת הקצה השיבה ללחיצת היד initialize של MCP, שם השרת, הגרסה שלו וגרסת הפרוטוקול, והשמות והמספר של הכלים שלו (tools/list); לא מופעל שום כלי ולא מתבצעת התחברות | עובדות בלבד (סטטוס, שמות ומספרים), נרשמות עם התאריך |
| התיעוד של ה-MCP Registry: אימות | מה מוכיח מרחב שמות במרשם: התחברות עם GitHub לשמות io.github.*, הוכחת בעלות על דומיין דרך DNS או HTTP לשמות בפורמט דומיין הפוך | עובדות בלבד |
| האתר של כל שירות | /llms.txt, /.well-known/mcp.json, /.well-known/ai-plugin.json ו-/agents.json, שנבדקו ונרשמו עם הסטטוס והתאריך | עובדות בלבד (הסטטוס והאם כל קובץ קיים) |
מי מפעיל את האתר
Agent-Ready מופעל על ידי Nexa AI. אף שירות, מלון או מקום לא משלם כדי להופיע, להיות מתואר או מדורג.
מדיניות עריכה: איך נבחרות הרשומות, מה המשמעות של רישום, איך לבקש תיקון או הסרה ועד כמה הנתונים עדכניים.