MCP Reference: mapstools.googleapis.com

यह एक एमसीपी सर्वर है, जिसे Maps Experience एजेंट टूल उपलब्ध कराते हैं. यह सर्वर, डेवलपर को Google Maps Platform पर एलएलएम ऐप्लिकेशन बनाने के लिए टूल उपलब्ध कराता है.

मॉडल कॉन्टेक्स्ट प्रोटोकॉल (एमसीपी) सर्वर, किसी बाहरी सेवा और लार्ज लैंग्वेज मॉडल (एलएलएम) या एआई ऐप्लिकेशन के बीच प्रॉक्सी के तौर पर काम करता है. यह बाहरी सेवा, एलएलएम या एआई ऐप्लिकेशन को कॉन्टेक्स्ट, डेटा या सुविधाएं उपलब्ध कराती है. एमसीपी सर्वर, एआई ऐप्लिकेशन को डेटाबेस और वेब सेवाओं जैसे बाहरी सिस्टम से कनेक्ट करते हैं. साथ ही, उनके जवाबों को ऐसे फ़ॉर्मैट में बदलते हैं जिसे एआई ऐप्लिकेशन समझ सके.

सर्वर का सेटअप

इस्तेमाल करने से पहले, आपको एमसीपी सर्वर चालू करने होंगे और पुष्टि करने की सुविधा सेट अप करनी होगी. Google और Google Cloud के रिमोट एमसीपी सर्वर इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Google Cloud के एमसीपी सर्वर की खास जानकारी देखें.

सर्वर एंडपॉइंट

एमसीपी सेवा एंडपॉइंट, एमसीपी सर्वर का नेटवर्क पता और कम्यूनिकेशन इंटरफ़ेस (आम तौर पर एक यूआरएल) होता है. इसका इस्तेमाल एआई ऐप्लिकेशन (एमसीपी क्लाइंट के लिए होस्ट) सुरक्षित और स्टैंडर्ड कनेक्शन बनाने के लिए करता है. यह एलएलएम के लिए संपर्क का पॉइंट होता है. इसकी मदद से, एलएलएम कॉन्टेक्स्ट का अनुरोध कर सकता है, किसी टूल को कॉल कर सकता है या किसी संसाधन को ऐक्सेस कर सकता है.

Maps एक्सपीरियंस एजेंट टूल के एमसीपी सर्वर में, यह ग्लोबल एमसीपी एंडपॉइंट होता है:

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

एमसीपी टूल

एमसीपी टूल एक ऐसा फ़ंक्शन या सुविधा है जिसे एमसीपी सर्वर, एलएलएम या एआई ऐप्लिकेशन को उपलब्ध कराता है. इससे एलएलएम या एआई ऐप्लिकेशन, असल दुनिया में कोई कार्रवाई कर पाता है.

टूल

mapstools.googleapis.com एमसीपी सर्वर में ये टूल मौजूद हैं:

एमसीपी टूल
search_places

इस टूल को तब कॉल करें, जब उपयोगकर्ता ने जगहों, कारोबारों, पतों, जगहों की जानकारी, लोकप्रिय जगहों या Google Maps से जुड़ी कोई अन्य मिलती-जुलती खोज की हो.

इनपुट से जुड़ी ज़रूरी शर्तें (अहम):

  1. 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'.
  2. location_bias (object - OPTIONAL): इसका इस्तेमाल करके, किसी खास इलाके के आस-पास के नतीजों को प्राथमिकता दी जा सकती है.

    • फ़ॉर्मैट: {"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}}
    • इस्तेमाल:
      • पांच कि॰मी॰ के दायरे में मौजूद जगहों को प्राथमिकता देने के लिए: {"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 को छोड़कर).
  3. language_code (string - ज़रूरी नहीं): खोज के नतीजों की खास जानकारी दिखाने के लिए इस्तेमाल की जाने वाली भाषा.

    • फ़ॉर्मैट: दो अक्षर वाला भाषा कोड (ISO 639-1). इसके बाद, अंडरस्कोर और दो अक्षर वाला देश कोड (ISO 3166-1 alpha-2) भी डाला जा सकता है. उदाहरण के लिए, en, ja, en_US, zh_CN, es_MX. अगर भाषा कोड नहीं दिया जाता है, तो नतीजे अंग्रेज़ी में दिखेंगे.
  4. region_code (स्ट्रिंग - ज़रूरी नहीं): उपयोगकर्ता के देश/इलाके का यूनिकोड CLDR कोड. इस पैरामीटर का इस्तेमाल, जगह की जानकारी दिखाने के लिए किया जाता है. जैसे, किसी इलाके के हिसाब से जगह का नाम, अगर उपलब्ध हो. लागू कानून के आधार पर, पैरामीटर से नतीजों पर असर पड़ सकता है.

    • फ़ॉर्मैट: दो अक्षर का देश कोड (ISO 3166-1 alpha-2), जैसे कि US, CA.
  5. page_size (integer - OPTIONAL): नतीजों में दिखाई जाने वाली जगहों की ज़्यादा से ज़्यादा संख्या. यह संख्या 1 से 10 के बीच होनी चाहिए. डिफ़ॉल्ट रूप से, यह 5 पर सेट होता है. 5 से ज़्यादा वैल्यू सिर्फ़ तब सेट करें, जब उपयोगकर्ता को पांच से ज़्यादा जगहों की तुलना करनी हो. 6 से 10 तक की वैल्यू सेट करने पर, ज़्यादा शुल्क लगता है और इंतज़ार का समय भी ज़्यादा होता है.

  6. include_extended_details (बूलियन - ज़रूरी नहीं): जब उपयोगकर्ता के अनुरोध के लिए, बेहतर क्वालिटी वाली अहम जानकारी, रीयल-टाइम डाइनैमिक या इकाई की खास विशेषताओं की ज़रूरत हो, तो इस फ़ील्ड को true पर सेट करें. डिफ़ॉल्ट रूप से, यह false पर सेट होता है. इसे true पर सेट करने से, ज़्यादा लागत और इंतज़ार का समय बढ़ जाता है.

टूल कॉल के लिए निर्देश:

  • जगह की जानकारी (ज़रूरी): खोज में जगह की ज़रूरी जानकारी शामिल होनी चाहिए. अगर जगह की जानकारी साफ़ तौर पर नहीं दी गई है (उदाहरण के लिए, सिर्फ़ "पिज़्ज़ा की दुकानें"), तो आपको text_query में इसकी जानकारी देनी होगी (उदाहरण के लिए, "न्यूयॉर्क में पिज़्ज़ा की दुकानें") या location_bias पैरामीटर का इस्तेमाल करना होगा. अगर ज़रूरी हो, तो शहर, राज्य/प्रांत, और इलाके/देश का नाम शामिल करें, ताकि कोई भ्रम न रहे.

  • हमेशा सबसे सटीक और काम की text_query दें.

  • location_bias का इस्तेमाल सिर्फ़ तब करें, जब निर्देशांक साफ़ तौर पर दिए गए हों या उपयोगकर्ता के जाने-पहचाने संदर्भ से जगह की जानकारी का अनुमान लगाना सही और बेहतर नतीजों के लिए ज़रूरी हो.

  • ग्राउंडेड आउटपुट को सोर्स के साथ एट्रिब्यूट किया जाना चाहिए. इसके लिए, attribution फ़ील्ड में मौजूद जानकारी का इस्तेमाल करें.

lookup_weather इससे किसी जगह के मौसम की पूरी जानकारी मिलती है. इसमें मौसम, एयर क्वालिटी (एक्यूआई और प्रदूषण फैलाने वाले कारक), और पराग (पेड़, घास, खरपतवार, और पौधों की प्रजातियों में एलर्जी पैदा करने वाले कारकों के लेवल) की जानकारी शामिल है: मौसम और एयर क्वालिटी के लिए, मौजूदा स्थिति, हर घंटे के हिसाब से पूर्वानुमान/इतिहास, और रोज़ के पूर्वानुमान; पराग के लिए सिर्फ़ रोज़ का पूर्वानुमान (आज से लेकर अगले चार दिनों तक, हर घंटे या पिछले डेटा के बिना). उपलब्ध एनवायरमेंटल डोमेन और सुविधाएं (capabilities: WEATHER, AIR_QUALITY, POLLEN — ज़रूरी): * साफ़ तौर पर चुनना ज़रूरी है: आपको हर कॉल पर capabilities में WEATHER, AIR_QUALITY या POLLEN में से कम से कम एक को शामिल करना ज़रूरी है. capabilities को छोड़ना मंज़ूर नहीं है. * बाहर के मौसम के बारे में साफ़ तौर पर न पूछी गई / अधूरी क्वेरी (बाहर के मौसम की पूरी जानकारी): अगर उपयोगकर्ता ने बाहर के मौसम, यात्रा या किसी स्थिति के बारे में सामान्य सवाल पूछा है और किसी खास डोमेन तक सीमित नहीं है (जैसे, "अभी दौड़ने के लिए बाहर का मौसम कैसा है?"), तो साफ़ तौर पर तीनों सुविधाएं शामिल करें (capabilities: ["WEATHER", "AIR_QUALITY", "POLLEN"]), ताकि बाहर के मौसम की पूरी जानकारी (मौसम + एयर क्वालिटी + पराग) मिल सके; पिछले date/hour के लिए, POLLEN को छोड़ दें, जिसका कोई इतिहास नहीं है. * टारगेट किए गए डोमेन का विकल्प (खास क्वेरी): अगर उपयोगकर्ता सिर्फ़ एक या दो डोमेन के बारे में पूछता है (जैसे, "सिएटल में ताज़ातरीन एक्यूआई क्या है?"), तो सिर्फ़ अनुरोध की गई सुविधाओं (WEATHER, AIR_QUALITY, और/या POLLEN) को शामिल करें. सिर्फ़ अनुरोध किए गए डोमेन को लागू किया जाएगा और दिखाया जाएगा. डोमेन के हिसाब से उपलब्ध डेटा: * मौसम (weather): तापमान (मौजूदा, महसूस होने वाला, ज़्यादा से ज़्यादा/कम से कम, हीट इंडेक्स), हवा (रफ़्तार, झोंके, दिशा), खगोलीय घटनाएं (सूर्योदय/सूर्यास्त, चंद्रमा की कलाएं), बारिश (टाइप, संभावना, मात्रा/क्यूपीएफ़), और वायुमंडलीय स्थितियां (यूवी इंडेक्स, नमी, बादलों की स्थिति, आंधी-तूफ़ान की संभावना, वायुमंडलीय दबाव). * एयर क्वालिटी (air_quality): यूनिवर्सल और लोकल एयर क्वालिटी इंडेक्स (एक्यूआई वैल्यू, कैटगरी, सबसे ज़्यादा प्रदूषण फैलाने वाला कारक), स्वास्थ्य से जुड़ी सलाह (सात संवेदनशील ग्रुप के लिए), और प्रदूषण फैलाने वाले कारकों की सघनता (include_pollutant_concentration: true). हर इंडेक्स में, सबसे ज़्यादा प्रदूषण फैलाने वाला कारक अलग होता है.इसे हर इंडेक्स के हिसाब से रिपोर्ट करें. उदाहरण के लिए, यूएस एक्यूआई के लिए यूनिवर्सल एक्यूआई के प्रदूषण फैलाने वाले कारक की जानकारी न दें. * पराग (pollen): पेड़, घास, और खरपतवार की हर कैटगरी और पौधे की हर प्रजाति के लिए, हर दिन का यूनिवर्सल पोलन इंडेक्स (यूपीआई, 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 Maps पर मौजूद जगह का ऐसा आईडी जो साफ़ तौर पर समझ आए (उदाहरण के लिए, 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 का इस्तेमाल किया जाता है), यूटीसी या कॉलर के टाइमज़ोन में नहीं. * 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 की जानकारी दें. अगर मिनटों का ज़िक्र किया गया है, तो उन्हें निकटतम घंटे में बदलें. * ज़रूरी शर्त (hour सेट होने पर date ज़रूरी है): date के बिना hour (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 को शामिल नहीं किया गया है): * पूरे दिन की क्वेरी (जैसे, "weather and pollen in London tomorrow") के लिए, hour के बिना location, date (अनुरोध किए गए location के स्थानीय सिविल समय के हिसाब से {year, month, day}), और टारगेट capabilities की जानकारी दें. * आज के लिए, एयर क्वालिटी और घर से बाहर की गतिविधियों से जुड़े सामान्य सवाल: आज (जैसे, "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") के बारे में है, तो उस तारीख के लिए हर दिन एक कॉल को प्राथमिकता दें. साथ ही, अलग-अलग घंटों के सैंपल लेने के बजाय, एयर क्वालिटी की सीरीज़ से समयावधि के घंटे पढ़ें. अगर हर घंटे के हिसाब से कॉल किए जाते हैं, तो विंडो के हर घंटे को कवर करें. * यह अनुरोध किए गए मौसम और/या पराग के लिए, रोज़ के पूर्वानुमान दिखाता है. साथ ही, पूरे दिन (स्थानीय समयानुसार 00:00 से 23:00 बजे तक) के लिए, हर घंटे की एयर क्वालिटी की सीरीज़ दिखाता है: पिछली तारीख के लिए 24 घंटे का इतिहास, आने वाली तारीख के लिए 24 घंटे का पूर्वानुमान, और आज के लिए पिछले घंटे (इतिहास), मौजूदा घंटा, और बाकी घंटे (पूर्वानुमान). डोमेन के हिसाब से, समय की सीमाएं: * मौसम: पिछले 24 घंटों से लेकर अगले 240 घंटों (10 दिन) तक, हर घंटे के हिसाब से (पिछले घंटों के लिए, date और hour, दोनों की ज़रूरत होती है); आज से लेकर अगले 10 दिनों तक, हर दिन के हिसाब से (आज से लेकर +9 दिनों तक); हर दिन का इतिहास नहीं होता. * एयर क्वालिटी: 720 घंटे (30 दिन) पहले से लेकर 96 घंटे (4 दिन) आगे तक, हर घंटे के हिसाब से; पूरे दिन का कॉल उस विंडो में फ़िट होना चाहिए (आज से −29 दिन से लेकर +3 दिन तक). * पराग: सिर्फ़ रोज़ाना, आज से लेकर अगले चार दिनों तक (आज को मिलाकर पांच दिन); पिछली तारीखें शामिल नहीं हैं और hour को अनदेखा किया जाता है. * (ध्यान दें: अगर कई सुविधाओं का अनुरोध किया जाता है और date/hour उनमें से किसी एक की रेंज से बाहर है, तो भी कॉल सफल होता है और सिर्फ़ वे सुविधाएं मिलती हैं जो काम करती हैं.) * रेंज से बाहर के अनुरोध: अगर अनुरोध की गई तारीख या घंटा, ऊपर बताई गई डोमेन की रेंज से बाहर है (उदाहरण के लिए, पिछली तारीख के लिए पराग), तो भी अनुरोध की गई तारीख/घंटे के लिए 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): अगर आपको प्रदूषण फैलाने वाले खास कॉम्पोनेंट (PM2.5, PM10, O3, NO2, SO2, CO) की सघनता का डेटा चाहिए, तो include_pollutant_concentration: true सेट करें. इसके अलावा, किसी खास इलाके के एक्यूआई स्केल का अनुरोध करने के लिए, index_region_code (देश का दो अक्षरों वाला आईएसओ कोड, जैसे कि "US") सेट करें. डिफ़ॉल्ट रूप से, जवाब में यूनिवर्सल एक्यूआई और जगह का क्षेत्रीय एक्यूआई शामिल होता है. * एट्रिब्यूशन: ग्राउंडेड आउटपुट को सोर्स के साथ एट्रिब्यूट करना ज़रूरी है. इसके लिए, दिखाए गए हर डोमेन कंटेनर (weather.attribution, air_quality.attribution, pollen.attribution) में मौजूद attribution फ़ील्ड का इस्तेमाल करें. * दिखाए गए समय: एयर क्वालिटी date_time की वैल्यू, जगह के स्थानीय समय (utc_offset शामिल है) के हिसाब से पहले से मौजूद होती हैं. इन्हें ऐसे ही दिखाएं. मौसम date_time (मौजूदा और हर घंटे का) और सूर्योदय/सूर्यास्त का समय यूटीसी में होता है. इन्हें time_zone का इस्तेमाल करके, जगह के स्थानीय समय में बदलें. सभी समय को स्थानीय समय के तौर पर लेबल करें.
compute_routes

यह यात्रा शुरू करने की जगह और मंज़िल के बीच के रास्ते की जानकारी देता है. इसमें बीच में पड़ने वाले स्टॉप की जानकारी भी शामिल की जा सकती है. यह हर रास्ते के लिए दूरी और लगने वाले समय की जानकारी दिखाता है.

इनपुट से जुड़ी ज़रूरी शर्तें (अहम):

  1. origin और destination (ऑब्जेक्ट - ज़रूरी): इनमें से हर एक को इनमें से किसी एक का इस्तेमाल करके उपलब्ध कराना ज़रूरी है:

    • address (स्ट्रिंग, जैसे कि 'Eiffel Tower, Paris'). नाम वाली जगहों, लैंडमार्क, और कारोबारों को सीधे तौर पर रिज़ॉल्व किया जाता है. इसलिए, किसी वेपॉइंट को जियोकोड करने के लिए, पहले search_places को कॉल न करें. उपयोगकर्ता ने जिस शहर, इलाके या देश का ज़िक्र किया है उसे शामिल करें.
    • lat_lng (object, {"latitude": number, "longitude": number}).
    • place_id (स्ट्रिंग, जैसे कि 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'), उदाहरण के लिए, search_places से.
  2. intermediate_waypoints (ऑब्जेक्ट का कलेक्शन - ज़रूरी नहीं): यात्रा शुरू करने की जगह और मंज़िल के बीच, क्रम से ज़्यादा से ज़्यादा 25 स्टॉप. origin जैसा फ़ॉर्मैट. TRANSIT के साथ काम नहीं करता. सिर्फ़ वे स्टॉप शामिल करें जिनके लिए उपयोगकर्ता ने अनुरोध किया है. 10 से ज़्यादा इंटरमीडिएट वेपॉइंट तय करने पर, ज़्यादा शुल्क और ज़्यादा इंतज़ार का समय लगेगा.

  3. travel_mode (enum - ज़रूरी नहीं): DRIVE (डिफ़ॉल्ट), WALK, BICYCLE या TRANSIT.

  4. समय (ज़रूरी नहीं - ज़्यादा से ज़्यादा एक सेट करें): यूटीसी ऑफ़सेट के साथ आरएफ़सी 3339 टाइमस्टैंप, जैसे कि '2026-09-19T08:00:00-07:00'. डिफ़ॉल्ट रूप से, यह 'अभी रवाना हो रही है' पर सेट होता है. TRANSIT के लिए, समय को पिछले सात दिनों या आने वाले 100 दिनों तक के लिए सेट किया जा सकता है. अन्य मोड के लिए, समय को आने वाले 365 दिनों तक के लिए सेट किया जा सकता है. हालांकि, इसे बीते हुए समय के लिए सेट नहीं किया जा सकता.

    • departure_time: इसका इस्तेमाल तब करें, जब उपयोगकर्ता यह बताए कि वह कब रवाना होगा (उदाहरण के लिए, "कल सुबह 8 बजे").
    • arrival_time: इसका इस्तेमाल तब करें, जब उपयोगकर्ता यह बताए कि उसे कब पहुंचना है. उदाहरण के लिए, "सुबह 9 बजे तक वहां पहुंचना है".
  5. routing_preference (enum - ज़रूरी नहीं है):

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (डिफ़ॉल्ट): लाइव ट्रैफ़िक, घटनाओं, और बंद सड़कों को अनदेखा करता है. इंतज़ार का समय सबसे कम रखना.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: उपलब्ध होने पर, ट्रैफ़िक की लाइव जानकारी का इस्तेमाल करता है. यह सुविधा WALK या BICYCLE के लिए उपलब्ध नहीं है. इसे सिर्फ़ तब सेट करें, जब उपयोगकर्ता ट्रैफ़िक, भीड़भाड़ या ट्रैफ़िक के हिसाब से अडजस्ट किए गए ईटीए के बारे में पूछे. इसमें ज़्यादा लागत और इंतज़ार का समय लगता है.
  6. location_bias (ऑब्जेक्ट - ज़रूरी नहीं): {"latitude": number, "longitude": number} इसका इस्तेमाल, वेपॉइंट के पतों में जगहों के नामों को साफ़ तौर पर बताने के लिए किया जाता है. अगर किसी जगह का नाम साफ़ तौर पर समझ नहीं आ रहा है (जैसे, "स्प्रिंगफ़ील्ड") और उपयोगकर्ता ने कोई इलाका नहीं बताया है, तो address में दिया गया नाम ही रखें. साथ ही, किसी इलाके का अनुमान लगाने के बजाय, location_bias को उस इलाके पर सेट करें जहां आपको जाना है.

  7. compute_alternative_routes (बूलियन - ज़रूरी नहीं): इसे true पर सिर्फ़ तब सेट करें, जब उपयोगकर्ता रास्ते के विकल्प या अन्य रास्ते के बारे में पूछे. डिफ़ॉल्ट रूप से, false पर सेट होता है. इससे सिर्फ़ सुझाया गया रास्ता दिखता है.

  8. include_polyline (बूलियन - ज़रूरी नहीं): इसे true पर सिर्फ़ तब सेट करें, जब रास्ते की ज्यामिति (encoded_polyline) की ज़रूरत हो. डिफ़ॉल्ट रूप से, यह false पर सेट होता है.

टूल कॉल के लिए निर्देश:

  • अगर शुरुआत या मंज़िल की जानकारी मौजूद नहीं है, तो टूल को कॉल करने से पहले, आपको उपयोगकर्ता से साफ़ तौर पर जानकारी मांगनी होगी.
  • "A से B कितनी दूर है?" जैसे सवालों के लिए, B को origin और A को destination के तौर पर इस्तेमाल करें.

टूल कॉल का उदाहरण: {"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"}

Instructions for Response:

  • जब वैकल्पिक रास्तों का अनुरोध किया जाता है, तो रास्तों को सबसे ज़्यादा से लेकर सबसे कम सुझाए गए क्रम में लगाया जाता है.
  • अगर routes खाली है, तो उपयोगकर्ता को बताएं कि कोई रास्ता नहीं मिला. रास्ते का अनुमान न लगाएं.
  • DRIVE रास्ते पर मौजूद जगहों को ढूंढने के लिए, रास्ते के retrieval_token को search_along_route पर पास करें. यह टोकन 10 मिनट के लिए मान्य होता है.
  • सिर्फ़ टूल से मिले तथ्यों को शामिल करें. मोड़-दर-मोड़ निर्देश, बस, मेट्रो वगैरह की लाइनें, स्टेशन, प्लैटफ़ॉर्म या ट्रांसफ़र की जानकारी खुद से न बनाएं.
  • उपलब्ध होने पर, हर रूट के attribution फ़ील्ड का इस्तेमाल करके, तथ्यों पर आधारित आउटपुट को सोर्स के साथ एट्रिब्यूट किया जाना चाहिए.
search_along_route

इस टूल को तब कॉल करें, जब उपयोगकर्ता को यात्रा के रास्ते में जगहें, कारोबार या लोकप्रिय जगहें ढूंढनी हों. जैसे, "ताहो जाने के रास्ते में पेट्रोल पंप", "सैन फ़्रांसिस्को और सैन होज़े के बीच कॉफ़ी शॉप". इस टूल को कॉल करने पर, search_places की तुलना में ज़्यादा शुल्क लगता है. इसलिए, किसी रास्ते के बजाय किसी एक जगह के आस-पास खोजते समय, search_places का इस्तेमाल करें.

इनपुट से जुड़ी ज़रूरी शर्तें (अहम):

  1. text_query (स्ट्रिंग - ज़रूरी है): रास्ते में क्या खोजना है, इसकी जानकारी नैचुरल लैंग्वेज में दें.

    • उदाहरण: 'ev chargers', 'coffee', 'vegetarian restaurants', 'rest stops'.
  2. रूट की जानकारी (ज़रूरी है - इनमें से सिर्फ़ एक विकल्प चुनें):

    • retrieval_token (स्ट्रिंग): DRIVE रास्ते के लिए, compute_routes के पिछले कॉल से मिला retrieval_token. जब रास्ते का हिसाब पहले ही लगा लिया गया हो, तब इसे प्राथमिकता दें. यह टोकन 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 रास्ते को दिखाती है.
  3. travel_mode (enum - ज़रूरी नहीं): DRIVE (डिफ़ॉल्ट), WALK या BICYCLE. WALK और BICYCLE सिर्फ़ route_endpoints के साथ काम करते हैं. TRANSIT का इस्तेमाल नहीं किया जा सकता.

  4. routing_preference (enum - ज़रूरी नहीं है):

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (डिफ़ॉल्ट): लाइव ट्रैफ़िक के बिना, रास्ते और चक्करदार रास्तों का हिसाब लगाता है. इंतज़ार का समय सबसे कम रखना.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: उपलब्ध होने पर, ट्रैफ़िक की लाइव जानकारी का इस्तेमाल करता है. यह सुविधा WALK या BICYCLE के लिए उपलब्ध नहीं है. इसे सिर्फ़ तब सेट करें, जब उपयोगकर्ता ट्रैफ़िक, भीड़भाड़ या ट्रैफ़िक के हिसाब से अडजस्ट किए गए डिटूर के समय के बारे में पूछे. इससे इंतज़ार का समय बढ़ जाता है.
  5. include_extended_details (बूलियन - ज़रूरी नहीं): इसे true पर सिर्फ़ तब सेट करें, जब अनुरोध में समीक्षा की अहम जानकारी, मेन्यू के खास आइटम या ऑफ़र, माहौल, विज़िटर के लिए सलाह या व्यस्तता, ईवी चार्जर की उपलब्धता, पेट्रोल/डीज़ल की कीमतें या अन्य अहम जानकारी शामिल हो. डिफ़ॉल्ट रूप से, यह false पर सेट होता है. इसे चालू करने से, इंतज़ार का समय बढ़ सकता है.

  6. language_code (स्ट्रिंग - ज़रूरी नहीं): नतीजों की खास जानकारी और जगह की जानकारी के लिए भाषा, जैसे कि en, ja, en-US. डिफ़ॉल्ट रूप से, यह en-US पर सेट होता है.

  7. region_code (स्ट्रिंग - ज़रूरी नहीं): उपयोगकर्ता के यूनिकोड सीएलडीआर क्षेत्र का कोड, जैसे कि US, CA.

टूल कॉल के लिए निर्देश:

  • हर नतीजे में एक detour_summary (उपलब्ध होने पर) शामिल होता है. इसमें अतिरिक्त दूरी (localized_detour_distance) की जानकारी होती है. साथ ही, अगर रास्ते को encoded_polyline के तौर पर नहीं दिया गया है, तो उस जगह पर रुकने में लगने वाले अतिरिक्त समय (detour_duration) की जानकारी भी होती है. विकल्पों की तुलना करने के लिए इसका इस्तेमाल करें.
  • जवाब summary में, शून्य से शुरू होने वाले उद्धरण (जैसे, "[0]") शामिल हो सकते हैं. ये उद्धरण, results में मौजूद एंट्री के बारे में बताते हैं.
  • तथ्यों पर आधारित आउटपुट को सोर्स के साथ एट्रिब्यूट किया जाना चाहिए. इसके लिए, हर results[].place के attribution फ़ील्ड का इस्तेमाल करें. हालांकि, ऐसा तब ही किया जा सकता है, जब यह फ़ील्ड उपलब्ध हो.
resolve_names

यह जगह की जानकारी से जुड़ी क्वेरी (लैंडमार्क के नाम या सटीक पते) की बैच लिस्ट को कैननिकल Google Maps जगह के आईडी में बदलता है.

इनपुट से जुड़ी ज़रूरी शर्तें (अहम):

  1. queries (ऑब्जेक्ट का कलेक्शन - ज़रूरी): जगह की जानकारी से जुड़ी क्वेरी की सूची, जिन्हें हल करना है. ज़्यादा से ज़्यादा 20 क्वेरी डाली जा सकती हैं.

    • हर क्वेरी ऑब्जेक्ट में ये चीज़ें होनी चाहिए:
      • text (स्ट्रिंग - ज़रूरी): टेक्स्ट क्वेरी, जिसमें किसी जगह का नाम या पता शामिल होता है.
        • उदाहरण: 'Googleplex, Mountain View, CA', '1600 Amphitheatre Pkwy, Mountain View, CA', 'Eiffel Tower, Paris'.
  2. location_bias (object - OPTIONAL): इसका इस्तेमाल करके, किसी खास इलाके के आस-पास के नतीजों को प्राथमिकता दी जा सकती है.

    • फ़ॉर्मैट: {"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}}
  3. region_code (स्ट्रिंग - ज़रूरी नहीं): उपयोगकर्ता के यूनिकोड सीएलडीआर रीजन कोड (दो अक्षरों वाला देश का कोड, जैसे कि US, CA) के हिसाब से नतीजे दिखाए जाते हैं.

टूल कॉल के लिए निर्देश:

  • सटीक जानकारी (ज़रूरी): क्वेरी में किसी जगह का नाम या पता सटीक होना चाहिए. 'restaurants' जैसी सामान्य खोजों या 'Starbucks' जैसे चेन के नामों के लिए यह सुविधा काम नहीं करती.
  • अगर आपको जिन डाउनस्ट्रीम टूल को कॉल करना है वे पहले से ही रॉ पते या जगह के नाम की स्ट्रिंग को सीधे तौर पर स्वीकार करते हैं, तो इस टूल को कॉल न करें.

Google Maps में सेव करना:

  • जवाब में save_to_maps_url फ़ील्ड शामिल होता है: Google Maps का एक लिंक, जिसमें उन सभी जगहों की जानकारी होती है जिन्हें सही तरीके से खोजा गया है.
  • जब उपयोगकर्ता को Google Maps में, खोजी गई जगहों को सूची के तौर पर सेव करना, शेयर करना या खोलना हो, तो उसे यह लिंक दिखाएं. इस लिंक को खुद न बनाएं.

गड़बड़ी ठीक करना (ज़रूरी):

  • यह एक बैच प्रोसेसिंग टूल है. किसी अनुरोध के जवाब में "मिले-जुले नतीजे" मिल सकते हैं. उदाहरण के लिए, कुछ क्वेरी का जवाब मिल सकता है, जबकि कुछ का नहीं.
  • results की आउटपुट सूची, इनपुट queries इंडेक्स के साथ 1:1 मैप करने की गारंटी देती है. क्वेरी पूरी न होने पर, results सूची में उसके इंडेक्स पर, खाली Result मैसेज दिखेगा. साथ ही, कोई entity सेट नहीं होगा.
  • आपको रिस्पॉन्स में failed_requests मैप फ़ील्ड की जांच ज़रूर करनी चाहिए, ताकि यह पता चल सके कि किस क्वेरी इंडेक्स में गड़बड़ी हुई है. failed_requests की कुंजी, अनुरोध में मौजूद उस क्वेरी के 0-आधारित इंडेक्स को दिखाती है जो पूरी नहीं हो सकी. यह न मानें कि कुछ गड़बड़ियों की वजह से पूरा बैच कॉल फ़ेल हो गया है.
resolve_maps_urls

यह Google Maps के यूआरएल की सूची को Google Maps के कैननिकल जगह के आईडी में बदलता है.

इस टूल को कब कॉल करना चाहिए (ज़रूरी):

  • इस टूल का इस्तेमाल तब करें, जब उपयोगकर्ता Google Maps पर शेयर करने के लिए एक या उससे ज़्यादा लिंक या यूआरएल उपलब्ध कराता है. जैसे, 'https://maps.app.goo.gl/...', 'https://www.google.com/maps/place/...' या 'https://maps.google.com/...') और आपको कैननिकल जगह का आईडी निकालने हैं.
  • एक ही बैच अनुरोध में, ज़्यादा से ज़्यादा 20 यूआरएल की समस्या हल की जा सकती है.

इनपुट से जुड़ी ज़रूरी शर्तें (अहम):

  • urls (स्ट्रिंग का कलेक्शन - ज़रूरी): Google Maps के उन यूआरएल की सूची जिन्हें रिज़ॉल्व करना है. हर यूआरएल, Google Maps का मान्य और किसी एक जगह का यूआरएल होना चाहिए.

Google Maps में सेव करना:

  • जवाब में save_to_maps_url फ़ील्ड शामिल होता है: Google Maps का एक लिंक, जिसमें उन सभी जगहों की जानकारी होती है जिन्हें सही तरीके से खोजा गया है.
  • जब उपयोगकर्ता को Google Maps में, सुझाई गई जगहों को सूची के तौर पर सेव करना हो, शेयर करना हो या खोलना हो, तो उसे यह लिंक दिखाएं. जैसे, किसी बातचीत में शेयर की गई जगहों को इकट्ठा करना. इस लिंक को खुद न बनाएं.

गड़बड़ी ठीक करना (ज़रूरी):

  • यह एक बैच प्रोसेसिंग टूल है. किसी अनुरोध के जवाब में "मिले-जुले नतीजे" मिल सकते हैं. उदाहरण के लिए, कुछ यूआरएल के लिए अनुरोध पूरा हो सकता है, जबकि कुछ के लिए नहीं.
  • entities की आउटपुट सूची, इनपुट urls इंडेक्स के साथ 1:1 मैप करने की गारंटी देती है. यूआरएल रिज़ॉल्यूशन पूरा न होने पर, entities सूची में मौजूद इंडेक्स पर, Entity मैसेज खाली दिखेगा. इसका मतलब है कि कोई फ़ील्ड सेट नहीं किया गया है.
  • आपको रिस्पॉन्स में failed_requests मैप फ़ील्ड की जांच ज़रूर करनी चाहिए, ताकि यह पता चल सके कि किस यूआरएल को इंडेक्स नहीं किया जा सका. failed_requests की कुंजी, अनुरोध में मौजूद उस यूआरएल के 0-आधारित इंडेक्स को दिखाती है जिसे प्रोसेस नहीं किया जा सका. यह न मानें कि कुछ गड़बड़ियों की वजह से पूरा बैच कॉल फ़ेल हो गया है.

एमसीपी टूल की खास जानकारी पाना

किसी एमसीपी सर्वर में मौजूद सभी टूल के लिए, एमसीपी टूल की खास जानकारी पाने के लिए, tools/list तरीके का इस्तेमाल करें. यहां दिए गए उदाहरण में, curl का इस्तेमाल करके, एमसीपी सर्वर में फ़िलहाल उपलब्ध सभी टूल और उनकी खास जानकारी को लिस्ट करने का तरीका बताया गया है.

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
}'