KI-Agenten mit dem Maps Grounding Lite-MCP-Server mit georäumlichem Kontext aus der realen Welt verknüpfen

Die Entwicklung von KI-Agenten stellt eine bedeutende Weiterentwicklung in der Softwareentwicklung dar. Sie ermöglicht es Systemen, komplexe Schlussfolgerungen zu ziehen und autonomer zu agieren. Die Foundation Models, die diese Systeme antreiben, sind jedoch naturgemäß durch ihre Trainingsdaten eingeschränkt. Ohne externen Kontext wissen sie nichts über Echtzeitbedingungen, z. B. das aktuelle Wetter draußen, ob ein lokales Unternehmen gerade geöffnet ist oder die effizienteste Route zu einem Ziel.

In diesem Dokument wird beschrieben, wie Sie die Lücke zwischen statischen Schlussfolgerungen und der dynamischen Realität schließen können, indem Sie Ihre KI-Agenten mit vertrauenswürdigen geografischen Daten aus Google Maps fundieren. Sie erfahren, warum die räumliche Fundierung für Aufgaben in der realen Welt so wichtig ist, wie das Model Context Protocol (MCP) die Tool-Integration vereinfacht und wie Sie mit Google Maps Grounding Lite MCP einen Reiseplanungsagenten erstellen.

Diagramm des Reiseplaner-Agents
Mit Maps MCP fundierter Reiseplanungsagent

Warum müssen Agenten mit Kartendaten fundiert werden?

Der Übergang von traditioneller Software zu agentischen Arbeitsabläufen bedeutet eine Verlagerung von deterministischer Entwicklung zu probabilistischer Orchestrierung. Wir bewegen uns von Systemen, die nur Dinge wissen, zu proaktiven Ausführungs-Engines, die tatsächlich Dinge tun. Wenn eine Anwendung diese Grenze überschreitet und in der physischen Welt Maßnahmen ergreift, ändert sich die Bedeutung von Genauigkeit völlig.

Large Language Models (LLMs) verstehen Logik, aber ihr interner Speicher ist eine Momentaufnahme der Vergangenheit. Wenn ein Agent beispielsweise eine Lieferkette verwaltet und die Verfügbarkeit eines Lieferanten oder eine Straßenroute falsch bestätigt, führt das zu verschwendetem Kraftstoff, verpassten SLAs und echten Geschäftsunterbrechungen. In Architekturen mit mehreren Agenten kann es zu einem kaskadierenden Halluzinationsproblem kommen. Wenn ein Agent in der Kette halluziniert und falsche Daten an einen zweiten Agenten weitergibt, trifft das gesamte System Entscheidungen in der realen Welt, die auf einer Lüge basieren. Autonomie ohne Wahrheit wird zu einer massiven Haftung.

Die Fundierung erfordert, dass der Agent seine Trainingsgewichte verlässt. Indem Sie die KI zwingen, überprüfbare, aktuelle Fakten abzurufen – wie Ortsdaten und Routendaten –, geben Sie dem Agenten Augen und Ohren in Echtzeit und verwandeln eine statistische Vermutung in eine fundierte operative Entscheidung.

Warum MCP?

Das Model Context Protocol (MCP) ist ein offener Standard, der die Tool- und Datenintegrationen vereinfachen soll.

Bisher war es erforderlich, starre, maßgeschneiderte Wrapper zu schreiben, um ein KI-Modell mit einer externen API zu verbinden. Sie mussten die Formatierung, die Fehleranalyse und die Tool-Aufruf-Übersetzungen für jede einzelne Funktion manuell verarbeiten.

MCP standardisiert diese Integrationsebene. Durch die Implementierung eines MCP-Clients kann Ihre Anwendung serverbereitgestellte Tools dynamisch über ein einheitliches Protokoll erkennen und ausführen. So können sich Entwickler auf die Entwicklung von agentischen Netzwerken auf hoher Ebene konzentrieren, anstatt sich mit der wiederholten API-Integrationslogik zu beschäftigen.

Google Maps Grounding Lite MCP

Google Maps Grounding Lite MCP ist ein vollständig verwalteter, von Google gehosteter MCP-Server, der direkt in jedes kompatible agentische Framework eingebunden werden kann.

Derzeit bietet der Server drei Haupttools für die Fundierung:

  • Orte suchen: Fordern Sie Informationen zu Orten an und erhalten Sie KI-generierte Zusammenfassungen von Ortsdaten sowie Orts-IDs, Breiten- und Längengradkoordinaten und Google Maps-Links für jeden in der Zusammenfassung enthaltenen Ort. Sie können die zurückgegebenen Orts-IDs und Breiten- und Längengradkoordinaten mit anderen Google Maps Platform APIs verwenden, um Orte auf einer Karte anzuzeigen.
  • Wetter abrufen: Fordern Sie Informationen zum Wetter an und erhalten Sie aktuelle Bedingungen, stündliche Vorhersagen und Tagesvorhersagen.
  • Routen berechnen: Fordern Sie Informationen zu Routen für Autofahrer oder Fußgänger zwischen zwei Orten an und erhalten Sie Informationen zur Routenentfernung und -dauer.

Für den Zugriff auf den Dienst können Sie entweder einen API-Schlüssel oder OAuth verwenden. Die Google Maps Platform bietet einen kostenlosen Demo-API-Schlüssel, mit dem Entwickler sofort mit dem Prototyping beginnen können.

MCP-Architektur für Maps Grounding
Maps Grounding MCP-Architektur

Best Practices für die Integration von Maps Grounding MCP

Um die Datenrelevanz zu maximieren und strukturelle Halluzinationen zu vermeiden, sollten Sie die Systemanweisungen Ihres Agenten an diesen Kernstrategien ausrichten: * Seien Sie explizit und spezifisch: Weisen Sie den Agenten an, genaue Orte zu verwenden. „Central Park, New York“ liefert bessere Ergebnisse als „New York“, genau wie „Paris, Frankreich“ Verwechslungen mit Paris, Texas, vermeidet.

  • Allgemeine Anfragen aufschlüsseln: Bei vagen Anfragen wie „Ideen für ein Date“ sollten Sie den Agenten auffordern, die Aufgabe in spezifische Unteranfragen aufzuteilen, z. B. „romantische Restaurants“, „Kinos“ oder „Cocktailbars“.

  • Zuerst indirekte Suchanfrage, dann erkunden: Führen Sie zuerst eine umfassende indirekte Suchanfrage durch (z.B. „Japanische Restaurants mit barrierefreien Eingängen, die sonntags geöffnet sind“). Präsentieren Sie dem Nutzer Optionen und führen Sie dann eine Folgeanfrage aus, um bestimmte Details wie eine Telefonnummer für den ausgewählten Ort abzurufen.

  • Niemals Orts-IDs halluzinieren: Orts-IDs sind das entscheidende Bindeglied zwischen den Google Maps Platform-Diensten. Achten Sie darauf, dass Ihr Agent nur Orts-IDs verwendet, die explizit vom Tool „search_places“ zurückgegeben werden, anstatt eigene zu generieren.

Reiseplanungsagent mit Google ADK implementieren

In diesem Abschnitt wird gezeigt, wie Sie mit dem Google Agent Development Kit (ADK) einen Reiseplanungsagenten erstellen. Wenn Sie das ADK nicht installiert haben, lesen Sie die Entwicklerdokumentation zum Google ADK.

Die Integration des Maps MCP-Servers in ein Agenten-Framework wie das ADK ist unkompliziert. Das ADK kümmert sich um die Komplexitäten der Kontextverwaltung, sodass Sie sich auf das Verhalten des Agenten konzentrieren können.

Das Beispielprojekt hat folgende Struktur:

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

Beispiel für agent.py. Bearbeiten Sie es entsprechend Ihren Anwendungsfällen.

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]
)

Beispiel für SKILL.md. Bearbeiten Sie es entsprechend Ihren Anwendungsfällen.

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

adk web ausführen und interagieren

Führen Sie diesen Befehl im Projektverzeichnis „travel-concierge-google-maps-mcp“ aus, um die Standard-ADK-Web-UI zu starten:

adk web

Interaktion in der Benutzeroberfläche :

  • Laden Sie die Benutzeroberfläche unter http://127.0.0.1:8000 im Browser.
  • Probieren Sie Prompts wie:
    • „Ich bin am Samstag in San Francisco. Plane einen Tagesausflug für mich.“
    • „Suche nach Cafés in der Nähe des Golden Gate Park und zeige mir die Highlights der Speisekarte.“
    • „Route von GooglePlex nach SFO.“

Wenn der Agent den Prompt erhält, wertet der Planer die Absicht des Nutzers aus. Er erkennt den Bedarf an räumlichen und Wetterdaten und löst autonom die Tools „lookup_weather“, „search_places“ und „compute_routes“ über den MCP-Server aus. Der Agent erstellt dann eine faktenbasierte Reiseroute für den Nutzer.

Fazit

Die Verlagerung hin zu agentischer KI eröffnet völlig neue Möglichkeiten in den Bereichen Logistik, Reisen und Einzelhandel. Echte Autonomie erfordert jedoch eine solide Grundlage der Wahrheit.

Wenn Sie das Model Context Protocol zusammen mit Google Maps Grounding Lite verwenden, vermeiden Sie die Reibung maßgeschneiderter API-Integrationen und geben Ihren Agenten die Augen und Ohren in Echtzeit, die sie benötigen. Wenn Sie Ihre Modelle in räumlichen Livedaten verankern, treffen sie operative Entscheidungen auf der Grundlage dessen, was gerade in der physischen Welt passiert – nicht auf der Grundlage einer Momentaufnahme aus ihren Trainingsdaten.

Nächste Schritte

Hauptautoren:

Teresa Qin | Google Maps Platform DevX Engineer