אם הקציתם שנים בתחזוקת לוגיקה עסקית בתוך אפליקציות PHP, צפייה במדריכים על Model Context Protocol עשויה להרגיש כמו לעמוד מחוץ לדלת נעולה. כמעט כל מדריך מניח שימוש ב-TypeScript או Python. הם עוברים על SDKs רשמיים, התקנות npm וחבילות pip. זה משאיר כמות עצומה של נתונים עסקיים — רשומות לקוחות, היסטוריית הזמנות, מערכות מלאי — יושבים בתוך בסיסי קוד PHP שנראים בלתי נראים עבור גל כלי ה-AI הנוכחי.
החדשות הטובות הן ששום דבר ב-MCP לא מחייב את ה-SDKs הללו. MCP אינו ספרייה. הוא wire protocol. אם סביבת ההרצה (runtime) שלכם יכולה לקרוא שורת טקסט מ-standard input, לנתח JSON ולכתוב JSON חזרה, היא יכולה לדבר את הפרוטוקול. PHP עושה בדיוק את זה הרבה לפני ש-LLMs היו קיימים.
מהו MCP באמת
MCP מייצג את Model Context Protocol. בבסיסו, זהו תקן פתוח לחיבור עוזרי AI לנתונים, כלים ו-APIs חיצוניים. במקום לבנות אינטגרציה מותאמת אישית עבור כל עוזר או מודל, אתם בונים ממשק אחד תואם (compliant). כל לקוח (client) שמבין MCP יכול אז לתקשר עם השרת שלכם מבלי לדעת דבר על PHP, Laravel או סכימת מסד הנתונים הספציפית שלכם.
מתחת לפני השטח, MCP משתמש ב-JSON-RPC 2.0. המשמעות היא שכל בקשה היא אובייקט JSON פשוט המכיל שם של מתודה (method), פרמטרים ו-ID. השרת מגיב עם אובייקט JSON נוסף הנושא תוצאה או שגיאה.
שרת חושף שלושה פרימיטיבים (primitives):
- Tools: פעולות שהמודל יכול להפעיל. כלי יכול לבצע שאילתה במסד נתונים, לעדכן סטטוס או לקרוא ל-API של צד שלישי.
- Resources: נתונים סטטיים או חצי-סטטיים שהמודל יכול להתייחס אליהם באמצעות URI. חשבו על קבצים, מסמכי קונפיגורציה או מערכי נתונים של ייחוס.
- Prompts: תבניות מוגדרות מראש שעוזרות למשתמש לתקשר עם המערכת.
יש הבחנה חשובה בתחולה (control) שיש לזכור. ה-Tools נשלטים על ידי המודל. העוזר מחליט מתי לקרוא לאחד מהם. ה-Resources נשלטים על ידי האפליקציה. השרת מחליט אילו נתונים זמינים והמודל פשוט קורא את מה שמוצע. הבנה נכונה של ההבדל הזה שומרת על הארכיטקטורה שלכם צפויה. אתם לא רוצים מודל שיחפש אחר resources שהיו אמורים להיות tools, או להיפך.
איך ה-Transport עובד
MCP מגדיר שתי שיטות transport, והבחירה שלכם מעצבת את האופן שבו תכתבו את צד ה-PHP.
stdio היא השיטה הפשוטה ביותר. לקוח ה-MCP מריץ את סקריפט ה-PHP שלכם כתת-תהליך (subprocess). הלקוח כותב הודעות JSON-RPC ל-standard input של הסקריפט שלכם, והסקריפט שלכם כותב תגובות ל-standard output. אין צורך לנהל sockets, אין פורטים לפתוח, ואין כותרות אימות (authentication headers) לנתח. אם הכלי והלקוח שלכם נמצאים על אותה מכונה, זה בדרך כלל המקום הנכון להתחיל בו.
הרצה דרך stdio מטילה שני חוקים נוקשים על תהליך ה-PHP שלכם. ראשית, האפליקציה שלכם לעולם לא צריכה לכתוב נתונים שאינם חלק מהפרוטוקול ל-stdout. אם תבצעו echo להצהרת debug או תתנו ל-PHP notice לדלוף החוצה, תשברו את ה-parser של הלקוח. הפנו את כל ה-logging והדיאגנוסטיקה ל-stderr. שנית, השבית את ה-output buffering לחלוטין. PHP אוהבת לבצע buffering ל-stdout, במיוחד בהקשרים של CGI או אינטרנט, אך גם סקריפטים של CLI יכולים להחזיק נתונים. בצעו flush לכל תגובה באופן מיידי. אם אתם משתמשים ב-streams, הגדירו stream_set_write_buffer(STDOUT, 0) או כבו את ה-implicit buffering כדי שהלקוח יקבל את ה-newline ברגע שאתם שולחים אותו.
Streamable HTTP עובד בצורה שונה. אפליקציית ה-PHP שלכם רצה כ-HTTP endpoint קבוע, שבדרך כלל מגיעים אליו באמצעות בקשות POST. זה שימושי כאשר השרת נמצא על מארח (host) אחר, או כאשר אתם רוצים daemon שרץ לאורך זמן וניתן להגיע אליו ממספר לקוחות. ב-PHP, זה בדרך כלל אומר הרצה תחת RoadRunner, FrankenPHP, או מנהל תהליכים (process manager) דומה, במקום מחזור ה-request-response המסורתי שמסתיים לאחר כל קריאה.
בנייה ב-PHP
אתם לא זקוקים ל-framework כדי להתחיל. שרת MCP מינימלי ב-PHP הוא לולאה שקוראת מ-STDIN, מפענחת JSON, מעבירה ל-handler ומקודדת את התוצאה.
while ($line = fgets(STDIN)) {
$request = json_decode($line, true);
// route to tool or resource handler
// write JSON-RPC response to STDOUT
}
בתוך הלולאה הזו, העבודה האמיתית היא בניית ממשקים שמשמעותיים עבור מודל.
צור סכמות של כלים מקוד. אחת הדרכים המהירות ביותר ליצור בעיות היא כתיבה ידנית של JSON Schemas עבור הפרמטרים של הכלים שלך, מה שגורם להם לאבד סנכרון עם לוגיקת הולידציה בפועל. ל-PHP יש יכולות reflection עשירות. בדוק את חתימות המתודות שלך, קרא חוקי ולידציה קיימים מהטפסים או מאובייקטי הפקודה (command objects) שלך, וצור את הסכימה מתוך האילוצים הללו. אם הקוד הפנימי שלך דורש פורמט אימייל תקין, סכימת ה-MCP שלך צריכה לומר את אותו הדבר. כשחוקי הולידציה משתנים, הסכימה מתעדכנת אוטומטית. ללא חוסר סנכרון, ללא כשלים שקטים.
הפרד בין שגיאות פרוטוקול לשגיאות של הכלים. ל-JSON-RPC יש מרחב שגיאות משלו. השתמש בו עבור פרוטוקול שבור: JSON לא תקין, מתודות לא ידועות, או חוסר ב-request IDs. כאשר כלי מתבצע בצורה תקינה אך נתקל בבעיה עסקית, החזר תוצאה רגילה עם דגל שגיאה (error flag) בתוך ה-payload. אם כלי חיפוש לקוחות לא מוצא רשומה תואמת, זה לא קריסה של הפרוטוקול. החזרת תוצאה מובנית כמו {"found": false} מאפשרת למודל להבין מה קרה ולבחור את הצעד הבא. הוא עשוי לנסות חיפוש רחב יותר, או לבקש מהמשתמש הבהרה. אם תזרוק שגיאת JSON-RPC במקום זאת, המודל לעיתים קרובות מאבד את ההקשר.
תכנן לעבודה ממושכת. PHP בנויה לבקשות קצרות. בקשת אינטרנט עלולה לפוג (time out) תוך שלושים שניות, ואפילו סקריפטים של CLI יכולים לרוקן זיכרון או סבלנות. אם כלי זקוק לדקות כדי להסתיים — אולי הוא מפיק דוח גדול או מסנכרן נתונים בין מערכות — אל תגרום למודל לחכות. החזר מזהה עבודה (job identifier) באופן מיידי. לאחר מכן, חשוף כלי שני לבדיקת סטטוס באמצעות אותו מזהה. ניתן לאחסן את ההתקדמות ב-Redis, בטבלת מסד נתונים, או אפילו בקובץ פשוט (flat file) אם הנפח נמוך. המודל מקבל את ה-ID, בודק שוב מאוחר יותר, ובסופו של דבר מקבל את התוצאה שהושלמה.
אבטחה כאשר למודל יש מפתחות
מתן גישה למודל AI לכלי מסוים אינו דומה למתן גישה למשתמש אנושי. מודל פועל מהר, במובן המילולי, והוא עלול לפרש תיאורים באופן שגוי. התייחס לכל כלי חשוף כסיכון להעלאת הרשאות (privilege escalation).
הגבל את ההיקף (scope) באגרסיביות. לעולם אל תחשוף כלי גנרי כמו run_sql. בנה כלים ספציפיים וצרים כמו find_customer_by_email או update_order_status. המודל אמור להיות מסוגל לעשות בדיוק את מה שקראת לו, עם הפרמטרים שהגדרת.
הפרד בין נתיבי קריאה וכתיבה. לכלים של קריאה בלבד (read-only) יש סיכון נמוך יותר. שים כל פעולה הרסנית מאחורי מנגנון אישור מפורש, או הגבל אותה לחלוטין לשרת שני. אם הלקוח (client) שלך תומך בכך, דרוש שלב של אישור אנושי לפני שכלים של כתיבה מתבצעים.
כתוב תיאורי כלים כאילו הם הוראות נוספות, כי הם בדיוק כאלה. היה מדויק לגבי המועד שבו המודל צריך לקרוא לכלי. אם כלי מחפש מחירים, ציין זאת. אם יש להשתמש בו רק לאחר אימות מזהה הלקוח, ציין זאת בבירור. תיאורים מעורפלים מובילים להתנהגות מעורפלת.
סנן את הפלט שלך. אל תבצע סריאליזציה (serialize) למודל Eloquent שלם או לישות Doctrine ותשפוך אותה לתוצאה. החזר רק את השדות שהמודל באמת צריך. לשדות פנימיים — מחירי עלות, הערות עובדים, מזהי מסד נתונים שצריכים להישאר פנימיים — אין שום עניין לעבור על הרשת. היה מפורש לגבי מבנה ההחזרה (return shape) שלך.
לבסוף, תעד (log) הכל. רשום את שם הכלי, את הארגומנטים שהועברו ואת התוצאה. אם מודל מתחיל לרוץ בלולאה על שאילתה יקרה או בודק כלים בסדר לא צפוי, הלוגים שלך הם הדרך היחידה שלך לראות זאת.
מאיפה להתחיל
אינך זקוק לאישור ממתחזק SDK כדי לחבר את אפליקציית ה-PHP שלך לעוזר AI. אתה זקוק ל-JSON-RPC, ללולאה ולקצת משמעת סביב stdout.
התנגד לדחף לשכתב את כל ה-API שלך לכלי MCP כבר ביום הראשון. בחר שלוש פעולות של קריאה בלבד שמישהו בארגון שלך באמת שואל עליהן שוב ושוב. אולי זה בדיקת סטטוס הזמנה, שליפת סיכום לקוח או רשימת חשבוניות אחרונות. עטוף אותן ככלים, ספק אותן דרך stdio, ותן לקולגה אחד להשתמש בהן. צפה במה המודל עושה טוב ובמה הוא נתקל בקשיים. תלמד יותר משלושת הכלים הללו מאשר מתכנון שלושים.
MCP הוא גשר, לא תחליף לאפליקציה שלך. קוד ה-PHP שלך כבר מכיר את העסק שלך. הפרוטוקול פשוט מאפשר למודל לחצות ולשאול אותו שאלות.