סקירה כללית על Model Context Protocol
במסמך הזה מפורטת סקירה כללית על התמיכה ב-Model Context Protocol (MCP) ב-API Gateway.
API Gateway יכול לשמש כשרת MCP מרוחק, וכך לאפשר לכם לחשוף את ממשקי ה-API הקיימים שלכם ל-REST לסוכני AI ולמודלים גדולים של שפה (LLM) בלי שתצטרכו לכתוב מחדש את השירותים לקצה העורפי.
רקע
Model Context Protocol (MCP) הוא תקן פתוח שמאפשר לכם ליצור סוכני AI ישירות על בסיס התשתית הקיימת שלכם. במקום לכתוב קוד שילוב בהתאמה אישית לכל כלי או API, MCP מספק דרך סטנדרטית למודלים של AI לגלות ולהפעיל פונקציונליות בסביבה שלכם.
כשמגדירים את API Gateway כשרת MCP, הוא פועל כ-proxy. הוא מתרגם הודעות סטנדרטיות של פרוטוקול JSON-RPC של MCP שנשלחות ממערכות מבוססות-סוכנים לבקשות HTTP REST סטנדרטיות שמופנות אל השרתים העורפיים הקיימים שלכם.
תכונות נתמכות
במהלך תקופת ה-Public Preview, API Gateway תומך בתכונות הבאות של MCP:
- שרת MCP מרוחק: API Gateway פועל כשרת מרוחק שמקבל בקשות MCP דרך HTTP (POST).
- שילוב של OpenAPI 3.x: הגדרות ה-MCP נגזרות ישירות מהמפרט של OpenAPI 3.x באמצעות תוספים בהתאמה אישית.
- שיטות נתמכות של מחזור החיים של MCP:
-
initialize: קובע את גרסת הפרוטוקול והיכולות. -
notifications/initialized: אישור הלחיצת יד. -
tools/list: מאפשר ללקוחות לגלות את הכלים הזמינים ואת הסכימות שלהם. -
tools/call: מאפשר ללקוחות להפעיל כלי עם ארגומנטים.
-
מגבלות
המגבלות הבאות חלות על תמיכה ב-MCP בשער API:
- אין תמיכה במשאבים (
resources/*) ובפרומפטים (prompts/*). - אין תמיכה בהעברה של Stdio.
- אין תמיכה ב-OpenAPI 2.0.
- אין תמיכה בסטרימינג או בהפעלת כלים לזמן ארוך.
- הדרה הדדית של ניתוב מודלים: אי אפשר להפעיל גם את MCP וגם את ניתוב המודלים באותה הגדרת API. אם המדיניות
x-google-api-management.mcpמופעלת, אי אפשר להשתמש במדיניותx-google-model-router.
רשימה מלאה של מגבלות טכניות מופיעה במאמר מגבלות התכונות של OpenAPI 3.x.
תרחישים לדוגמה
- חשיפת ממשקי REST API קיימים ככלים של MCP: אפשר להפוך ממשקי API קיימים לכלים שמוכנים לשימוש ב-AI בלי לשנות את קוד הקצה העורפי.
- בחירת כלים לכל פעולה: בחירה מפורשת של נתיבי API ושיטות שיהיו זמינים לסוכנים.
- הגנה על ממשק הכלי: צריך להחיל על נקודת הקצה של ה-MCP את מדיניות האבטחה הקיימת של API Gateway (כמו מפתחות API או OAuth).
תהליך הבקשה
הנתיב הקנוני לבקשות MCP הוא <basepath>/mcp, כאשר <basepath> נגזר מכתובת ה-URL של השער או מההגדרה של x-google-endpoint.
התרשים הבא מציג את זרימת הבקשות של בקשת MCP tools/call:
- לקוח MCP (לדוגמה, סוכן AI) שולח בקשת JSON-RPC לנקודת הקצה של ה-MCP של השער (לדוגמה,
POST /mcpאוPOST /v1/mcpאם נעשה שימוש בקידומת גרסה). - השער מאמת את הבקשה ובודק את האימות.
- השער בודק את מטען הנתונים כדי לקבוע לאיזה כלי מתבצעת קריאה.
- השער מתרגם את מטען ה-MCP לבקשת HTTP רגילה (נתיב, פרמטרים, גוף) על סמך המיפוי שמוגדר בהגדרת ה-API.
- השער מעביר את הבקשה לשירות הקצה העורפי.
- הבק-אנד מחזיר תגובת HTTP רגילה.
- השער מתרגם את תגובת ה-HTTP בחזרה לתגובת JSON-RPC של MCP ומחזיר אותה ללקוח.
חיפוש באמצעות API Hub ו-Agent Registry
אם משלבים את השער עם API Hub, השער עם MCP מתפרסם ב-API Hub כשרת MCP עם מטא-נתונים נוספים שספציפיים ל-MCP, והוא גם מופיע ב-Agent Registry באופן אוטומטי.
בשערי תשלום שבהם לא מופעל MCP, מתפרסמים מטא-נתונים סטנדרטיים של API. רק שערים שמופעל בהם MCP יציגו את הגדרות ה-MCP הנוספות האלה במרכז ה-API.
אין צורך בשלב הרשמה נפרד. הסוכנים יכולים למצוא את השרת ואת הכלים שלו דרך אחד מהקטלוגים.
כדי להריץ שאילתה ב-Agent Registry, צריך להפעיל את ה-API שלו בפרויקט:
gcloud services enable agentregistry.googleapis.com