שאלו שאלות, הריצו דוחות, צרו ועדכנו רשומות — מ-Claude, מ-ChatGPT או מ-Gemini. כל אדם מתחבר עם טוקן משלו, ואפשר לבטל אותו בשניות.
Priority Gateway v1.55.x · POST /mcp
שתי לשוניות, נקודת קצה אחת: שאלה שנענית מנתונים חיים, וכתיבה שעוצרת לאדם.
מודל שפה קורא רק את מה שמדביקים לו. בלי משטח כלים, כל שאלה על Priority נגמרת בצילום מסך, בייצוא CSV או בניחוש שגוי.
לכל התקנה יש טפסים, עמודות וכללים משלה. חיבור עם סכימה צרובה מתיישן בבוקר שבו מישהו מוסיף עמודה.
קריאה קל לאשר. כתיבה פחות. השאלה שמנהל הכספים באמת שואל היא של מי הכללים כשהמודל לוחץ שמירה.
נקודת קצה אחת עונה על שלושתן.
ה-Gateway מאחד 23 כלים צרים לשלושה כלים מרכזיים, בלי לוותר על יכולת. מודל לומד את המשטח פעם אחת ומשתמש בו בכל Priority.
priority_discover
לגלות מה קיים
טפסים ופרוצדורות לפי שם, מטא-דאטה של שדות בכל עומק של מסך-בן, ערכי בחירה, ובדיקת פרטי התחברות.
priority_action
לבצע בקריאה אחת
שליפה, יצירה, עדכון ומחיקה. הרצת פרוצדורות ודוחות, הפעלת פעולות מהטופס, העלאת קבצים ואצוות כתיבה.
priority_session
לערוך כמו שאדם עורך
פותחים טופס, מזינים שדה אחד, רואים את Priority עונה באזהרות ובעדכונים נגררים, ושומרים.
הגילוי ההדרגתי הוא הסיבה שזה עובד על ה-Priority שלכם. המודל שואל מה קיים לפני שהוא עושה משהו, ולכן שום דבר מההתקנה שלכם לא צרוב אצלנו. תוסיפו עמודה ל-ORDERS בבוקר, והמודל יראה אותה אחר הצהריים.
"כמה מכרנו בחודש שעבר" רחוקה join שגוי אחד ממספר שגוי ובטוח בעצמו. לכן המודל מקבל קודם את הפרוסה הנכונה מהסכימה שלכם.
כל דבר עם סכום, דירוג, פילוח או טווח תאריכים.
הטפסים הרלוונטיים, מסנני הבחנה, מסלולי join וקטלוגי ערכים — מבסיס הנתונים הגרפי של ההתקנה שלכם.
הוא מנסח את השאילתה בעצמו, מול כללי הדיאלקט שקיבל.
בדיקת דיאלקט וקיום עמודות מול הגרף, לפני שמשהו רץ.
רצה בערוץ ה-SQL לקריאה בלבד, והתשובה חוזרת לשיחה.
ה-Gateway לעולם לא כותב ולא משכתב את ה-SQL. הוא ממקד את הסכימה, מנסח את כללי הדיאלקט ובודק את מה שהמודל חיבר. השאילתה נשארת של המודל, ואתם יכולים לקרוא אותה לפני שהיא רצה.
המיקוד הזה מגיע מבסיס נתונים גרפי של ה-Priority שלכם, שנבנה על ידי BI Generator: כל טבלה, עמודה, טופס ומסלול מפתח זר, עם המשמעות העסקית של כל שדה והמסננים שהופכים תצוגת טופס למה שהיא — כולל הישויות שאיש היישום שלכם בנה. הטבלה הייעודית שמאחורי תהליך בקרת האיכות שלכם והעמודות שמישהו הוסיף לשורת ההזמנה נמצאות על המפה לצד הסטנדרטיות. מודל שמסתמך על ידע כללי ב-Priority לא יידע בכלל שהן קיימות; מודל שמקבל את ההקשר הזה עונה עליהן כבר בניסיון הראשון.
הבקרות הן אלה שכבר קיימות ב-Priority. תפקיד ה-Gateway הוא לחשוף אותן, לא להמציא אותן מחדש.
| כשהמודל… | מה קורה בפועל |
|---|---|
| קורא נתונים | הוא רץ כמשתמש ה-Priority שנצרב בטוקן — בדיוק ההרשאות שיש לאותו אדם בלקוח Priority, לא יותר. |
| כותב SQL | ערוץ ה-SQL הוא לקריאה בלבד מעצם המבנה. הפעולות INSERT, UPDATE, DELETE ושאר פעולות השינוי נדחות לפני שהשאילתה יוצאת מה-Gateway. |
| יוצר או מעדכן רשומה | הכתיבה עוברת דרך הטופס של Priority עצמו, ולכן כל הבדיקות, כללי העסק והטריגרים רצים. שום דבר לא נכתב ישירות לטבלה. |
| נתקל באזהרה של Priority | נוסח האזהרה עולה לשיחה במקום להיבלע. מישהו מאשר או מבטל, והשמירה ממתינה. |
| מגיע לדיאלוג אישור | אתם בוחרים לכל קריאה: לאשר, לבטל, להכשיל את הקריאה, או להעביר את נוסח הדיאלוג למודל ולתת לו להחליט בקול. |
| בוחר פרוטוקול לא נכון | מסמכי העזר הם חלק ממשטח הכלים. המודל בודק איזו טכנולוגיה מתאימה במקום לנחש, ומקבל רמז מתקן כששאילתה נתקלת בקיר מוכר. |
אותה נקודת קצה, אותם טוקנים. בחרו את זו שהאנשים שלכם כבר פותחים.
מדביקים כתובת ומתחברים. OAuth 2.1 עם רישום לקוח דינמי ו-PKCE; הלקוח מגלה בעצמו את שרת ההרשאות מתוך האתגר שה-Gateway מחזיר.
# הוספת מחבר מותאם
https://your-gateway/mcp
מורידים את חבילת החיבור מפורטל הרישוי ופותחים אותה. אין קובץ הגדרות לערוך ביד, ואין JSON שאפשר לטעות בו.
# בלחיצה אחת, מהפורטל priority-gateway.mcpb
ChatGPT ו-Gemini מגיעים ל-Gateway דרך תמיכת ה-MCP שלהם, וכך גם כל דבר אחר שמדבר את הפרוטוקול מעל HTTP. בנו סוכן משלכם על אותם שלושה כלים.
# Streamable HTTP POST /mcp Authorization: Bearer gct_…
הטוקן שפותח את ה-REST API פותח גם את ה-MCP. אף אחד לא מקליד סיסמת Priority לתוך כלי AI.
טוקן gct_ צורב את שרת ה-Priority, את המשתמש, את החברה ואת השפה שעבורם הונפק. מנפיקים אותו בעמוד ההתחברות של ה-Gateway או בפורטל הרישוי; ברירת המחדל היא 365 יום. טוקן שדלף לא ניתן להפנות לטננט אחר.
מבטלים אדם מהפורטל או מה-API, והבקשה הבאה שלו נכשלת. משנים את כתובת השרת, וכל הטוקנים שעליו מתבטלים איתה, כך שטוקן ישן לא ממשיך לחייג לכתובת שעבורה הונפק.
מפעילים שער הסכמה, וזרימת ה-OAuth מפסיקה לבקש יפה: היא דורשת הדבקה של טוקן מחבר, שכובלת כל סשן AI לזהות Priority אמיתית ולא למי שמצא את הכתובת.
הטוקנים שהונפקו נשמרים במאגר מוצפן ועמיד. אפשר לפרוס מחדש את ה-Gateway והלקוחות המחוברים ממשיכים לעבוד — וקובץ המאגר לבדו חסר ערך למי שייקח אותו.
ארבע עובדות ששווה לבדוק לפני שמחברים משהו.
כלים מרכזיים שאיחדו 23 כלים צרים, בלי לאבד יכולת.
לא התקנה נפרדת, לא רישיון נפרד ולא שירות נוסף להריץ.
לקוחות מחוברים נשארים מחוברים גם אחרי פריסה מחדש.
מעצם המבנה, לא מכוח מדיניות. פעולות שינוי לא מגיעות ל-Priority.
נקודת הקצה /mcp שהלקוח שלכם מתחבר אליה רצה על Amazon Web Services, כש-Cloudflare יושב לפני כל בקשה.
הגייטוויי המתארח רץ באזור תל אביב של Amazon, ונפרס מצינור גרסאות מסודר. הסודות שמורים מוצפנים ב-AWS Parameter Store, ולא בבסיס נתונים או בקובץ הגדרות.
כל בקשה מגיעה דרך Cloudflare: הצפנת TLS, הגנה מפני מתקפות מניעת שירות, חומת אש לאפליקציות, הגבלת קצב וסינון בוטים — ולצד זה מטמון וניתוב שמקצרים את הדרך מכל מקום שבו האנשים שלכם נמצאים.
השרתים לא מקבלים חיבורים נכנסים. הם יוצרים קשר החוצה אל Cloudflare והתעבורה חוזרת דרך אותה מנהרה, כך שאין פורט ציבורי למצוא ואין מה לסרוק. ממשקי הניהול יושבים מאחורי שער נוסף.
מריצים את הגייטוויי אצלכם? ה-MCP מגיע בתוכו. אותו מודל של Cloudflare נותן לשירות ה-Windows שאצלכם נקודת קצה שמודל שפה יכול להגיע אליה — בלי לפתוח פורט ברשת שלכם.
הרשמה אחת מחברת את הצוות שלכם ל-Priority דרך AI. המוצרים האלה כבר בנויים על המשטח שהעמוד הזה מתאר.
רוכבים על אותם שלושה כלים
משפט אחד לאפליקציה עובדת על גבי טפסי ה-Priority שלכם.
אותם כלים, אותם טוקנים, בכל מה שתבנו הלאה.
לחבילה המלאה — עמוד המוצרים. למה שיושב מתחת למשטח הזה — Priority Gateway.