MCP Reference: mapstools.googleapis.com

זהו שרת MCP שסופק על ידי כלים אג'נטיים בממשק Maps. השרת מספק למפתחים כלים ליצירת אפליקציות LLM על גבי Google Maps Platform.

שרת Model Context Protocol‏ (MCP) פועל כשרת proxy בין שירות חיצוני שמספק הקשר, נתונים או יכולות לבין מודל שפה גדול (LLM) או אפליקציית AI. שרתי MCP מחברים בין אפליקציות AI למערכות חיצוניות כמו מסדי נתונים ושירותי אינטרנט, ומתרגמים את התשובות שלהם לפורמט שאפליקציית ה-AI יכולה להבין.

הגדרת השרת

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

נקודות קצה של שרתים

נקודת קצה של שירות MCP היא כתובת הרשת וממשק התקשורת (בדרך כלל כתובת URL) של שרת ה-MCP, שבהם אפליקציית AI (המארח של לקוח ה-MCP) משתמשת כדי ליצור חיבור מאובטח וסטנדרטי. הוא משמש כנקודת הקשר של ה-LLM לבקשת הקשר, להפעלת כלי או לגישה למשאב.

לשרת ה-MCP של הכלים האג'נטיים בממשק מפות Google יש את נקודת הקצה הגלובלית הבאה של MCP:

• https://mapstools.googleapis.com/mcp

כלי MCP

כלי MCP הוא פונקציה או יכולת הפעלה ששרת MCP חושף לאפליקציית LLM או AI כדי לבצע פעולה בעולם האמיתי.

כלים

בשרת ה-MCP של mapstools.googleapis.com יש את הכלים הבאים:

כלי MCP
search_places	צריך להפעיל את הכלי הזה כשהמשתמש מבקש למצוא מקומות, עסקים, כתובות, מיקומים, נקודות עניין או כל חיפוש אחר שקשור למפות Google. דרישות קלט (קריטי): text_query (מחרוזת – חובה): שאילתת החיפוש הראשית. הוא צריך להגדיר בבירור מה המשתמש מחפש. דוגמאות: 'restaurants in New York', 'coffee shops near Golden Gate Park', 'SF MoMA', '1600 Amphitheatre Pkwy, Mountain View, CA, USA', 'pets friendly parks in Manhattan, New York', 'date night restaurants in Chicago', 'accessible public libraries in Los Angeles'. לפרטים ספציפיים על מקום: כוללים את המאפיין המבוקש (למשל, 'Google Store Mountain View opening hours',‏ 'SF MoMa phone number',‏ 'Shoreline Park Mountain View address'). location_bias (אובייקט – אופציונלי): משתמשים בפרמטר הזה כדי לתת עדיפות לתוצאות שקרובות לאזור גיאוגרפי מסוים. פורמט: {"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}} שימוש: כדי להטות לרדיוס של 5 ק"מ: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}, "radius_meters": 5000}}} כדי להטות את התוצאות באופן משמעותי לנקודת המרכז: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}}}} (השמטת radius_meters). language_code (מחרוזת – אופציונלי): השפה שבה יוצג סיכום תוצאות החיפוש. פורמט: קוד שפה בן שתי אותיות (ISO 639-1), ואחריו קו תחתון וקוד מדינה בן שתי אותיות (ISO 3166-1 alpha-2), למשל: en, ja, en_US, zh_CN, es_MX. אם לא תציינו קוד שפה, התוצאות יוצגו באנגלית. region_code (מחרוזת – אופציונלי): קוד האזור של המשתמש במאגר CLDR של Unicode. הפרמטר הזה משמש להצגת פרטי המקום, כמו שם המקום הספציפי לאזור, אם הוא זמין. הפרמטר יכול להשפיע על התוצאות בהתאם לדין החל. פורמט: קוד מדינה בן שתי אותיות (ISO 3166-1 alpha-2), למשל US, CA. ‫page_size (מספר שלם – אופציונלי): המספר המקסימלי של מקומות שיוחזרו, מ-1 עד 10. ברירת המחדל היא 5. כדאי להגדיר ערך גבוה מ-5 רק כשהמשתמש רוצה להשוות בין יותר מ-5 מקומות. ערכים בין 6 ל-10 כרוכים בעלות גבוהה יותר ובזמן אחזור ארוך יותר. include_extended_details (בוליאני – אופציונלי): מגדירים את השדה הזה כ-true כשהבקשה של המשתמש דורשת תובנות איכותיות עשירות, דינמיקה בזמן אמת או מאפייני ישות מיוחדים. ברירת המחדל היא false. הגדרה של true תגרום לעלויות גבוהות יותר ולזמן אחזור ארוך יותר. הוראות לקריאת API לכלי: נתוני מיקום (קריטי): החיפוש חייב להכיל מספיק נתוני מיקום. אם המיקום לא ברור (למשל, רק "פיצריות"), חובה לציין אותו בפרמטר text_query (למשל, "פיצריות בניו יורק") או להשתמש בפרמטר location_bias. כדי למנוע בלבול, צריך לכלול את שם העיר, המדינה/המחוז והאזור/המדינה. תמיד צריך לספק את ה-text_query הכי ספציפי ועשיר בהקשר שאפשר. צריך להשתמש ב-location_bias רק אם הקואורדינטות צוינו במפורש או אם מתאים להסיק את המיקום מההקשר הידוע של המשתמש וגם אם זה נחוץ כדי לקבל תוצאות טובות יותר. צריך לשייך את הפלט המבוסס למקור באמצעות המידע מהשדה attribution, אם הוא זמין.
lookup_weather	אחזור מידע סביבתי מקיף על מיקום מסוים, כולל מזג אוויר, איכות האוויר (AQI ומזהמים) ואבקנים (רמות אלרגנים של עצים, דשא, עשבים וצמחים): תנאים נוכחיים, תחזיות/היסטוריה לפי שעה ותחזיות יומיות של מזג האוויר ואיכות האוויר. לגבי אבקנים, התחזית היא יומית בלבד (מהיום ועד 4 ימים קדימה, ללא נתונים לפי שעה או נתונים מהעבר). תחומים ויכולות סביבתיים זמינים (capabilities: WEATHER, AIR_QUALITY, POLLEN — קריטי): * בחירה מפורשת חובה: חובה לכלול לפחות אחד מהערכים WEATHER, AIR_QUALITY או POLLEN ב-capabilities בכל קריאה. אסור להשמיט את capabilities. * שאילתות רחבות או מעורפלות לגבי תנאי הסביבה (חבילת Ambient Outdoor מלאה): אם המשתמש שואל שאלה כללית לגבי תנאי הסביבה, נסיעות או מצב מסוים בלי להגביל את השאלה לתחום ספציפי (למשל, "מהם תנאי הסביבה כרגע לריצה?"), צריך לכלול במפורש את כל שלוש היכולות (capabilities: ["WEATHER", "AIR_QUALITY", "POLLEN"]) כדי להחזיר את חבילת Ambient Outdoor המלאה (מזג אוויר + איכות האוויר + אבקנים). אם השאלה היא לגבי העבר (date או hour), צריך להשמיט את POLLEN כי אין לו היסטוריה. ‫* בחירת דומיין ממוקד (שאילתות ספציפיות): אם המשתמש מבקש באופן ספציפי רק דומיין אחד או שניים (למשל, "מהו מדד איכות האוויר בסיאטל כרגע?"), צריך לכלול רק את היכולות המבוקשות (WEATHER,‏ AIR_QUALITY ו/או POLLEN). רק הדומיינים המבוקשים יופעלו ויוחזרו. נתונים ספציפיים שזמינים לפי דומיין: * מזג אוויר (weather): טמפרטורה (נוכחית, מרגישה כמו, מקסימום/מינימום, מדד חום), רוח (מהירות, משבים, כיוון), אירועים שמימיים (זריחה/שקיעה, מופע הירח), משקעים (סוג, סבירות, כמות/QPF) ותנאים אטמוספריים (מדד קרינת UV, לחות, כיסוי עננים, סבירות לסופת רעמים, לחץ אוויר). ‫* איכות האוויר (air_quality): מדדי איכות אוויר אוניברסליים ומקומיים (ערך AQI, קטגוריה, מזהם דומיננטי), המלצות בריאותיות ל-7 קבוצות רגישות וריכוזי מזהמים (include_pollutant_concentration: true). לכל מדד יש מזהם דומיננטי משלו. צריך לדווח עליו לכל מדד (למשל, לא לתת את המזהם של מדד איכות האוויר האוניברסלי למדד איכות האוויר בארה"ב). * אבקת פרחים (pollen): מדד אבקת פרחים אוניברסלי (UPI,‏ 0-5) יומי לפי קטגוריות של עצים, דשא ועשבים שוטים ולפי מיני צמחים (index.value עם index.category, למשל 1 = "נמוך מאוד"), סטטוס עונתי, תגובות צולבות והמלצות בריאותיות. * שדות חסרים של אבקנים: אם השדה in_season חסר, סימן שזו לא העונה. אל תכלול מיני צמחים שהוחזרו בלי index, אלא אם המשתמש שואל על הצמח הזה. במקרה כזה, ציין שלא דווחו היום נתונים על אבקנים לגביו (אל תסיק מה הרמה). כללי מיקום (קריטי): צריך לציין את מיקום היעד הגיאוגרפי ב-location באמצעות רק אחד משדות המשנה הבאים של oneof: 1. קואורדינטות גיאוגרפיות (lat_lng): * משתמשים באפשרות הזו כשיודעים את הקואורדינטות המדויקות של קו הרוחב וקו האורך. ‫* דוגמה: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} 2. מזהה מקום (place_id): * מזהה מקום חד-משמעי במפות Google (למשל, מזהה שהתקבל מ-search_places או מ-resolve_names). * דוגמה: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} 3. מחרוזת כתובת (address): * עיר/אזור, שכונה, ציון דרך או נקודת עניין, כתובת או מיקוד, רצוי עם העיר/המדינה. * דוגמה: {"location": {"address": "Paris, France"}} מצבי זמן ושימוש (date ו-hour — קריטי): * הפניה לאזור זמן מקומי: כל הקלטים של date ({year, month, day}) ו-hour (0-23) חייבים להיות מבוטאים באזור הזמן האזרחי המקומי של location המבוקש (לדוגמה, שאילתה עבור "Paris tomorrow at 13:00" משתמשת בתאריך ובשעה המקומיים של Europe/Paris 13), אף פעם לא ב-UTC או באזור הזמן של המתקשר. * ‫1. התנאים הנוכחיים (date הושמט וגם hour הושמט): * צריך לציין את location ואת היעד capabilities (WEATHER, AIR_QUALITY, POLLEN). אין לציין את date או את hour. ‫* מחזירה את התנאים הנוכחיים (CC) בזמן אמת לדומיינים המבוקשים (מזג האוויר הנוכחי, איכות האוויר בשעה הנוכחית ו/או תחזית האבקנים להיום). ‫* באיכות האוויר, התנאים הנוכחיים מתייחסים לשעה אחת: אין להשתמש בהם לבד כדי לענות על שאלות לגבי איכות האוויר או שאלות כלליות לגבי מזג האוויר בחוץ היום (צריך להשתמש בשאילתות היומיות שבהמשך). * ‫2. תחזית/היסטוריה לפי שעה (צוינו date וגם hour 0-23): * צריך לציין את location, date ({year, month, day}), hour (0-23) ואת היעד capabilities. אם מוזכרות דקות, מעגלים כלפי מטה לשעה הקרובה. ‫* אילוץ קריטי (חובה לציין את date כשמגדירים את hour): אסור לציין את hour בלי date (date הושמט, hour הוגדר), והפעולה תיכשל עם שגיאה. גם כשהמשתמש שואל על שעה ספציפית היום (למשל, "at 13:00 today"), חובה לאכלס גם את date (התאריך של היום בשעה location) וגם את hour. * מבצע חיפוש מדי שעה של נתוני מזג האוויר ו/או איכות האוויר המבוקשים ב-YYYY-MM-DD-HH וחיפוש יומי של נתוני האבקנים המבוקשים ב-YYYY-MM-DD. ‫* שאלות "מתי" לגבי מזג האוויר: בשאלות על מזג האוויר שכוללות את המילים מתי / באיזו שעה / הזמן הכי טוב (למשל, "what time will it stop raining?"), צריך להשתמש בקריאות WEATHER לפי שעה (date + hour) לשעות הרלוונטיות. בתחזית מזג אוויר יומית אין ערכים לפי שעה. לשאילתות כלליות על פעילויות בחוץ שכוללות את המילים "מתי / הזמן הכי טוב" (למשל, "when is the best time to go walking today?"), צריך לבצע את הקריאות השעתיות האלה ל-WEATHER בנוסף לקריאה היומית לאיכות האוויר (ולאבקנים) שמתוארת בקטע "שאילתות יומיות". * ‫3. ‫שאילתות יומיות (date צוין ו-hour הושמט): * צריך לציין את location, date ({year, month, day} בזמן האזרחי המקומי של location המבוקש) בלי hour, ואת capabilities היעד לשאילתות של יום שלם (למשל, "weather and pollen in London tomorrow"). * שאלות על איכות האוויר ושאלות כלליות על מזג האוויר בחוץ היום: לשאלות על איכות האוויר ושאלות כלליות על מזג האוויר בחוץ (כולל איכות האוויר) לגבי היום (למשל, "how will the air quality change today", "is today a good day for a picnic?"), צריך להגדיר את date לתאריך של היום ב-location (השעה הושמטה) כדי לקבל את סדרת הנתונים השעתית של איכות האוויר לאותו יום. קריאה ל-Current Conditions לבדה מחזירה רק את השעה הנוכחית של איכות האוויר וזה לא מספיק. אפשר להוסיף קריאה כזו אם המשתמש שואל גם על "עכשיו". * חלונות זמן של איכות האוויר: אם יש שאלה לגבי איכות האוויר בחלון זמן מסוים ביום אחד (למשל, "air quality between noon and 6 PM"), עדיף לבצע קריאה אחת של Daily לתאריך הזה ולקרוא את השעות של חלון הזמן מסדרת Air Quality, במקום לדגום שעות ספציפיות. אם אתם משתמשים בקריאות לפי שעה, צריך לכסות כל שעה בחלון הזמן. * מחזירה תחזיות יומיות לגבי מזג האוויר ו/או Pollen המבוקשים, וסדרת נתונים שעתית של איכות האוויר באותו יום שמכסה את כל היום המקומי (00:00 עד 23:00 לפי השעון המקומי): 24 שעות היסטוריות לתאריך קודם, 24 שעות חזויות לתאריך עתידי, ולגבי היום – השעות המוקדמות יותר (היסטוריה), השעה הנוכחית והשעות שנותרו (תחזית). טווחי הזמן הנתמכים לפי תחום: * מזג אוויר: תחזית שעתית מ-24 שעות אחורה ועד 240 שעות (10 ימים) קדימה (שעות בעבר צריכות גם את date וגם את hour); תחזית יומית עד 10 ימים כולל היום (מהיום ועד 9 ימים קדימה); אין היסטוריה יומית. * איכות האוויר: כל שעה, החל מ-720 שעות (30 ימים) בעבר ועד 96 שעות (4 ימים) בעתיד. קריאה של יום שלם חייבת להתאים לחלון הזה (בפועל, היום, 29- ימים עד 3+ ימים). * אבקנים: תחזית יומית בלבד, מהיום ועד 4 ימים קדימה (5 ימים כולל היום). אין תאריכים קודמים, והמערכת מתעלמת מהפרמטר hour. * (הערה: אם מבוקשות מספר יכולות וה-date/hour נמצא מחוץ לאחד מהטווחים שלהן, הקריאה עדיין תצליח ותחזיר רק את התכונות הנתמכות.) * בקשות מחוץ לטווח: אם התאריך או השעה המבוקשים עשויים להיות מחוץ לטווח הנתמך של הדומיין שלמעלה (למשל, Pollen לתאריך בעבר), עדיין צריך להתקשר אל lookup_weather עבור התאריך או השעה המבוקשים. השגיאה מציינת את הטווח הנתמך. אל תציינו תאריך, שעה או דומיין אחרים במקום. אפשרויות דומיין ושיוך: * שפה (language_code): קוד שפה אופציונלי בתקן BCP-47 (למשל, "fr"). ברירת המחדל היא "en". * יחידות של מזג האוויר (weather_options.units_system או units_system): ברירת המחדל היא METRIC. מגדירים את הערך IMPERIAL (פרנהייט/מייל לשעה) אם המשתמש מתכוון לסטנדרטים של ארה"ב או מבקש במפורש יחידות אימפריאליות. נתמך גם ב-weather_options.units_system (מועדף) וגם ברמה העליונה של units_system. אם שניהם צוינו, הם לא יכולים לסתור זה את זה. ‫* אפשרויות איכות האוויר (air_quality_options): מגדירים את include_pollutant_concentration: true כשצריך ריכוזים של מזהמים ספציפיים (PM2.5,‏ PM10,‏ O3,‏ NO2,‏ SO2,‏ CO). אפשר גם להגדיר את index_region_code (קוד מדינה בן 2 אותיות לפי תקן ISO, למשל "US") כדי לבקש סולם AQI אזורי ספציפי. כברירת מחדל, התגובה כוללת את מדד איכות האוויר האוניברסלי ואת מדד איכות האוויר האזורי של המיקום. ‫* שיוך (Attribution): חובה לשייך את הפלט המבוסס למקור באמצעות השדה attribution בתוך כל מאגר דומיינים שמוחזר (weather.attribution,‏ air_quality.attribution,‏ pollen.attribution). * השעות שמוחזרות: ערכי date_time של איכות האוויר כבר מופיעים בשעון המקומי של המיקום (כולל utc_offset). צריך להציג אותם כמו שהם. ערכי date_time של מזג האוויר (הנוכחי והשעתי) ושעות הזריחה/השקיעה הם ב-UTC. צריך להמיר אותם לשעון המקומי של המיקום באמצעות time_zone. כל השעות מסומנות כשעות מקומיות.
compute_routes	מחשב מסלולי נסיעה בין נקודת מוצא ליעד, עם אפשרות לעצירות ביניים. הפונקציה מחזירה את המרחק ומשך הזמן של כל מסלול. דרישות קלט (קריטי): ‫origin ו-destination (אובייקטים – חובה): צריך לספק כל אחד מהם באמצעות אחד מהאפשרויות הבאות: ‫address (מחרוזת, למשל 'Eiffel Tower, Paris'). מקומות עם שם, ציוני דרך ועסקים מזוהים ישירות, לכן אין צורך להפעיל קודם את search_places רק כדי להמיר את הכתובת של נקודת הדרך לקואורדינטות. ציינו את העיר, האזור או המדינה שהמשתמש הזכיר. ‫lat_lng (אובייקט, {"latitude": number, "longitude": number}). place_id (מחרוזת, למשל 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'), לדוגמה מ-search_places. intermediate_waypoints (מערך של אובייקטים – אופציונלי): עד 25 עצירות שצריך לעבור בהן, לפי הסדר, בין נקודת המוצא ליעד. אותו פורמט כמו origin. אין תמיכה ב-TRANSIT. צריך לכלול רק עצירות שהמשתמש ביקש. אם מציינים יותר מ-10 נקודות ציון ביניים, העלות והזמן האחזור יהיו גבוהים יותר. ‫travel_mode (enum – אופציונלי): DRIVE (ברירת מחדל), WALK, BICYCLE או TRANSIT. תזמון (אופציונלי – אפשר להגדיר לכל היותר אחד): חותמות זמן בפורמט RFC 3339 עם הפרש שעות מ-UTC, למשל '2026-09-19T08:00:00-07:00'. ברירת המחדל היא יציאה עכשיו. בשדה TRANSIT, אפשר להזין תאריך עד 7 ימים בעבר או עד 100 ימים בעתיד. במצבים אחרים, אפשר להגדיר את הזמן עד 365 ימים בעתיד, והוא לא יכול להיות בעבר. ‫departure_time: משתמשים בפרמטר הזה כשהמשתמש מציין מתי הוא ייצא (למשל, "מחר ב-8:00"). ‫arrival_time: משתמשים בפרמטר הזה כשהמשתמש מציין מתי הוא צריך להגיע (לדוגמה, "להיות שם עד 9:00"). routing_preference (enum - OPTIONAL): ROUTING_PREFERENCE_TRAFFIC_UNAWARE (ברירת המחדל): המערכת מתעלמת ממצב התנועה בזמן אמת, מאירועי תנועה ומחסימות כבישים. זמן האחזור הכי קצר. ‫ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: משתמש במצב התנועה בזמן אמת, אם הוא זמין. הפעולה הזו לא נתמכת ב-WALK או ב-BICYCLE. צריך להגדיר את זה רק כשהמשתמש שואל על התנועה, על עומס תנועה או על זמן הגעה משוער שמותאם לתנועה. היא כרוכה בעלות גבוהה יותר ובזמן אחזור ארוך יותר. ‫location_bias (אובייקט – אופציונלי): {"latitude": number, "longitude": number} משמש להפגת עמימות של שמות מקומות בכתובות של נקודות דרך. אם השם לא חד-משמעי (למשל, "Springfield") והמשתמש לא ציין אזור, צריך להשאיר את השם כמו שהוא ב-address ולהגדיר את location_bias לאזור הרצוי במקום לנחש את האזור. ‫compute_alternative_routes (בוליאני – אופציונלי): מגדירים את הערך true רק כשהמשתמש מבקש אפשרויות או חלופות למסלול. ברירת המחדל היא false, והיא מחזירה רק את המסלול המומלץ. include_polyline (בוליאני – אופציונלי): מגדירים את הערך true רק כשצריך את הגיאומטריה של המסלול (encoded_polyline). ברירת המחדל היא false. הוראות לקריאת API לכלי: אם חסר מקור או יעד, חובה לבקש מהמשתמש הבהרה לפני שמפעילים את הכלי. בשאלות כמו "מה המרחק בין א' לב'?", צריך להשתמש ב-ב' בתור origin וב-א' בתור destination. דוגמה לקריאת API לכלי: {"origin":{"address":"Eiffel Tower"},"destination":{"place_id":"ChIJt_5xIthw5EARoJ71mGq7t74"},"intermediate_waypoints":[{"address":"Louvre Museum"}],"travel_mode":"DRIVE","departure_time":"2026-09-19T08:00:00+02:00"} הוראות למענה: כשמבקשים מסלולים חלופיים, המסלולים מסודרים מהמומלץ ביותר לפחות מומלץ. אם routes ריק, צריך להגיד למשתמש שלא נמצא מסלול. אל תנחשו מסלול. כדי למצוא מקומות לאורך מסלול של DRIVE, מעבירים את ה-retrieval_token של המסלול אל search_along_route. האסימון תקף למשך 10 דקות. צריך לציין רק עובדות שהכלי החזיר. אל תמציאו מסלולים מפורטים, קווי תחבורה ציבורית, תחנות, רציפים או החלפות קווים. הפלט המעוגן חייב להיות משויך למקור באמצעות השדה attribution של כל מסלול, אם הוא זמין.
search_along_route	צריך להפעיל את הכלי הזה כשהמשתמש רוצה למצוא מקומות, עסקים או נקודות עניין לאורך מסלול נסיעה (למשל, "תחנות דלק בדרך לטבריה", "בתי קפה בין תל אביב לחיפה"). הפעלת הכלי הזה כרוכה בעלות גבוהה יותר מאשר search_places, לכן כדאי להשתמש ב-search_places כשמחפשים ליד מיקום אחד ולא לאורך מסלול. דרישות קלט (קריטי): text_query (מחרוזת – חובה): תיאור בשפה טבעית של מה שרוצים לחפש לאורך המסלול. לדוגמה: 'ev chargers',‏ 'coffee',‏ 'vegetarian restaurants',‏ 'rest stops'. מפרט המסלול (חובה – צריך לספק בדיוק אחת מהאפשרויות הבאות): ‫retrieval_token (מחרוזת): הערך של retrieval_token שהוחזר על ידי קריאה קודמת של compute_routes למסלול DRIVE. עדיף להשתמש בזה בכל פעם שהמסלול כבר חושב. האסימון תקף למשך 10 דקות. route_endpoints (אובייקט): ה-origin וה-destination של המסלול. צריך לספק כל אחד מהם באמצעות אחת מהאפשרויות הבאות: address,‏ lat_lng או place_id. לדוגמה: {"route_endpoints": {"origin": {"address": "San Francisco, CA"}, "destination": {"address": "Lake Tahoe, CA"}}} ‫encoded_polyline (מחרוזת): קו פוליגוני מקודד שמייצג מסלול של DRIVE. ‫travel_mode (enum – אופציונלי): DRIVE (ברירת מחדל), WALK או BICYCLE. האפשרויות WALK ו-BICYCLE נתמכות רק עם route_endpoints. אין תמיכה ב-TRANSIT. routing_preference (enum - OPTIONAL): ROUTING_PREFERENCE_TRAFFIC_UNAWARE (ברירת המחדל): חישוב המסלול ודרכים חלופיות בלי עדכוני תנועה בזמן אמת. זמן האחזור הכי קצר. ‫ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: משתמש במצב התנועה בזמן אמת, אם הוא זמין. הפעולה הזו לא נתמכת ב-WALK או ב-BICYCLE. צריך להגדיר את זה רק כשהמשתמש שואל על עומסי תנועה או על זמני נסיעה בדרכים חלופיות בהתאם לעומסי התנועה. הוא גורם לזמן אחזור ארוך יותר. ‫include_extended_details (בוליאני – אופציונלי): צריך להגדיר את הערך true רק כשהבקשה דורשת תובנות איכותיות, פריטים או מבצעים ספציפיים בתפריט, אווירה, טיפים למבקרים או רמת עומס, זמינות של מטען לרכב חשמלי, מחירי דלק או פרטים איכותיים עשירים אחרים. ברירת המחדל היא false. הפעלת ההגדרה הזו עלולה להאריך את זמן האחזור. ‫language_code (מחרוזת – אופציונלי): השפה של סיכום התוצאות ופרטי המקום, למשל en,‏ ja,‏ en-US. ברירת המחדל היא en-US. region_code (מחרוזת – אופציונלי): קוד האזור של המשתמש לפי Unicode CLDR, למשל US,‏ CA. הוראות לקריאת API לכלי: כל תוצאה כוללת detour_summary (אם זמין) שמתאר את המרחק הנוסף (localized_detour_distance) ואת הזמן הנוסף (detour_duration) שיידרש כדי לעצור במקום הזה, אלא אם המסלול ניתן בתור encoded_polyline. אפשר להשתמש בו כדי להשוות בין אפשרויות. התשובה summary עשויה להכיל ציטוטים שמבוססים על אפס (למשל, "[0]") שמפנים לרשומות ב-results. הפלט המבוסס-קרקע חייב להיות משויך למקור באמצעות השדה attribution של כל results[].place, אם הוא זמין.
resolve_names	הופך רשימה של שאילתות מיקום ספציפיות (שמות של ציוני דרך או כתובות מדויקות) למזהי מקומות קנוניים במפות Google. דרישות קלט (קריטי): queries (מערך של אובייקטים – חובה): רשימה של שאילתות מיקום שצריך לפתור. אפשר לציין עד 20 שאילתות. כל אובייקט שאילתה חייב לכלול: text (מחרוזת – חובה): שאילתת הטקסט שמייצגת שם או כתובת של מקום ספציפי שרוצים לפתור. דוגמאות: 'Googleplex, Mountain View, CA',‏ '1600 Amphitheatre Pkwy, Mountain View, CA',‏ 'Eiffel Tower, Paris'. location_bias (אובייקט – אופציונלי): משתמשים בפרמטר הזה כדי לתת עדיפות לתוצאות שקרובות לאזור גיאוגרפי מסוים. פורמט: {"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}} ‫region_code (מחרוזת – אופציונלי): קוד האזור של המשתמש במאגר CLDR של Unicode (קוד מדינה בן שתי אותיות, למשל US,‏ CA) כדי להטות את התוצאות. הוראות לקריאת API לכלי: ספציפיות (קריטי): השאילתות חייבות לייצג שם או כתובת של מקום ספציפי. אין תמיכה בחיפושים כלליים כמו 'restaurants' או בשמות של רשתות כמו 'Starbucks'. אל תפעילו את הכלי הזה אם הכלים הבאים שאתם מתכננים להפעיל כבר מקבלים ישירות מחרוזות של כתובות או שמות של מקומות. שמירה במפות Google: התשובה כוללת את השדה save_to_maps_url: קישור אחד למפות Google שמכיל את כל המקומות שנמצאו. כשהמשתמש רוצה לשמור, לשתף או לפתוח את המקומות שנמצאו כרשימה במפות Google, צריך להציג לו את הקישור הזה. אל תיצרו את הקישור הזה בעצמכם. טיפול בשגיאות (קריטי): זהו כלי לעיבוד ברצף (batch processing). יכול להיות שבקשה תחזיר "תוצאות מעורבות" (למשל, חלק מהשאילתות נפתרות בהצלחה ואחרות נכשלות). רשימת הפלט של results ממופה באופן ודאי ביחס של 1:1 לאינדקסים של הקלט queries. שאילתה שנכשלה תגרום להודעת Result ריקה (לא מוגדר entity) באינדקס התואם שלה ברשימה results. חובה לבדוק את השדה failed_requests בתגובה כדי לזהות את אינדקס השאילתה הספציפי שנכשל. המפתח של failed_requests מייצג את האינדקס מבוסס-האפס של השאילתה שנכשלה בבקשה. אל תניחו שכל הקריאה באצווה נכשלה בגלל כישלון חלקי.
resolve_maps_urls	הפונקציה פותרת רשימה של כתובות URL במפות Google למזהי מקומות קנוניים במפות Google. מתי להפעיל את הכלי הזה (חשוב מאוד): השתמש בכלי הזה כשהמשתמש מספק כתובת URL אחת או יותר או קישור אחד או יותר לשיתוף במפות Google (למשל, "https://maps.app.goo.gl/...‎", ‫'https://www.google.com/maps/place/...‎' או 'https://maps.google.com/...‎') ואתם צריכים לחלץ את מזהי המקומות הקנוניים הבסיסיים. אפשר לציין עד 20 כתובות URL לפתרון בבקשת Batch אחת. דרישות קלט (קריטי): urls (מערך של מחרוזות – חובה): רשימת כתובות ה-URL של מפות Google שצריך לפתור. כל כתובת URL צריכה להיות כתובת URL תקינה של מקום אחד במפות Google. שמירה במפות Google: התשובה כוללת את השדה save_to_maps_url: קישור אחד למפות Google שמכיל את כל המקומות שנמצאו. כשהמשתמש רוצה לשמור, לשתף או לפתוח את המקומות שנמצאו כרשימה במפות Google (למשל, לאסוף מקומות ששותפו בשיחה), צריך להציג למשתמש את הקישור הזה. אל תיצרו את הקישור הזה בעצמכם. טיפול בשגיאות (קריטי): זהו כלי לעיבוד ברצף (batch processing). יכול להיות שבקשה תחזיר "תוצאות מעורבות" (למשל, חלק מכתובות ה-URL נפתרות בהצלחה ואחרות נכשלות). רשימת הפלט של entities ממופה באופן ודאי ביחס של 1:1 לאינדקסים של הקלט urls. אם פתרון כתובת ה-URL נכשל, תתקבל הודעת Entity ריקה (לא הוגדרו שדות) באינדקס התואם ברשימה entities. חובה לבדוק את השדה failed_requests בתגובה כדי לזהות את האינדקס של כתובת ה-URL הספציפית שנכשלה. המפתח של failed_requests מייצג את האינדקס מבוסס-האפס של כתובת ה-URL שנכשלה בבקשה. אל תניחו שכל הקריאה באצווה נכשלה בגלל כישלון חלקי.

קבלת המפרט של כלי ה-MCP

כדי לקבל את המפרטים של כל הכלים בשרת MCP, משתמשים ב-method‏ tools/list. בדוגמה הבאה מוסבר איך להשתמש ב-curl כדי להציג את כל הכלים והמפרטים שלהם שזמינים כרגע בשרת ה-MCP.

בקשת Curl
curl --location 'https://mapstools.googleapis.com/mcp' \ --header 'content-type: application/json' \ --header 'accept: application/json, text/event-stream' \ --data '{ "method": "tools/list", "jsonrpc": "2.0", "id": 1 }'