רכז את הגישה MCP עם Durin

למה לרכז חיבורי MCP?

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

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

לפני: כל לקוח מתחבר למערכות במעלה הזרם באופן עצמאי. לאחר: לקוחות משתמשים בנקודות קצה משלהם ב-Durin ובקבוצה משותפת של בקרות חיבור. השביל הישיר המקווקו עדיין מגיע למערכת במעלה הזרם מבלי לחצות את Durin; הבעלים שלו חייב לשלוט על נתיב זה בנפרד.

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

שמור את הנתיבים הישירים במלאי זה. משתמש עם אישור ספק נפרד עדיין עשוי להגיע לאותה מערכת מחוץ ל-Durin. תצורת הלקוח, ההרשאות במעלה הזרם וכל בקרות הרשת נשארות חלק מההשקה. שיחה מבוקרת מוצלחת מוכיחה שהמסלול עובד; זה לא מוכיח שכל מסלול אחר נסגר.

איך הארכיטקטורה משתלבת

לקוח הבינה המלאכותית מציע קריאת כלי. Durin מקבל את הבקשה בנקודת הקצה האישית של MCP ומאמת את המבקש. נקודת הקצה שייכת לחשבון זה: ידיעת הכתובת שלה אינה מאשרת לאדם אחר להשתמש בה. כניסה לדפדפן ולקוח MCP מאומת הם שלבים נפרדים.

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

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

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

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

מה קורה כשסוכן מתקשר לכלי?

התחל בקריאה לא מזיקה: sandbox__read_document עם הנדסת משאבים/מדריך. הלקוח מגיש את שם הכלי והטיעונים; Durin מעריך אם מבקש זה יכול לבצע שיחה זו כעת.

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

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

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

חבר לקוח ל-Durin

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

1. בסביבת העבודה האישית, פתחו את החיבורים והרחיבו את אזור חיבור הסוכנים. חפשו את נקודת הקצה האישית שלכם ל-MCP. אם נדרש, הגדירו את נקודת הקצה ולאחר מכן העתיקו את כתובת ה-URL. שמרו את הכתובת המועתקת המשויכת לחשבון שלכם.
2. פתח חיבורים ← זמין ובקש ארגז חול Durin. מנהל מערכת פותח את הבקשה באישורים ובוחר באישור בקשה. זה יוצר את ארגז החול במידת הצורך. מדיניות הגישה הקיימת עדיין חלה; ארגז חול מושבת זקוק למנהל מערכת כדי להפעיל אותו.
3. הוסף את נקודת הקצה שהעתקת ללקוח MCP שלך. הפקודה Claude Code למטה מגיעה מאותו מחולל הגדרות המשמש את האתר. החלף את YOUR_PERSONAL_ENDPOINT_ID במזהה בכתובת האתר המועתקת שלך.

claude mcp add --transport http --scope user durin 'https://mcp.getdurin.com/mcp/u/YOUR_PERSONAL_ENDPOINT_ID'

פתח את Claude Code והשתמש ב-/mcp כדי לאמת את Durin.

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

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

בקש מהלקוח להתקשר ל-sandbox__read_document עם הנדסת משאבים/מדריך. תגובה מוצלחת מחזירה את המדריך להנדסת ארגז חול. בדוק את הפעילות עבור הבקשה ותוצאותיה; בקש ממנהל לבדוק את ראיות הביקורת של הארגון כאשר אתה זקוק לתצוגה הרחבה יותר.

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

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

טפל בכתבים רגישים בכוונה

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

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

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

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

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

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

הבן את הגבול לפני ההשקה

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

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

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

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

הרחב לאחר שהצוות שלך יכול להסביר את המסלול, את החלטת ההרשאה ואת התוצאה של ניסיון.