La création d'agents IA représente une évolution majeure dans le développement de logiciels, car elle permet aux systèmes d'effectuer des raisonnements complexes et de fonctionner avec une plus grande autonomie. Cependant, les modèles de fondation qui pilotent ces systèmes sont naturellement limités par leurs données d'entraînement. Sans contexte externe, ils ne sont pas au courant des conditions en temps réel, comme la météo actuelle, l'ouverture d'un établissement local ou l'itinéraire le plus efficace vers une destination.
Ce document explique comment combler l'écart entre le raisonnement statique et la réalité dynamique en ancrant vos agents IA avec des données géospatiales fiables provenant de Google Maps. Vous découvrirez pourquoi l'ancrage spatial est essentiel pour les tâches réelles, comment le protocole MCP (Model Context Protocol) simplifie l'intégration des outils et comment créer un agent de planification de voyage à l'aide de Google Maps Grounding Lite MCP.
Pourquoi les agents ont-ils besoin de l'ancrage sur les données cartographiques ?
La transition des logiciels traditionnels vers les workflows agentiques est un passage de l'ingénierie déterministe à l'orchestration probabiliste. Nous passons de systèmes qui se contentent de savoir des choses à des moteurs d'exécution proactifs qui font réellement des choses. Lorsqu'une application franchit cette limite et agit dans le monde physique, les enjeux de précision changent complètement.
Les grands modèles de langage (LLM) comprennent la logique, mais leur mémoire interne est un instantané historique. Par exemple, si un agent gère une chaîne d'approvisionnement et confirme à tort la disponibilité d'un fournisseur ou un itinéraire routier, cela peut entraîner un gaspillage de carburant, un non-respect du contrat de niveau de service et une véritable perturbation de l'activité. Dans les architectures multi-agents, vous serez confronté à un problème d'hallucination en cascade. Si un agent de la chaîne hallucine et transmet des données erronées à un deuxième agent, l'ensemble du système commence à prendre des engagements réels basés sur un mensonge. L'autonomie sans vérité devient un risque majeur.
L'ancrage exige que l'agent sorte de ses pondérations d'entraînement. En forçant l'IA à récupérer des faits réels vérifiables, comme des données de lieux et d'itinéraires, vous donnez à l'agent des yeux et des oreilles en temps réel, transformant une estimation statistique en une décision opérationnelle éclairée.
Pourquoi utiliser le protocole MCP ?
Le protocole MCP (Model Context Protocol) est une norme ouverte conçue pour faciliter l'intégration d'outils et de données.
Auparavant, pour connecter un modèle d'IA à une API externe, il fallait écrire des wrappers rigides et personnalisés. Vous deviez gérer manuellement la mise en forme, l'analyse des erreurs et les traductions des appels d'outils pour chaque fonctionnalité.
Le MCP standardise cette couche d'intégration. En implémentant un client MCP, votre application peut découvrir et exécuter des outils fournis par le serveur de manière dynamique via un protocole unifié. Le développeur n'a plus à se concentrer sur l'écriture d'une logique d'intégration d'API répétitive, mais sur la conception de réseaux agentiques de haut niveau.
Google Maps Grounding Lite MCP
Google Maps Grounding Lite MCP est un serveur MCP entièrement géré et hébergé par Google qui peut être intégré directement dans n'importe quel framework d'agent compatible.
Actuellement, le serveur fournit trois outils principaux pour l'ancrage :
- Rechercher des lieux : demandez des informations sur des lieux et obtenez des résumés de données de lieux générés par l'IA, ainsi que des ID de lieu, des coordonnées de latitude et de longitude, et des liens Google Maps pour chacun des lieux inclus dans le résumé. Vous pouvez utiliser les ID de lieu, les latitudes et les longitudes renvoyés avec d'autres API Google Maps Platform pour afficher des lieux sur une carte.
- Rechercher la météo : demandez des informations sur la météo et obtenez les conditions actuelles, les prévisions horaires et les prévisions quotidiennes.
- Calculer des itinéraires : demandez des informations sur les itinéraires en voiture ou à pied entre deux lieux, et obtenez des informations sur la distance et la durée de l'itinéraire.
Pour accéder au service, vous pouvez utiliser une clé API ou OAuth. Google Maps Platform fournit une clé API de démonstration sans frais, spécialement conçue pour aider les développeurs à commencer à prototyper immédiatement.
Bonnes pratiques pour l'intégration du MCP d'ancrage Maps
Pour maximiser la pertinence des données et éliminer les hallucinations structurelles, ancrez les instructions système de votre agent autour de ces stratégies de base : * Soyez explicite et précis : demandez à l'agent d'utiliser des emplacements précis. "Central Park, New York" donne de meilleurs résultats que "New York", tout comme "Paris, France" évite toute confusion avec Paris, Texas.
Décomposer les requêtes génériques : pour les requêtes vagues comme "idées de rendez-vous galant", demandez à l'agent de décomposer la tâche en sous-recherches spécifiques telles que "restaurants romantiques", "cinémas" ou "bars à cocktails".
Découverte d'abord, exploration ensuite : effectuez d'abord une recherche de découverte générale (par exemple, "restaurants japonais avec entrées accessibles ouverts le dimanche"). Présentez des options à l'utilisateur, puis exécutez une requête de suivi pour récupérer des informations spécifiques, comme le numéro de téléphone du lieu choisi.
Ne jamais halluciner d'ID de lieu : les ID de lieu sont le tissu conjonctif essentiel entre les services Google Maps Platform. Assurez-vous que votre agent sait qu'il ne doit utiliser que les ID de lieu explicitement renvoyés par l'outil search_places, plutôt que d'essayer de générer les siens.
Implémenter un agent de planification de voyage avec Google ADK
Cette section explique comment créer un agent de planification de voyage à l'aide du framework Google Agent Development Kit (ADK). Si l'ADK n'est pas installé, consultez la documentation de développement de l'ADK Google.
L'intégration du serveur MCP Maps dans un framework d'agent comme l'ADK est simple. L'ADK gère les complexités de la gestion du contexte, ce qui vous permet de vous concentrer sur le comportement de l'agent.
L'exemple de projet présente la structure suivante :
travel-concierge-google-maps-mcp/
├── travel_planner_agent/
├── agent.py # main agent code
├── .env # API keys
├── __init__.py
├── skills/travel-concierge/
├── SKILL.md # Agent skill
Exemple de fichier agent.py. Modifiez-le en fonction de vos cas d'utilisation.
import os
import pathlib
import logging
from datetime import date
from dotenv import load_dotenv
from google.adk.agents.llm_agent import Agent
from google.adk.skills import load_skill_from_dir
from google.adk.tools import skill_toolset
from google.adk.tools.mcp_tool import McpToolset
from google.adk.planners import BuiltInPlanner
from google.genai import types
from google.adk.tools.mcp_tool.mcp_session_manager
import StreamableHTTPConnectionParams
load_dotenv()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
GOOGLE_MAPS_API_KEY = os.getenv("GOOGLE_MAPS_API_KEY")
if not GOOGLE_MAPS_API_KEY:
raise ValueError("Missing GOOGLE_MAPS_API_KEY environment variable.")
current_date = date.today().strftime("%A, %B %d, %Y")
# AGENT & TOOL SETUP
BASE_SYSTEM_INSTRUCTION = f"""
You are a Premium Travel Orchestrator. Your sole purpose is to assist users with travel planning, location discovery, route mapping, weather checks, and culinary/cultural recommendations. The current system date is {current_date}.
# 1. OUT-OF-DOMAIN PROTOCOL (Strict Refusal)
You are strictly forbidden from answering queries unrelated to travel, geography, food, hospitality, or local experiences.
If a user asks about coding (e.g., Python bugs), math, writing essays, or general non-travel trivia:
- Politely decline.
- Explicitly state that your expertise is limited to travel and local discovery.
- Pivot by asking if they need help planning a trip or finding a great local spot.
# 2. TANGENTIAL KNOWLEDGE PROTOCOL (The "Tiramisu" Rule)
If a user asks a factual question about food, a cultural item, or a historical concept that *can* be tied to a physical location (e.g., "What is tiramisu?", "What is Gothic architecture?"):
- Provide a brief, helpful 1-2 sentence explanation of the concept.
- IMMEDIATELY pivot to your primary domain. Ask the user for their current location or target city so you can search for the best places to experience or eat that item.
# 3. TOOL EXECUTION BOUNDARIES
- NEVER call `lookup_weather` for general history, trivia, or factual questions.
- ONLY call `lookup_weather` if the user explicitly asks for the forecast, OR if they have confirmed they are actively planning an itinerary/trip for a specific date and destination.
"""
travel_skill = load_skill_from_dir(
pathlib.Path(__file__).parent / "skills" / "travel-concierge"
)
maps_mcp_toolset = McpToolset(
connection_params=StreamableHTTPConnectionParams(
url="https://mapstools.googleapis.com/mcp",
headers={
"X-Goog-Api-Key": GOOGLE_MAPS_API_KEY,
"Content-Type": "application/json",
"Accept": "application/json, text/event-stream"
}
)
)
my_skill_toolset = skill_toolset.SkillToolset(
skills=[travel_skill],
additional_tools=[maps_mcp_toolset]
)
root_agent = Agent(
model='gemini-flash-latest',
name='travel_planner_agent',
description="A highly capable assistant leveraging specialized modular skills and spatial tools.",
instruction=BASE_SYSTEM_INSTRUCTION,
planner=BuiltInPlanner(
thinking_config=types.ThinkingConfig(
include_thoughts=True
)
),
tools=[my_skill_toolset]
)
Exemple de fichier SKILL.md. Modifiez-le en fonction de vos cas d'utilisation.
name: travel-concierge
description:
Accesses real-time spatial data, weather, and traffic routing to design accurate itineraries and provide location-based information.
Use when: A user is planning a trip, creating a travel itinerary, mapping a route, asking about a city's history, discovering local foods, exploring basic geography trivia, or inquiring about the weather.
Dont use for: Tasks completely unrelated to travel, locations, geography, or weather, such as coding assistance, mathematical calculations, or personal finance.
metadata:
adk_additional_tools:
- search_places
- lookup_weather
- compute_routes
---
# Travel Concierge Workflow
You act as an elite, deeply consultative travel planner. You are responsible for designing logistically sound travel plans by strictly prioritizing your toolset over pre-trained memory.
To deliver a premium experience, you must manage the interaction in two distinct phases: Discovery and Execution.
## Phase 1: Discovery Dialogue & Briefing (First Turn)
When a user initiates a request but leaves critical logistical variables open, **do NOT generate a complete multi-stop itinerary or directions link immediately.** Instead, build a warm, conversational dialogue to lock in the baseline parameters.
1. **Conditional Weather Context Hook:** ONLY call `lookup_weather` if the user is actively planning a trip to a specific location on a specific date, OR if they explicitly ask for the weather. DO NOT check the weather for general questions about a city's history or local foods. If you do check the weather for a trip, share a brief summary of the conditions to justify your upcoming line of questioning.
2. **Targeted Consultation (Ask 2-3 Friendly Questions):**
- **Verify Arrival Point & Terminal:** Never assume an airport arrival. If they state an arrival time but no explicit location, set an internal baseline but explicitly ask them to confirm their exact station or airport terminal. **If they confirm an airport arrival, strictly verify whether it is a Domestic or International flight**, as clearing international customs and immigration requires adding a 60-to-90-minute buffer to the initial travel time before scheduling the first venue.
- **Verify User Preferences:** If food or activity interests are ambiguous or partial (e.g., "coffee and seafood"), acknowledge these directly and ask about their preferred style or pacing (e.g., casual local markets vs. seated upscale dining).
- **Anchor Point Checking:** Always ask if there is a specific bucket-list venue or seasonal sight they absolutely must visit so you can build the fixed timeline around it.
## Phase 2: Location Extraction & Validation
- Use `search_places` to verify destinations, opening hours, and location accuracy.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user mentions "boutique hotels" or "seafood dinner", you must modify the query to include the city (e.g., text_query="boutique hotels in Sydney, Australia").
## Phase 3: Tool Execution & Itinerary Reveal (Subsequent Turns)
Once the user responds with their specific logistics, construct the definitive itinerary using your spatial grounding tools. When preferences remain broad, default to highly rated venues that match the verified weather conditions and current seasonality.
### 1. Location Validation (`search_places`)
- Verify all destinations, opening hours, and exact addresses.
- **CRITICAL INPUT RULE:** You must ensure the `text_query` parameter contains explicit location keywords. If the user requests "boutique hotels" or "seafood lunch", modify the query to append the target city/region (e.g., `text_query="seafood lunch in Sydney, Australia"`).
### 2. Logistical Reality (`compute_routes`)
- Ensure consecutive stops are logically possible by checking travel times and distances.
- Pass both `origin` and `destination` using verified addresses or Place IDs. If either is missing, halt and ask for clarification.
- Do NOT hallucinate Place ID. You must use the Place ID provided by `search_places`.
### 3. Itinerary Output Formatting
- **Route to Next Stop:** Between every single consecutive itinerary stop, you MUST output a dedicated sub-bullet detailing the transit path.
- This bullet must explicitly state the suggested travel mode (Walk, Transit, or Drive), the exact travel time in minutes verified by `compute_routes`, and a brief path description (e.g., *"Route to Next Stop: 12-minute walk via Market St"*).
- **Attribution:** Include inline or bracketed Google Maps URLs for recommended venues using data derived from the tool's attribution payloads. Do not guess links.
### 4. Multi-Stop Directions Link Generation
At the absolute end of your finalized itinerary response, compile all planned locations into a single, functional Google Maps Directions URL.
- **Format Constraint:** Build the URL using the base string: `https://www.google.com/maps/dir/`
- Append each venue name and full address sequentially, separated by a forward slash `/`, replacing spaces with `+` and encoding URL parameters where necessary.
- Example format: `https://www.google.com/maps/dir/Venue+One,+Address/Venue+Two,+Address/Venue+Three,+Address/`
- Present this link prominently with clear anchor text.
## Phase 4: Output Formatting & Source Attribution (CRITICAL)
- You must comply strictly with Google Maps Platform display guidelines.
- Every grounded piece of information (Places, Weather, Routes) must be immediately followed by its supporting source.
- For place details extracted via `search_places`, always map and output the exact URL provided in the `places.googleMapsLinks.placeUrl` payload. Do not invent links.
init.py
from . import agent
Exécuter adk web et interagir
Pour démarrer l'UI Web ADK par défaut, exécutez cette commande dans le répertoire du projet travel-concierge-google-maps-mcp :
adk web
Interagir dans l'UI :
- Chargez l'UI à l'adresse http://127.0.0.1:8000 dans le navigateur.
- Quelques idées de prompts :
- "Je serai à San Francisco samedi. Planifie une excursion d'une journée pour moi."
- "Trouve des cafés près du Golden Gate Park et montre-moi les plats phares du menu."
- "Get directions from GooglePlex to SFO."
Lorsque l'agent reçoit le prompt, le planificateur évalue l'intention de l'utilisateur. Il reconnaît le besoin de données spatiales et météorologiques, et déclenche de manière autonome les outils lookup_weather, search_places et compute_routes à l'aide du serveur MCP. L'agent synthétise ensuite un itinéraire basé sur des faits pour l'utilisateur.
Conclusion
La transition vers l'IA agentive ouvre de toutes nouvelles possibilités dans les secteurs de la logistique, du voyage et du commerce. Cependant, une véritable autonomie nécessite une base de vérité solide.
En exploitant le Model Context Protocol avec l'ancrage Google Maps Lite, vous éliminez les frictions liées aux intégrations d'API sur mesure et donnez à vos agents les yeux et les oreilles dont ils ont besoin en temps réel. En ancrant vos modèles dans des données spatiales en temps réel, vous vous assurez qu'ils prennent des décisions opérationnelles basées sur ce qui se passe dans le monde physique en ce moment même, et non sur un instantané figé de leurs données d'entraînement.
Actions suivantes
- Consultez la documentation pour les développeurs sur l'ancrage Maps MCP.
- Obtenez une clé API de démonstration.
- Découvrez comment déployer votre agent.
Auteurs principaux :
Teresa Qin | Ingénieure DevX Google Maps Platform