שאלו שאלות, הריצו דוחות, צרו ועדכנו רשומות — מ-Claude, מ-ChatGPT או מ-Gemini. כל אדם מתחבר עם טוקן משלו, ואפשר לבטל אותו בשניות.
Priority Gateway v1.55.x · POST /mcp
שתי לשוניות, נקודת קצה אחת: שאלה שנענית מנתונים חיים, וכתיבה שעוצרת לאדם.
מודל שפה קורא רק את מה שמדביקים לו. בלי משטח כלים, כל שאלה על Priority נגמרת בצילום מסך, בייצוא CSV או בניחוש שגוי.
לכל התקנה יש טפסים, עמודות וכללים משלה. חיבור עם סכימה צרובה מתיישן בבוקר שבו מישהו מוסיף עמודה.
קריאה קל לאשר. כתיבה פחות. השאלה שמנהל הכספים באמת שואל היא של מי הכללים כשהמודל לוחץ שמירה.
נקודת קצה אחת עונה על שלושתן.
שלושה כלים במקום עשרים ושלושה, בלי לוותר על כלום בדרך. המודל לומד אותם פעם אחת ומשתמש בהם בכל Priority.
priority_discover
לגלות מה קיים
מוצא טופס או פרוצדורה לפי שם, רואה את השדות שלהם בכל עומק, וקורא את ערכי הרשימות.
priority_action
לבצע בקריאה אחת
שליפה, יצירה, עדכון ומחיקה. הרצת פרוצדורות ודוחות, הפעלת פעולות מהטופס, העלאת קבצים ואצוות כתיבה.
priority_session
לערוך כמו שאדם עורך
פותחים טופס, מזינים שדה אחד, רואים את Priority עונה באזהרות ובעדכונים נגררים, ושומרים.
הגילוי ההדרגתי הוא הסיבה שזה עובד על ה-Priority שלכם. המודל שואל מה קיים לפני שהוא עושה משהו, ולכן שום דבר מההתקנה שלכם לא צרוב אצלנו. תוסיפו עמודה ל-ORDERS בבוקר, והמודל יראה אותה אחר הצהריים.
"כמה מכרנו בחודש שעבר" רחוקה join שגוי אחד ממספר שגוי ובטוח בעצמו. לכן המודל מקבל קודם את הפרוסה הנכונה מהסכימה שלכם.
כל דבר עם סכום, דירוג, פילוח או טווח תאריכים.
הטפסים שהוא צריך, המסננים שנותנים להם משמעות, והדרך שבה הם מתחברים, מתוך מפה של ההתקנה שלכם.
הוא מנסח את השאילתה בעצמו, מול כללי הדיאלקט שקיבל.
נבדק מול אותה מפה לפני שמשהו רץ.
רצה בערוץ הקריאה-בלבד, והתשובה חוזרת לשיחה.
הטיפול ב־SQL תלוי במסלול השאילתה. מסלול משתמש הקצה בודק שאילתה מובנית ומייצר ממנה SQL מוגבל לקריאה. מסלול המנהלים, הדורש הרשאה נפרדת, מקבל SQL גולמי ובודק אותו לפני ההרצה.
המפה הזאת נבנית מה-Priority שלכם על ידי BI Generator: כל טבלה, עמודה וטופס, איך הם מתחברים, ומה כל שדה באמת אומר — כולל כל מה שאיש היישום שלכם בנה. הטבלה הייעודית שמאחורי תהליך בקרת האיכות שלכם והעמודות שמישהו הוסיף לשורת ההזמנה נמצאות על המפה לצד הסטנדרטיות. מודל שמסתמך על ידע כללי ב-Priority לא יידע בכלל שהן קיימות; מודל שמקבל את ההקשר הזה עונה עליהן כבר בניסיון הראשון.
הבקרות הן אלה שכבר קיימות ב-Priority. תפקיד ה-Gateway הוא לחשוף אותן, לא להמציא אותן מחדש.
| כשהמודל… | מה קורה בפועל |
|---|---|
| קורא נתונים | פעולות נתונים ב־OData וב־WebSDK משתמשות בזהות Priority המחוברת. SQLI עם בקרת הרשאות בודק את גישת המשתמש המאומת לטפסים ומריץ את השאילתה שאושרה באמצעות ה־Master של הסביבה. היקף ההגנה תלוי בהגדרות האכיפה ואינו משחזר כל הגבלת מסך או שדה. |
| כותב SQL | ערוץ ה-SQL הוא לקריאה בלבד מעצם המבנה. הפעולות INSERT, UPDATE, DELETE ושאר פעולות השינוי נדחות לפני שהשאילתה יוצאת מה-Gateway. |
| יוצר או מעדכן רשומה | הכתיבה עוברת דרך הטופס של Priority עצמו, ולכן כל הבדיקות, כללי העסק והטריגרים רצים. שום דבר לא נכתב ישירות לטבלה. |
| נתקל באזהרה של Priority | נוסח האזהרה עולה לשיחה במקום להיבלע. מישהו מאשר או מבטל, והשמירה ממתינה. |
| מגיע לדיאלוג אישור | אתם בוחרים לכל קריאה: לאשר, לבטל, להכשיל את הקריאה, או להעביר את נוסח הדיאלוג למודל ולתת לו להחליט בקול. |
| בוחר פרוטוקול לא נכון | מסמכי העזר הם חלק ממשטח הכלים. המודל בודק איזו טכנולוגיה מתאימה במקום לנחש, ומקבל רמז מתקן כששאילתה נתקלת בקיר מוכר. |
אותה נקודת קצה, אותם טוקנים. בחרו את זו שהאנשים שלכם כבר פותחים.
מדביקים כתובת ומתחברים. ההתחברות היא OAuth רגיל, והלקוח מסדר את השאר בעצמו.
# הוספת מחבר מותאם
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.