יצירת API מדומה ב־Thodr דרך עורך קוד תואם MCP

אפשר להתחיל לבדוק מסך הזמנות גם כשהבקאנד עדיין לא מוכן. במדריך שפרסמה Thodr ב־27 באוקטובר 2026 מתואר חיבור עורך קוד תואם MCP באמצעות thodr-mcp, יצירת נקודת קצה מדומה דרך העוזר ושימוש בכתובת ה־HTTPS שלה באפליקציה. הנה מסלול עבודה מעשי ליישום התהליך, עם נתונים פיקטיביים ובדיקות שמתאימות גם לממשק בעברית.

011. מגדירים את התשובה שהממשק צריך לקבל

החידוש בתחקיר הוא פרסום המדריך, לא הכרזה על יכולת חדשה. הרעיון פשוט: במקום להמתין לשירות האמיתי, יוצרים API מדומה שמחזיר נתונים לצורך פיתוח. MCP הוא פרוטוקול לחיבור כלי AI לכלים ולמקורות מידע חיצוניים; במקרה הזה, החיבור מאפשר לבקש מהעוזר שבעורך הקוד ליצור את נקודת הקצה.

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

• הגדירו פעולת קריאה, למשל בקשת GET לרשימת הזמנות.
• בחרו מבנה תשובה ברור: אובייקט ובו מערך orders, או מערך ישיר, בהתאם לחוזה המוסכם.
• קבעו שדות לדוגמה: id כמחרוזת, customerName כטקסט, total כמספר ו־currency כקוד מטבע.
• הוסיפו status עם ערכים מוסכמים, כדי שהממשק לא יצטרך לנחש כיצד להציג כל הזמנה.
• הכינו שמות פיקטיביים בעברית, טקסט ארוך ורשימה ריקה לבדיקת מצבי תצוגה שונים.

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

022. מחברים את thodr-mcp ובודקים הרשאות

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

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

033. מבקשים נקודת קצה ובודקים את התוצאה

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

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

044. מחברים לאפליקציה בלי לקבע את כתובת הבדיקה

שמרו את כתובת ה־mock בהגדרת פיתוח נפרדת, במקום לפזר אותה בקובצי הממשק. בדוגמת JavaScript הבאה, endpoint הוא פרמטר שמקבל את כתובת ה־HTTPS שהוחזרה, והפונקציה מצפה לאובייקט עם מערך orders. זו דוגמת אינטגרציה לחוזה שבחרנו, לא תיאור של פורמט קבוע שמובטח על ידי Thodr.

async function loadOrders(endpoint) {
  const response = await fetch(endpoint);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  const data = await response.json();
  if (!Array.isArray(data.orders)) {
    throw new Error("Expected an orders array");
  }
  return data.orders;
}

חברו את הפונקציה למנגנון טעינת הנתונים הקיים באפליקציה והציגו בנפרד טעינה, הצלחה ושגיאה. בדיקת המערך בקוד היא בדיקה בסיסית בלבד; בפרויקט עצמו כדאי לאמת גם את טיפוסי השדות. אם הקריאה מצליחה בכלי HTTP אך נכשלת בדפדפן, בדקו את הודעת השגיאה ואת הגדרות CORS לפני שמשנים את הקוד.

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

055. בודקים מצבי קצה ומתכוננים לשרת האמיתי

כשהרשימה מופיעה, עברו מתרחיש ההצלחה לבדיקת התנהגות. אל תניחו שכל תרחיש נתמך ישירות ב־Thodr: בדקו במדריך אילו אפשרויות קיימות. תרחישים שאינם זמינים בשירות אפשר להשלים בשכבת בדיקות מקומית, בלי לייחס לכלי יכולת שלא אומתה.

1. בדקו רשימה ריקה: האם מופיע הסבר ברור במקום מסך שנראה תקול?
2. בדקו תוכן בעברית: שמות ארוכים, מזהים באנגלית וסכומים עם סימן מטבע.
3. בדקו כשל בקשה והשהיה באמצעות כלי הבדיקות הזמינים לכם: האם הטעינה מסתיימת והמשתמש יכול לנסות שוב?
4. עברו על הגדרות הסביבה וודאו שכתובת ההדמיה אינה נבחרת בטעות בפריסת הייצור.

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