MCP Reference: mapstools.googleapis.com

Il s'agit d'un serveur MCP fourni par Maps Experience Agent Tools. Le serveur fournit des outils permettant aux développeurs de créer des applications LLM sur Google Maps Platform.

Un serveur MCP (Model Context Protocol) sert de proxy entre un service externe qui fournit du contexte, des données ou des capacités à un grand modèle de langage (LLM) ou à une application d'IA. Les serveurs MCP connectent les applications d'IA à des systèmes externes tels que des bases de données et des services Web, et traduisent leurs réponses dans un format que l'application d'IA peut comprendre.

Configuration du serveur

Vous devez activer les serveurs MCP et configurer l'authentification avant de les utiliser. Pour en savoir plus sur l'utilisation des serveurs MCP distants Google et Google Cloud, consultez la présentation des serveurs MCP Google Cloud.

Points de terminaison du serveur

Un point de terminaison de service MCP est l'adresse réseau et l'interface de communication (généralement une URL) du serveur MCP qu'une application d'IA (l'hôte du client MCP) utilise pour établir une connexion sécurisée et standardisée. Il s'agit du point de contact permettant au LLM de demander du contexte, d'appeler un outil ou d'accéder à une ressource.

Le serveur MCP des outils de l'agent Maps Experience dispose du point de terminaison MCP global suivant :

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

Outils MCP

Un outil MCP est une fonction ou une capacité exécutable qu'un serveur MCP expose à un LLM ou à une application d'IA pour effectuer une action dans le monde réel.

Outils

Le serveur MCP mapstools.googleapis.com dispose des outils suivants :

Outils MCP
search_places

Appelez cet outil lorsque la requête de l'utilisateur consiste à trouver des lieux, des établissements, des adresses, des emplacements, des points d'intérêt ou toute autre recherche associée à Google Maps.

Exigences d'entrée (CRITIQUE) :

  1. text_query (chaîne - OBLIGATOIRE) : requête de recherche principale. Il doit définir clairement ce que l'utilisateur recherche.

    • Exemples : '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'.
    • Pour obtenir des détails spécifiques sur un lieu : incluez l'attribut demandé (par exemple, 'Google Store Mountain View opening hours', 'SF MoMa phone number', 'Shoreline Park Mountain View address').
  2. location_bias (objet, FACULTATIF) : utilisez ce paramètre pour prioriser les résultats situés à proximité d'une zone géographique spécifique.

    • Format : {"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}}
    • Utilisation :
      • Pour privilégier un rayon de 5 km : {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}, "radius_meters": 5000}}}
      • Pour privilégier fortement le point central : {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}}}} (en omettant radius_meters).
  3. language_code (chaîne, FACULTATIF) : langue dans laquelle afficher le résumé des résultats de recherche.

    • Format : code de langue à deux lettres (ISO 639-1), éventuellement suivi d'un trait de soulignement et d'un code pays à deux lettres (ISO 3166-1 alpha-2), par exemple en, ja, en_US, zh_CN, es_MX. Si le code de langue n'est pas fourni, les résultats seront en anglais.
  4. region_code (chaîne, FACULTATIF) : code de région CLDR Unicode de l'utilisateur. Ce paramètre permet d'afficher les détails du lieu, comme le nom du lieu spécifique à la région, s'il est disponible. Le paramètre peut affecter les résultats en fonction de la législation applicable.

    • Format : code pays à deux lettres (ISO 3166-1 alpha-2), par exemple US, CA.
  5. page_size (entier, FACULTATIF) : nombre maximal de lieux à renvoyer, de 1 à 10. La valeur par défaut est 5. Définissez une valeur supérieure à 5 uniquement si l'utilisateur souhaite comparer plus de cinq lieux. Les valeurs comprises entre 6 et 10 entraînent des coûts et une latence plus élevés.

  6. include_extended_details (booléen, FACULTATIF) : définissez ce champ sur true lorsque la requête de l'utilisateur nécessite des insights qualitatifs enrichis, des dynamiques en temps réel ou des attributs d'entité spécialisés. La valeur par défaut est false. Si vous définissez cette valeur sur true, le coût et la latence seront plus élevés.

Instructions pour l'appel d'outil :

  • Informations de localisation (CRITIQUE) : la recherche doit contenir suffisamment d'informations de localisation. Si l'emplacement est ambigu (par exemple, "pizzerias"), vous devez le spécifier dans le text_query (par exemple, "pizzerias à New York") ou utiliser le paramètre location_bias. Incluez la ville, l'État/la province et le nom de la région/du pays si nécessaire pour lever toute ambiguïté.

  • Fournissez toujours le text_query le plus spécifique et le plus riche en contexte possible.

  • N'utilisez location_bias que si les coordonnées sont explicitement fournies ou si déduire un emplacement à partir du contexte connu d'un utilisateur est approprié et nécessaire pour obtenir de meilleurs résultats.

  • La sortie ancrée doit être attribuée à la source à l'aide des informations du champ attribution, lorsqu'elles sont disponibles.

lookup_weather Récupère des informations environnementales complètes pour un lieu, y compris la météo, la qualité de l'air (IQA et polluants) et le pollen (niveaux d'allergènes des arbres, des graminées, des mauvaises herbes et des espèces végétales) : conditions actuelles, prévisions/historique horaires et prévisions quotidiennes pour la météo et la qualité de l'air. Le pollen n'est disponible que pour les prévisions quotidiennes (aujourd'hui à +4 jours, pas de données horaires ni passées). Domaines et fonctionnalités d'environnement disponibles (capabilities : WEATHER, AIR_QUALITY, POLLEN – CRITIQUE) : * Sélection explicite obligatoire : vous DEVEZ inclure au moins l'un des éléments WEATHER, AIR_QUALITY ou POLLEN dans capabilities pour chaque appel. L'omission de capabilities n'est PAS autorisée. * Requêtes générales/ambiguës sur l'extérieur (suite complète d'informations sur l'extérieur) : si l'utilisateur pose une question générale sur l'extérieur, les voyages ou la situation sans se limiter à un domaine spécifique (par exemple, "Quelles sont les conditions extérieures actuelles pour courir ?"), incluez explicitement les trois fonctionnalités (capabilities: ["WEATHER", "AIR_QUALITY", "POLLEN"]) pour renvoyer la suite complète d'informations sur l'extérieur (météo + qualité de l'air + pollen). Pour une date passée (date/hour), omettez POLLEN, qui n'a pas d'historique. * Sélection de domaines ciblés (requêtes spécifiques) : si l'utilisateur demande spécifiquement un ou deux domaines (par exemple, "Quel est l'IQA à Seattle en ce moment ?"), n'incluez que les fonctionnalités demandées (WEATHER, AIR_QUALITY et/ou POLLEN). Seuls les domaines demandés seront exécutés et renvoyés. Données spécifiques disponibles par domaine : * Météo (weather) : température (actuelle, ressentie, max/min, indice de chaleur), vent (vitesse, rafales, direction), événements célestes (lever/coucher du soleil, phase de la lune), précipitations (type, probabilité, quantité/QPF) et conditions atmosphériques (indice UV, humidité, couverture nuageuse, probabilité d'orage, pression atmosphérique). * Qualité de l'air (air_quality) : indices de la qualité de l'air (IQA) universels et locaux (valeur, catégorie et polluant dominant de l'IQA), recommandations de santé pour sept groupes de sensibilité et concentrations de polluants (include_pollutant_concentration: true). Chaque indice a son propre polluant dominant. Indiquez-le par indice (par exemple, ne donnez pas le polluant de l'IQA universel pour l'IQA américain). * Pollen (pollen) : indice UPI (Universal Pollen Index, 0-5) quotidien par catégorie (arbres, graminées et herbes) et par espèce végétale (index.value avec son index.category, par exemple 1 = "Très faible"), statut de saison, réactions croisées et recommandations de santé. * Champs de pollen manquants : un in_season manquant signifie que ce n'est pas la saison. Ignorez les espèces de plantes renvoyées sans index, sauf si l'utilisateur pose une question sur cette plante. Dans ce cas, indiquez qu'aucune donnée sur le pollen n'est disponible pour elle aujourd'hui (ne déduisez pas de niveau). Règles de localisation (CRITIQUE) : la zone géographique ciblée DOIT être spécifiée dans location à l'aide d'UN SEUL des sous-champs oneof suivants : 1. Coordonnées géographiques (lat_lng) : à utiliser lorsque les coordonnées exactes de latitude/longitude sont connues. * Exemple : {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} 2. ID de lieu (place_id) : * ID de lieu Google Maps non ambigu (par exemple, obtenu à partir de search_places ou resolve_names). * Exemple : {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} 3. Chaîne d'adresse (address) : * Ville/région, quartier, point de repère ou d'intérêt, adresse postale ou code postal, idéalement avec la ville/le pays. * Exemple : {"location": {"address": "Paris, France"}} Modes d'heure et d'utilisation (date et hour – CRITIQUE) : * Référence de fuseau horaire local : toutes les entrées date ({year, month, day}) et hour (0-23) DOIVENT être exprimées dans le fuseau horaire civil local de la location demandée (par exemple, une requête pour "Paris tomorrow at 13:00" utilise la date et l'heure locales de Europe/Paris 13), jamais l'heure UTC ni le fuseau horaire de l'appelant. * 1. Conditions actuelles (date omis ET hour omis) : * Indiquez location et la cible capabilities (WEATHER, AIR_QUALITY, POLLEN). Ne spécifiez PAS date ni hour. * Renvoie les conditions actuelles en temps réel (CC) pour les domaines demandés (météo actuelle, qualité de l'air pour l'heure actuelle et/ou prévisions de pollen pour aujourd'hui). * Pour la qualité de l'air, les conditions actuelles correspondent à une heure unique : ne les utilisez PAS seules pour répondre à des questions sur la qualité de l'air ou sur les conditions extérieures générales pour aujourd'hui (utilisez les requêtes quotidiennes ci-dessous). * 2. Prévisions/Historique par heure (date spécifié ET hour spécifié 0-23) : * Indiquez location, date ({year, month, day}), hour (0-23) et la cible capabilities. Si des minutes sont mentionnées, arrondissez à l'heure inférieure la plus proche. * CONTRAINTE CRITIQUE (date est REQUIS lorsque hour est défini) : fournir hour sans date (date omis, hour défini) n'est PAS autorisé et échouera avec une erreur. Même lorsque l'utilisateur demande une heure spécifique aujourd'hui (par exemple, "at 13:00 today"), vous DEVEZ renseigner à la fois date (la date du jour à location) et hour. * Exécute une recherche horaire pour les données météo et/ou de qualité de l'air demandées à YYYY-MM-DD-HH et une recherche quotidienne pour les données sur le pollen demandées à YYYY-MM-DD. * Questions sur la météo commençant par "quand" : pour les questions sur la météo demandant quand/à quelle heure/le meilleur moment (par exemple, "what time will it stop raining?"), utilisez les appels WEATHER horaires (date + hour) pour les heures concernées. Les prévisions météo quotidiennes ne comportent pas de valeurs horaires. Pour les questions générales sur l'extérieur "quand/meilleur moment" (par exemple, "when is the best time to go walking today?"), effectuez ces appels WEATHER toutes les heures en plus de l'appel sur une journée complète pour la qualité de l'air (et le pollen) décrit dans "Requêtes quotidiennes". * 3. Requêtes quotidiennes (date spécifié ET hour omis) : * Indiquez location, date ({year, month, day} dans l'heure civile locale de l'location demandé) sans hour, et l'capabilities cible pour les requêtes sur une journée complète (par exemple, "weather and pollen in London tomorrow"). * Questions sur la qualité de l'air et questions générales sur l'extérieur pour aujourd'hui : pour les questions sur la qualité de l'air et les questions générales sur l'extérieur (qui incluent la qualité de l'air) pour aujourd'hui (par exemple, "how will the air quality change today", "is today a good day for a picnic?"), définissez date sur la date d'aujourd'hui à location (heure omise) pour obtenir la série horaire de la qualité de l'air pour la journée. Un appel "Current Conditions" (Conditions actuelles) seul ne renvoie que l'heure actuelle de la qualité de l'air et ne suffit pas. Vous pouvez en ajouter un si l'utilisateur demande également des informations sur "maintenant". * Périodes de qualité de l'air : pour une question sur la qualité de l'air concernant une période d'une journée (par exemple, "air quality between noon and 6 PM"), privilégiez un appel quotidien pour cette date et lisez les heures de la période à partir de la série sur la qualité de l'air, plutôt que d'échantillonner des heures individuelles. Si vous utilisez des appels horaires, couvrez chaque heure de la période. * Renvoie les prévisions quotidiennes pour les données météo et/ou sur le pollen demandées, ainsi que les séries horaires de qualité de l'air pour la journée complète (de 00h00 à 23h00, heure locale) : 24 heures d'historique pour une date passée, 24 heures de prévisions pour une date future, et pour aujourd'hui, les heures précédentes (historique), l'heure actuelle et les heures restantes (prévisions). Horizons temporels acceptés par domaine : * Météo : toutes les heures, de 24 heures auparavant à 240 heures (10 jours) à l'avance (les heures passées nécessitent à la fois date et hour) ; tous les jours jusqu'à 10 jours, y compris aujourd'hui (aujourd'hui à +9 jours) ; pas d'historique quotidien. * Qualité de l'air : toutes les heures, de 720 heures (30 jours) dans le passé à 96 heures (4 jours) dans le futur. Un appel d'une journée complète doit s'inscrire dans cette période (en pratique, de -29 jours à +3 jours). * Pollen : quotidien uniquement, d'aujourd'hui à +4 jours (5 jours, aujourd'hui compris) ; aucune date passée, et hour est ignoré. * (Remarque : Si plusieurs fonctionnalités sont demandées et que date/hour se trouve en dehors de l'une de leurs plages, l'appel aboutit quand même et ne renvoie que les fonctionnalités compatibles.) * Requêtes hors plage : si une date ou une heure demandée se trouve en dehors de la plage acceptée d'un domaine ci-dessus (par exemple, pollen pour une date passée), appelez quand même lookup_weather pour la date/heure demandée. L'erreur indique la plage acceptée. Ne remplacez pas la date, l'heure ou le domaine par d'autres valeurs. Options de domaine et attribution : * Langue (language_code) : code de langue BCP-47 facultatif (par exemple, "fr"). La valeur par défaut est "en". * Unités météo (weather_options.units_system ou units_system) : par défaut, METRIC. Définissez cette option sur IMPERIAL (Fahrenheit/mph) si l'utilisateur implique les normes américaines ou demande explicitement des unités impériales. Compatible avec weather_options.units_system (recommandé) et units_system de premier niveau. Si les deux sont spécifiés, ils ne doivent pas être en conflit. * Options de qualité de l'air (air_quality_options) : définissez include_pollutant_concentration: true lorsque des concentrations de polluants spécifiques (PM2, 5, PM10, O3, NO2, SO2, CO) sont nécessaires. Vous pouvez également définir index_region_code (code pays ISO à deux lettres, par exemple "US") pour demander une échelle d'IQA régionale spécifique. Par défaut, la réponse inclut l'IQA universel et l'IQA régional de l'emplacement. * Attribution : la sortie ancrée DOIT être attribuée à la source à l'aide du champ attribution dans chaque conteneur de domaine renvoyé (weather.attribution, air_quality.attribution, pollen.attribution). * Heures renvoyées : les valeurs date_time de la qualité de l'air sont déjà exprimées dans l'heure locale du lieu (utc_offset inclus). Présentez-les telles quelles. Les valeurs date_time de la météo (actuelle et horaire) et les heures de lever/coucher du soleil sont exprimées en UTC. Convertissez-les dans l'heure locale du lieu à l'aide de time_zone. Indiquez que toutes les heures sont locales.
compute_routes

Calcule les itinéraires entre un point de départ et une destination, éventuellement en passant par des arrêts intermédiaires. Renvoie la distance et la durée de chaque itinéraire.

Exigences d'entrée (CRITIQUE) :

  1. origin et destination (objets - OBLIGATOIRE) : chacun doit être fourni en utilisant exactement l'un des éléments suivants :

    • address (chaîne, par exemple 'Eiffel Tower, Paris'). Les lieux nommés, les points de repère et les établissements sont résolus directement. N'appelez donc PAS search_places d'abord juste pour géocoder un point de cheminement. Incluez toute ville, région ou pays mentionné par l'utilisateur.
    • lat_lng (objet, {"latitude": number, "longitude": number}).
    • place_id (chaîne, par exemple 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'), par exemple à partir de search_places.
  2. intermediate_waypoints (tableau d'objets, FACULTATIF) : jusqu'à 25 arrêts par lesquels passer, dans l'ordre, entre le point de départ et la destination. Même format que origin. Non compatible avec TRANSIT. N'incluez que les arrêts demandés par l'utilisateur. Spécifier plus de 10 points de cheminement intermédiaires entraînera des coûts et une latence plus élevés.

  3. travel_mode (énumération, FACULTATIF) : DRIVE (par défaut), WALK, BICYCLE ou TRANSIT.

  4. Timing (OPTIONAL - set at most ONE): codes temporels RFC 3339 avec un décalage UTC, par exemple '2026-09-19T08:00:00-07:00'. La valeur par défaut est "départ immédiat". Pour TRANSIT, l'heure peut être définie jusqu'à sept jours dans le passé ou jusqu'à 100 jours dans le futur. Pour les autres modes, l'heure peut être fixée jusqu'à 365 jours dans le futur et ne doit pas être dans le passé.

    • departure_time : à utiliser lorsque l'utilisateur indique l'heure de son départ (par exemple, "demain à 8h").
    • arrival_time : à utiliser lorsque l'utilisateur indique l'heure à laquelle il doit arriver (par exemple, "arriver à 9h").
  5. routing_preference (enum - FACULTATIF) :

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (par défaut) : ignore le trafic en temps réel, les incidents et les fermetures. Latence la plus faible.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL : utilise les conditions de circulation en temps réel lorsqu'elles sont disponibles. Non compatible avec WALK ou BICYCLE. Définissez cette option UNIQUEMENT lorsque l'utilisateur pose une question sur le trafic, les embouteillages ou l'heure d'arrivée prévue ajustée en fonction du trafic. Cela entraîne des coûts et une latence plus élevés.
  6. location_bias (objet, FACULTATIF) : {"latitude": number, "longitude": number} utilisé pour lever l'ambiguïté des noms de lieux dans les adresses des points de cheminement. Si un nom est ambigu (par exemple, "Springfield") et que l'utilisateur n'a pas indiqué de région, conservez le nom tel qu'il est indiqué dans address et définissez location_bias sur la zone prévue au lieu de deviner une région.

  7. compute_alternative_routes (booléen, FACULTATIF) : défini sur true uniquement lorsque l'utilisateur demande des options ou des alternatives d'itinéraire. La valeur par défaut est false, qui ne renvoie que l'itinéraire recommandé.

  8. include_polyline (booléen, FACULTATIF) : définissez cette option sur true uniquement lorsque la géométrie de l'itinéraire (encoded_polyline) est nécessaire. La valeur par défaut est false.

Instructions pour l'appel d'outil :

  • Si le point de départ ou la destination est manquant, vous DEVEZ demander des précisions à l'utilisateur avant d'appeler l'outil.
  • Pour les questions du type "À quelle distance se trouve A de B ?", utilisez B comme origin et A comme destination.

Exemple d'appel d'outil : {"origin":{"address":"Tour Eiffel"},"destination":{"place_id":"ChIJt_5xIthw5EARoJ71mGq7t74"},"intermediate_waypoints":[{"address":"Musée du Louvre"}],"travel_mode":"DRIVE","departure_time":"2026-09-19T08:00:00+02:00"}

Instructions for Response:

  • Lorsque des itinéraires alternatifs sont demandés, ils sont classés du plus recommandé au moins recommandé.
  • Si routes est vide, indiquez à l'utilisateur qu'aucun itinéraire n'a été trouvé. Ne devinez pas un itinéraire.
  • Pour trouver des lieux le long d'un itinéraire DRIVE, transmettez le retrieval_token de l'itinéraire à search_along_route. Le jeton est valide pendant 10 minutes.
  • N'indiquez que les faits renvoyés par l'outil. N'inventez PAS d'itinéraires détaillés, de lignes de transports en commun, de stations, de quais ni de correspondances.
  • La sortie ancrée doit être attribuée à la source à l'aide du champ attribution de chaque itinéraire, lorsqu'il est disponible.
search_along_route

Appelez cet outil lorsque l'utilisateur souhaite trouver des lieux, des établissements ou des points d'intérêt sur un itinéraire (par exemple, "stations-service sur mon trajet vers Tahoe", "cafés entre SF et San Jose"). L'appel de cet outil entraîne un coût plus élevé que search_places. Utilisez donc plutôt search_places lorsque vous effectuez une recherche à proximité d'un seul lieu plutôt que le long d'un itinéraire.

Exigences d'entrée (CRITIQUE) :

  1. text_query (chaîne, OBLIGATOIRE) : description en langage naturel de ce qu'il faut rechercher le long de l'itinéraire.

    • Exemples : 'ev chargers', 'coffee', 'vegetarian restaurants', 'rest stops'.
  2. Spécification de l'itinéraire (OBLIGATOIRE : fournissez exactement UNE des options suivantes) :

    • retrieval_token (chaîne) : retrieval_token renvoyé par un appel compute_routes précédent pour une route DRIVE. Privilégiez cette option lorsque l'itinéraire a déjà été calculé. Le jeton est valide pendant 10 minutes.
    • route_endpoints (objet) : origin et destination de l'itinéraire. Chacun doit être fourni à l'aide de address, lat_lng ou place_id.
      • Exemple : {"route_endpoints": {"origin": {"address": "San Francisco, CA"}, "destination": {"address": "Lake Tahoe, CA"}}}
    • encoded_polyline (chaîne) : polyligne encodée représentant un itinéraire DRIVE.
  3. travel_mode (énumération - FACULTATIF) : DRIVE (par défaut), WALK ou BICYCLE. WALK et BICYCLE ne sont compatibles qu'avec route_endpoints. TRANSIT n'est pas compatible.

  4. routing_preference (énumération - FACULTATIF) :

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (par défaut) : calcule l'itinéraire et les détours sans tenir compte du trafic en temps réel. Latence la plus faible.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL : utilise les conditions de circulation en temps réel lorsqu'elles sont disponibles. Non compatible avec WALK ou BICYCLE. Définissez cette option UNIQUEMENT lorsque l'utilisateur pose des questions sur le trafic, les embouteillages ou les temps de détour ajustés en fonction du trafic. Elle entraîne une latence plus élevée.
  5. include_extended_details (booléen, FACULTATIF) : définissez cette option sur true uniquement lorsque la requête nécessite des insights d'avis qualitatifs, des plats ou des offres spécifiques, l'ambiance, des conseils ou l'affluence des visiteurs, la disponibilité des bornes pour véhicules électriques, les prix du carburant ou d'autres détails qualitatifs enrichis. La valeur par défaut est false. L'activer peut augmenter la latence.

  6. language_code (chaîne, FACULTATIF) : langue du résumé des résultats et des détails du lieu, par exemple en, ja, en-US. La valeur par défaut est en-US.

  7. region_code (chaîne, FACULTATIF) : code de région CLDR Unicode de l'utilisateur, par exemple US, CA.

Instructions pour l'appel d'outil :

  • Chaque résultat inclut un detour_summary (si disponible) décrivant la distance supplémentaire (localized_detour_distance) et, sauf si l'itinéraire a été indiqué comme encoded_polyline, le temps supplémentaire (detour_duration) nécessaire pour s'arrêter à cet endroit. Utilisez-le pour comparer les options.
  • La réponse summary peut contenir des citations basées sur zéro (par exemple, "[0]") faisant référence à des entrées dans results.
  • La sortie ancrée doit être attribuée à la source à l'aide du champ attribution de chaque results[].place, lorsqu'il est disponible.
resolve_names

Résout une liste de requêtes de lieux spécifiques (noms de points de repère ou adresses exactes) en ID de lieu Google Maps canoniques.

Exigences d'entrée (CRITIQUE) :

  1. queries (tableau d'objets - OBLIGATOIRE) : liste des requêtes de localisation à résoudre. Vous pouvez spécifier jusqu'à 20 requêtes.

    • Chaque objet de requête doit comporter les éléments suivants :
      • text (chaîne, OBLIGATOIRE) : requête textuelle représentant un nom de lieu ou une adresse spécifique à résoudre.
        • Exemples : 'Googleplex, Mountain View, CA', '1600 Amphitheatre Pkwy, Mountain View, CA', 'Eiffel Tower, Paris'.
  2. location_bias (objet, FACULTATIF) : utilisez ce paramètre pour prioriser les résultats situés à proximité d'une zone géographique spécifique.

    • Format : {"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}}
  3. region_code (chaîne, FACULTATIF) : code de région CLDR au format Unicode (code pays à deux lettres, par exemple US, CA) de l'utilisateur pour biaiser les résultats.

Instructions pour l'appel d'outil :

  • Spécificité (CRITIQUE) : les requêtes doivent représenter un nom de lieu ou une adresse spécifiques. Les recherches générales telles que 'restaurants' ou les noms de chaînes comme 'Starbucks' ne sont pas acceptés.
  • N'appelez PAS cet outil si les outils en aval que vous prévoyez d'appeler acceptent déjà directement les chaînes d'adresse ou de nom de lieu brutes.

Enregistrer dans Google Maps

  • La réponse inclut un champ save_to_maps_url : un seul lien Google Maps contenant tous les lieux résolus avec succès.
  • Lorsque l'utilisateur souhaite enregistrer, partager ou ouvrir les lieux résolus sous forme de liste dans Google Maps, présentez-lui ce lien. Ne construisez PAS ce lien vous-même.

Gestion des exceptions (CRITIQUE) :

  • Il s'agit d'un outil de traitement par lot. Une requête peut renvoyer des "résultats mitigés" (par exemple, certaines requêtes aboutissent, tandis que d'autres échouent).
  • La liste de sortie de results est garantie de correspondre à un mappage 1:1 avec les indices queries d'entrée. Une requête ayant échoué génère un message Result vide (aucun entity n'est défini) à l'index correspondant dans la liste results.
  • Vous DEVEZ vérifier le champ de mappage failed_requests dans la réponse pour identifier l'index de requête spécifique qui a échoué. La clé de failed_requests représente l'index de base 0 de la requête ayant échoué dans la requête. Ne partez pas du principe que l'intégralité de l'appel par lot a échoué en raison d'un échec partiel.
resolve_maps_urls

Résout une liste d'URL Google Maps en ID de lieu Google Maps canoniques.

Quand appeler cet outil (CRITIQUE) :

  • Utilisez cet outil lorsque l'utilisateur fournit un ou plusieurs liens ou URL de partage Google Maps (par exemple, "https://maps.app.goo.gl/...", "https://www.google.com/maps/place/..." ou "https://maps.google.com/...") et que vous devez extraire les ID de lieu canoniques sous-jacents.
  • Vous pouvez spécifier jusqu'à 20 URL à résoudre dans une même requête par lot.

Exigences d'entrée (CRITIQUE) :

  • urls (tableau de chaînes, OBLIGATOIRE) : liste des URL Google Maps à résoudre. Chaque URL doit être une URL Google Maps valide et ne correspondre qu'à un seul lieu.

Enregistrer dans Google Maps

  • La réponse inclut un champ save_to_maps_url : un seul lien Google Maps contenant tous les lieux résolus avec succès.
  • Lorsque l'utilisateur souhaite enregistrer, partager ou ouvrir les lieux résolus sous forme de liste dans Google Maps (par exemple, pour collecter les lieux partagés dans une conversation), présentez-lui ce lien. Ne construisez PAS ce lien vous-même.

Gestion des exceptions (CRITIQUE) :

  • Il s'agit d'un outil de traitement par lot. Une requête peut renvoyer des "résultats mitigés" (par exemple, certaines URL sont résolues, mais d'autres échouent).
  • La liste de sortie de entities est garantie de correspondre à un mappage 1:1 avec les indices urls d'entrée. L'échec de la résolution d'une URL entraîne un message Entity vide (aucun champ n'est défini) à l'index correspondant dans la liste entities.
  • Vous DEVEZ vérifier le champ de mappage failed_requests dans la réponse pour identifier l'index d'URL spécifique qui a échoué. La clé de failed_requests représente l'index de base 0 de l'URL ayant échoué dans la requête. Ne partez pas du principe que l'intégralité de l'appel par lot a échoué en raison d'un échec partiel.

Obtenir les spécifications de l'outil MCP

Pour obtenir les spécifications des outils MCP pour tous les outils d'un serveur MCP, utilisez la méthode tools/list. L'exemple suivant montre comment utiliser curl pour lister tous les outils et leurs spécifications actuellement disponibles sur le serveur MCP.

Requête 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
}'