MCP Reference: mapstools.googleapis.com

Dies ist ein MCP-Server, der von Maps Experience Agent Tools bereitgestellt wird. Der Server bietet Entwicklern Tools zum Erstellen von LLM-Anwendungen auf der Google Maps Platform.

Ein Model Context Protocol (MCP)-Server fungiert als Proxy zwischen einem externen Dienst, der einem Large Language Model (LLM) oder einer KI-Anwendung Kontext, Daten oder Funktionen bereitstellt. MCP-Server verbinden KI-Anwendungen mit externen Systemen wie Datenbanken und Webdiensten und übersetzen deren Antworten in ein Format, das die KI-Anwendung versteht.

Server einrichten

Sie müssen MCP-Server aktivieren und die Authentifizierung einrichten, bevor Sie sie verwenden können. Weitere Informationen zur Verwendung von Remote-MCP-Servern von Google und Google Cloud finden Sie unter Google Cloud-MCP-Server – Übersicht.

Serverendpunkte

Ein MCP-Dienstendpunkt ist die Netzwerkadresse und Kommunikationsschnittstelle (normalerweise eine URL) des MCP-Servers, die eine KI-Anwendung (der Host für den MCP-Client) verwendet, um eine sichere, standardisierte Verbindung herzustellen. Er ist der Kontaktpunkt für das LLM, um Kontext anzufordern, ein Tool aufzurufen oder auf eine Ressource zuzugreifen.

Der MCP-Server für die Maps Experience Agent Tools hat den folgenden globalen MCP-Endpunkt:

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

MCP-Tools

Ein MCP-Tool ist eine Funktion oder ausführbare Fähigkeit, die ein MCP-Server einem LLM oder einer KI-Anwendung zur Verfügung stellt, um eine Aktion in der realen Welt auszuführen.

Tools

Der MCP-Server mapstools.googleapis.com bietet die folgenden Tools:

MCP-Tools
search_places	Rufen Sie dieses Tool auf, wenn der Nutzer nach Orten, Unternehmen, Adressen, Standorten, POIs oder anderen Google Maps-bezogenen Suchanfragen sucht. Eingabeanforderungen (WICHTIG): text_query (String – ERFORDERLICH): Die primäre Suchanfrage. Hier muss klar definiert werden, wonach der Nutzer sucht. Beispiele: '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'. Für bestimmte Ortsdetails: Geben Sie das gewünschte Attribut an (z.B. 'Google Store Mountain View opening hours', 'SF MoMa phone number', 'Shoreline Park Mountain View address'). location_bias (Objekt – OPTIONAL): Hiermit können Sie Ergebnisse in der Nähe eines bestimmten geografischen Bereichs priorisieren. Format: {"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}} Verwendung: Umkreis von 5 km bevorzugen: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}, "radius_meters": 5000}}} Starke Gewichtung des Mittelpunkts: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}}}} (radius_meters wird weggelassen). language_code (String – OPTIONAL): Die Sprache, in der die Zusammenfassung der Suchergebnisse angezeigt werden soll. Format: Ein zweistelliger Sprachcode (ISO 639-1), optional gefolgt von einem Unterstrich und einem zweistelligen Ländercode (ISO 3166-1 alpha-2), z.B. en, ja, en_US, zh_CN, es_MX. Wenn der Sprachcode nicht angegeben ist, werden die Ergebnisse auf Englisch ausgegeben. region_code (String – OPTIONAL): Der Unicode-CLDR-Regionscode des Nutzers. Mit diesem Parameter werden die Ortsdetails angezeigt, z. B. der regionsspezifische Ortsname, falls verfügbar. Der Parameter kann sich je nach geltendem Recht auf die Ergebnisse auswirken. Format: Ein zweistelliger Ländercode (ISO 3166-1 alpha-2), z.B. US, CA. page_size (Ganzzahl – OPTIONAL): Die maximale Anzahl von Orten, die zurückgegeben werden sollen (zwischen 1 und 10). Die Standardeinstellung ist 5. Legen Sie einen Wert über 5 nur fest, wenn der Nutzer mehr als 5 Orte vergleichen möchte. Werte von 6 bis 10 führen zu höheren Kosten und einer höheren Latenz. include_extended_details (boolescher Wert – OPTIONAL): Setzen Sie dieses Feld auf true, wenn die Nutzeranfrage umfassende qualitative Informationen, Echtzeitdynamik oder spezielle Entitätsattribute erfordert. Die Standardeinstellung ist false. Wenn Sie diesen Wert auf true setzen, fallen höhere Kosten und eine höhere Latenz an. Anweisungen für den Toolaufruf: Standortinformationen (WICHTIG): Die Suchanfrage muss ausreichende Standortinformationen enthalten. Wenn der Ort nicht eindeutig ist (z.B. nur „Pizzerien“), müssen Sie ihn in der text_query angeben (z.B. „Pizzerien in New York“) oder den Parameter location_bias verwenden. Geben Sie bei Bedarf Stadt, Bundesland/Provinz und Region/Land an, um Mehrdeutigkeiten zu vermeiden. Geben Sie immer die spezifischste und kontextreichste text_query an. Verwenden Sie location_bias nur, wenn Koordinaten explizit angegeben sind oder wenn es angemessen und notwendig ist, einen Standort aus dem bekannten Kontext eines Nutzers abzuleiten, um bessere Ergebnisse zu erzielen. Die fundierte Ausgabe muss der Quelle zugeordnet werden. Verwenden Sie dazu die Informationen aus dem Feld attribution, falls verfügbar.
lookup_weather	Ruft umfassende Umweltdaten für einen Standort ab, einschließlich Wetter, Luftqualität (AQI und Schadstoffe) und Pollen (Allergenwerte für Baum-, Gras-, Unkraut- und Pflanzenarten): aktuelle Bedingungen, stündliche Vorhersagen/Verlauf und tägliche Vorhersagen für Wetter und Luftqualität; Pollen ist nur eine tägliche Vorhersage (heute bis +4 Tage, keine stündlichen oder vergangenen Daten). Verfügbare Umgebungsdomains und -funktionen (capabilities: WEATHER, AIR_QUALITY, POLLEN – WICHTIG): * Explizite Auswahl erforderlich: Sie MÜSSEN bei jedem Aufruf mindestens einen der Werte WEATHER, AIR_QUALITY oder POLLEN in capabilities angeben. Das Weglassen von capabilities ist NICHT zulässig. * Allgemeine/mehrdeutige Outdoor-Anfragen (vollständige Ambient Outdoor Suite): Wenn der Nutzer eine allgemeine Frage zu Outdoor-Aktivitäten, Reisen oder der aktuellen Situation stellt, ohne sich auf einen bestimmten Bereich zu beschränken (z. B. „Wie sind die Bedingungen draußen gerade für einen Lauf?“), beziehen Sie explizit alle drei Funktionen ein (capabilities: ["WEATHER", "AIR_QUALITY", "POLLEN"]), um die vollständige Ambient Outdoor Suite (Wetter + Luftqualität + Pollen) zurückzugeben. Lassen Sie für eine vergangene date/hour POLLEN weg, da dafür kein Verlauf verfügbar ist. * Gezielte Domainauswahl (spezifische Anfragen): Wenn der Nutzer ausdrücklich nach nur einer oder zwei Domains fragt (z.B. „Wie ist der LQI in Seattle in Echtzeit?“), füge nur die angeforderten Funktionen (WEATHER, AIR_QUALITY und/oder POLLEN) hinzu. Nur die angeforderten Domains werden ausgeführt und zurückgegeben. Spezifische Daten nach Domain: * Wetter (weather): Temperatur (aktuell, gefühlt, Max/Min, Hitzeindex), Wind (Geschwindigkeit, Böen, Richtung), Himmelsereignisse (Sonnenaufgang/-untergang, Mondphase), Niederschlag (Typ, Wahrscheinlichkeit, Menge/QPF) und atmosphärische Bedingungen (UV-Index, Luftfeuchtigkeit, Bewölkung, Gewitterwahrscheinlichkeit, Luftdruck). * Luftqualität (air_quality): Universeller und lokaler Luftqualitätsindex (LQI-Wert, Kategorie, dominanter Schadstoff), Gesundheitsempfehlungen für 7 Empfindlichkeitsgruppen und Schadstoffkonzentrationen (include_pollutant_concentration: true). Jeder Index hat seinen eigenen dominanten Schadstoff. Geben Sie ihn pro Index an (z. B. nicht den Schadstoff des universellen LQI für den US-LQI). * Pollen (pollen): Täglicher Universal Pollen Index (UPI, 0–5) pro Baum-, Gras- und Unkrautkategorie und pro Pflanzenart (index.value mit index.category, z.B. 1 = „Sehr niedrig“), Status der Saison, Kreuzreaktionen und Gesundheitsempfehlungen. * Fehlende Pollenfelder: Ein fehlendes in_season bedeutet, dass die Pollenart gerade keine Saison hat. Lass Pflanzenarten weg, die ohne index zurückgegeben werden, es sei denn, der Nutzer fragt nach dieser Pflanze. Sag dann, dass heute keine Pollendaten für sie gemeldet werden (leite keine Belastung ab). Standortregeln (WICHTIG): Die Zielregion MUSS in location mit NUR EINEM der folgenden oneof-Unterfelder angegeben werden: 1. Geografische Koordinaten (lat_lng): * Verwenden Sie diese Option, wenn die genauen Breiten- und Längengrade bekannt sind. * Beispiel: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} 2. Orts-ID (place_id): * Eine eindeutige Google Maps-Orts-ID (z.B. von search_places oder resolve_names). * Beispiel: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} 3. Adressstring (address): * Eine Stadt/Region, ein Viertel, eine Sehenswürdigkeit oder ein POI, eine Adresse oder eine Postleitzahl, idealerweise mit Stadt/Land. * Beispiel: {"location": {"address": "Paris, France"}} Zeit- und Nutzungsmodi (date und hour – WICHTIG): * Referenz für die lokale Zeitzone: Alle date- ({year, month, day}) und hour-Eingaben (0-23) MÜSSEN in der lokalen Zeitzone des angeforderten location angegeben werden (z.B. verwendet eine Abfrage für "Paris tomorrow at 13:00" das lokale Datum und die lokale Uhrzeit 13 von Europe/Paris), niemals UTC oder die Zeitzone des Aufrufers. * 1. Aktuelle Bedingungen (date weggelassen UND hour weggelassen): * Geben Sie location und das Ziel-capabilities (WEATHER, AIR_QUALITY, POLLEN) an. Geben Sie NICHT date oder hour an. * Gibt Echtzeitdaten zu den aktuellen Bedingungen (CC) für die angeforderten Bereiche zurück (aktuelles Wetter, Luftqualität für die aktuelle Stunde und/oder Pollenvorhersage für heute). * Bei der Luftqualität beziehen sich die aktuellen Bedingungen auf eine einzelne Stunde. Verwende sie NICHT allein, um Fragen zur Luftqualität oder allgemeine Fragen zum Wetter heute zu beantworten. Verwende stattdessen die unten aufgeführten täglichen Abfragen. * 2. Stündliche Vorhersage / Verlauf (date angegeben UND hour angegeben 0-23): * Geben Sie location, date ({year, month, day}), hour (0-23) und das Ziel capabilities an. Wenn Minuten erwähnt werden, runde auf die nächste volle Stunde ab. * KRITISCHE EINSCHRÄNKUNG (date ist ERFORDERLICH, wenn hour festgelegt ist): Die Angabe von hour ohne date (date weggelassen, hour festgelegt) ist NICHT zulässig und führt zu einem Fehler. Auch wenn der Nutzer nach einer bestimmten Uhrzeit heute fragt (z.B. "at 13:00 today"), MÜSSEN Sie sowohl date (das heutige Datum um location) als auch hour angeben. * Führt eine stündliche Suche nach den angeforderten Wetter- und/oder Luftqualitätsdaten für YYYY-MM-DD-HH und eine tägliche Suche nach den angeforderten Pollendaten für YYYY-MM-DD aus. * Wetterfragen mit „wann“: Verwende für Wetterfragen mit wann / um wie viel Uhr / beste Zeit (z.B. "what time will it stop raining?") stündliche WEATHER-Aufrufe (date + hour) für die relevanten Stunden. Eine tägliche Wettervorhersage enthält keine stündlichen Werte. Für allgemeine Fragen zu Outdoor-Aktivitäten, die sich auf die beste Zeit beziehen (z.B. "when is the best time to go walking today?"), solltest du zusätzlich zu den unter „Tägliche Abfragen“ beschriebenen ganztägigen Abfragen für Luftqualität (und Pollen) diese stündlichen WEATHER-Abfragen durchführen. * 3. Tägliche Abfragen (date angegeben UND hour weggelassen): * Gib location, date ({year, month, day} in der lokalen bürgerlichen Zeit des angeforderten location) ohne hour und das Ziel capabilities für ganztägige Abfragen an (z.B. "weather and pollen in London tomorrow"). * Fragen zur Luftqualität und allgemeine Fragen zu Outdoor-Aktivitäten für heute: Für Fragen zur Luftqualität und allgemeine Fragen zu Outdoor-Aktivitäten (einschließlich Luftqualität) für heute (z.B. "how will the air quality change today", "is today a good day for a picnic?") setze date auf das heutige Datum um location (Stunde weggelassen), um die stündliche Luftqualitätsreihe für den Tag zu erhalten. Ein Aufruf von „Aktuelle Bedingungen“ allein gibt nur die Luftqualität der aktuellen Stunde zurück und reicht nicht aus. Sie können einen hinzufügen, wenn der Nutzer auch nach „jetzt“ fragt. * Zeitfenster für die Luftqualität: Wenn Sie eine Frage zur Luftqualität in einem bestimmten Zeitfenster innerhalb eines Tages haben (z.B. "air quality between noon and 6 PM"), sollten Sie einen täglichen Aufruf für dieses Datum bevorzugen und die Stunden des Zeitfensters aus der Luftqualitätsreihe ablesen, anstatt einzelne Stunden abzufragen. Wenn Sie stündliche Aufrufe verwenden, decken Sie jede Stunde des Zeitfensters ab. * Gibt tägliche Vorhersagen für die angeforderten Wetter- und/oder Pollendaten sowie die stündlichen Luftqualitätsdaten für den gesamten lokalen Tag (00:00–23:00 Uhr Ortszeit) zurück: 24 Stunden Verlaufsdaten für ein vergangenes Datum, 24 Stunden Vorhersagedaten für ein zukünftiges Datum und für heute die früheren Stunden (Verlauf), die aktuelle Stunde und die verbleibenden Stunden (Vorhersage). Unterstützte Zeithorizonte nach Domain: * Wetter: Stündlich von vor 24 Stunden bis zu 240 Stunden (10 Tage) im Voraus (für vergangene Stunden sind sowohl date als auch hour erforderlich); täglich bis zu 10 Tage einschließlich heute (heute bis +9 Tage); kein täglicher Verlauf. * Luftqualität: Stündlich von vor 720 Stunden (30 Tagen) bis 96 Stunden (4 Tagen) im Voraus. Ein ganztägiger Aufruf muss in dieses Zeitfenster passen (in der Praxis heute −29 Tage bis +3 Tage). * Pollen: Nur täglich, heute bis +4 Tage (5 Tage einschließlich heute); keine vergangenen Daten, und hour wird ignoriert. * (Hinweis: Wenn mehrere Funktionen angefordert werden und der date/hour außerhalb eines ihrer Bereiche liegt, ist der Aufruf trotzdem erfolgreich und gibt nur die unterstützten Funktionen zurück.) * Anfragen außerhalb des Bereichs: Wenn ein angefordertes Datum oder eine angeforderte Uhrzeit außerhalb des oben genannten unterstützten Bereichs einer Domain liegt (z. B. Pollen für ein vergangenes Datum), rufen Sie trotzdem lookup_weather für das angeforderte Datum bzw. die angeforderte Uhrzeit auf. Der Fehler gibt den unterstützten Bereich an. Verwenden Sie kein anderes Datum, keine andere Uhrzeit und keine andere Domain als Ersatz. Domainoptionen und Attribution: * Sprache (language_code): Optionaler BCP-47-Sprachcode (z.B. "fr"). Standardmäßig "en". * Wettereinheiten (weather_options.units_system oder units_system): Standardmäßig METRIC. Setze den Wert auf IMPERIAL (Fahrenheit/mph), wenn der Nutzer US-Standards impliziert oder explizit imperiale Einheiten anfordert. Wird sowohl in weather_options.units_system (bevorzugt) als auch in units_system auf oberster Ebene unterstützt. Wenn beide angegeben sind, dürfen sie nicht in Konflikt stehen. * Optionen für die Luftqualität (air_quality_options): Legen Sie include_pollutant_concentration: true fest, wenn bestimmte Schadstoffkonzentrationen (PM2,5, PM10, O3, NO2, SO2, CO) erforderlich sind.Optional können Sie index_region_code (zweistelliger ISO-Ländercode, z.B. "US") festlegen, um eine bestimmte regionale LQI-Skala anzufordern. Standardmäßig enthält die Antwort den universellen LQI und den regionalen LQI des Standorts. * Quellenangabe: Fundierte Ausgaben MÜSSEN der Quelle zugeordnet werden. Verwenden Sie dazu das Feld attribution in jedem zurückgegebenen Domaincontainer (weather.attribution, air_quality.attribution, pollen.attribution). * Zurückgegebene Zeiten: Die Werte für die Luftqualität (date_time) sind bereits in der Ortszeit des Standorts angegeben (utc_offset enthalten). Präsentieren Sie sie unverändert. Die Werte für das Wetter (date_time, aktuell und stündlich) und die Sonnenaufgangs-/Sonnenuntergangszeiten sind in UTC angegeben. Konvertieren Sie sie mit time_zone in die Ortszeit des Standorts. Alle Zeiten als lokal kennzeichnen.
compute_routes	Berechnet Reiserouten zwischen einem Start- und einem Zielort, optional über Zwischenstopps. Gibt die Entfernung und Dauer für jede Route zurück. Eingabeanforderungen (WICHTIG): origin und destination (Objekte – ERFORDERLICH): Jedes muss mit genau einer der folgenden Optionen angegeben werden: address (String, z. B. 'Eiffel Tower, Paris'). Benannte Orte, Sehenswürdigkeiten und Unternehmen werden direkt aufgelöst. Rufen Sie also NICHT zuerst search_places auf, nur um einen Wegpunkt zu geocodieren. Berücksichtigen Sie alle Städte, Regionen oder Länder, die der Nutzer erwähnt hat. lat_lng (Objekt, {"latitude": number, "longitude": number}). place_id (String, z. B. 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'), z. B. von search_places. intermediate_waypoints (Array von Objekten – OPTIONAL): Bis zu 25 Zwischenstopps, die in der angegebenen Reihenfolge zwischen Start und Ziel angefahren werden sollen. Gleiches Format wie origin. Wird mit TRANSIT nicht unterstützt. Geben Sie nur die vom Nutzer angeforderten Zwischenstopps an. Wenn Sie mehr als 10 Zwischenwegpunkte angeben, fallen höhere Kosten und eine höhere Latenz an. travel_mode (Enum – OPTIONAL): DRIVE (Standard), WALK, BICYCLE oder TRANSIT. Zeitpunkt (OPTIONAL – höchstens EINEN festlegen): RFC 3339-Zeitstempel mit UTC-Abweichung, z.B. '2026-09-19T08:00:00-07:00'. Die Standardeinstellung ist „Jetzt abfahren“. Für TRANSIT kann die Zeit bis zu 7 Tage in der Vergangenheit oder bis zu 100 Tage in der Zukunft liegen. In anderen Modi kann die Zeit bis zu 365 Tage in der Zukunft liegen und darf nicht in der Vergangenheit liegen. departure_time: Verwenden, wenn der Nutzer angibt, wann er abreist (z.B. „morgen um 8:00 Uhr“). arrival_time: Verwenden Sie diesen Parameter, wenn der Nutzer angibt, wann er ankommen muss (z.B. „bis 9:00 Uhr da sein“). routing_preference (enum – OPTIONAL): ROUTING_PREFERENCE_TRAFFIC_UNAWARE (Standard): Live-Verkehrsinformationen, Verkehrsbehinderungen und Sperrungen werden ignoriert. Niedrigste Latenz. ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: Verwendet die aktuelle Verkehrslage, sofern verfügbar. Wird für WALK oder BICYCLE nicht unterstützt. Setzen Sie diese Option NUR, wenn der Nutzer nach dem Verkehr, Staus oder einer verkehrsabhängigen voraussichtlichen Ankunftszeit fragt. Es verursacht höhere Kosten und Latenz. location_bias (Objekt – OPTIONAL): {"latitude": number, "longitude": number} wird verwendet, um Ortsnamen in Wegpunktadressen eindeutig zu machen. Wenn ein Name mehrdeutig ist (z.B. „Springfield“) und der Nutzer keine Region angegeben hat, behalte den Namen wie in address angegeben bei und setze location_bias auf den beabsichtigten Bereich, anstatt eine Region zu erraten. compute_alternative_routes (boolesch – OPTIONAL): Setzen Sie diesen Wert nur dann auf true, wenn der Nutzer nach Routenoptionen oder Alternativen fragt. Der Standardwert ist false. Damit wird nur die empfohlene Route zurückgegeben. include_polyline (boolesch – OPTIONAL): Legen Sie diesen Wert nur dann auf true fest, wenn die Routengeometrie (encoded_polyline) benötigt wird. Die Standardeinstellung ist false. Anweisungen für den Toolaufruf: Wenn der Start- oder Zielort fehlt, MÜSSEN Sie den Nutzer um Klärung bitten, bevor Sie das Tool aufrufen. Verwenden Sie bei Fragen wie „Wie weit ist A von B entfernt?“ B als origin und A als destination. Beispiel für einen Toolaufruf: {"origin":{"address":"Eiffelturm"},"destination":{"place_id":"ChIJt_5xIthw5EARoJ71mGq7t74"},"intermediate_waypoints":[{"address":"Louvre"}],"travel_mode":"DRIVE","departure_time":"2026-09-19T08:00:00+02:00"} Anweisungen für die Antwort: Wenn alternative Routen angefordert werden, werden die Routen von der am meisten empfohlenen bis zur am wenigsten empfohlenen Route sortiert. Wenn routes leer ist, teile dem Nutzer mit, dass keine Route gefunden wurde. Raten Sie nicht, welche Route die richtige ist. Wenn Sie Orte entlang einer DRIVE-Route finden möchten, übergeben Sie die retrieval_token der Route an search_along_route. Das Token ist 10 Minuten lang gültig. Nenne nur Fakten, die vom Tool zurückgegeben werden. Erfinden Sie KEINE detaillierten Routenführungen, Linien, Haltestellen, Bahnsteige oder Umstiege. Die fundierte Ausgabe muss der Quelle zugeordnet werden. Verwenden Sie dazu das Feld attribution der jeweiligen Route, falls verfügbar.
search_along_route	Rufen Sie dieses Tool auf, wenn der Nutzer Orte, Unternehmen oder POIs entlang einer Reiseroute finden möchte (z.B. „Tankstellen auf dem Weg nach Tahoe“, „Cafés zwischen SF und San Jose“). Der Aufruf dieses Tools verursacht höhere Kosten als search_places. Verwenden Sie daher search_places, wenn Sie in der Nähe eines einzelnen Standorts und nicht entlang einer Route suchen. Eingabeanforderungen (WICHTIG): text_query (String – ERFORDERLICH): Eine Beschreibung in natürlicher Sprache, wonach entlang der Route gesucht werden soll. Beispiele: 'ev chargers', 'coffee', 'vegetarian restaurants', 'rest stops'. Routenspezifikation (ERFORDERLICH – geben Sie genau EINE der folgenden Optionen an): retrieval_token (String): Die retrieval_token, die von einem vorherigen compute_routes-Aufruf für eine DRIVE-Route zurückgegeben wurde. Diese Option sollte bevorzugt werden, wenn die Route bereits berechnet wurde. Das Token ist 10 Minuten lang gültig. route_endpoints (Objekt): Die origin und destination der Route. Jeder muss mit address, lat_lng oder place_id angegeben werden. Beispiel: {"route_endpoints": {"origin": {"address": "San Francisco, CA"}, "destination": {"address": "Lake Tahoe, CA"}}} encoded_polyline (String): Eine codierte Polylinie, die eine DRIVE-Route darstellt. travel_mode (Enum – OPTIONAL): DRIVE (Standard), WALK oder BICYCLE. WALK und BICYCLE werden nur mit route_endpoints unterstützt. TRANSIT wird nicht unterstützt. routing_preference (enum – OPTIONAL): ROUTING_PREFERENCE_TRAFFIC_UNAWARE (Standard): Die Route und Umwege werden ohne Echtzeit-Verkehrsinformationen berechnet. Niedrigste Latenz. ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: Verwendet die aktuelle Verkehrslage, sofern verfügbar. Wird für WALK oder BICYCLE nicht unterstützt. Setze diesen Wert NUR, wenn der Nutzer nach Verkehr, Staus oder verkehrsbedingten Umleitungszeiten fragt. Es führt zu einer höheren Latenz. include_extended_details (boolesch – OPTIONAL): Legen Sie diesen Wert nur dann auf true fest, wenn die Anfrage qualitative Rezensionsstatistiken, bestimmte Menüpunkte oder Angebote, die Atmosphäre, Tipps für Besucher oder die Auslastung, die Verfügbarkeit von Ladestationen für Elektrofahrzeuge, Benzinpreise oder andere detaillierte qualitative Informationen erfordert. Die Standardeinstellung ist false. Das Aktivieren kann die Latenz erhöhen. language_code (String – OPTIONAL): Die Sprache für die Ergebniszusammenfassung und die Place Details, z.B. en, ja, en-US. Die Standardeinstellung ist en-US. region_code (String – OPTIONAL): Der Unicode-CLDR-Regionscode des Nutzers, z.B. US, CA. Anweisungen für den Toolaufruf: Jedes Ergebnis enthält einen detour_summary (falls verfügbar), der die zusätzliche Entfernung (localized_detour_distance) und, sofern die Route nicht als encoded_polyline angegeben wurde, die zusätzliche Zeit (detour_duration) beschreibt, die durch den Halt an diesem Ort entsteht. Verwenden Sie sie, um Optionen zu vergleichen. Die Antwort summary kann nullbasierte Zitate (z.B. „[0]“) enthalten, die auf Einträge in results verweisen. Die fundierte Ausgabe muss der Quelle mithilfe des Felds attribution der einzelnen results[].place-Elemente zugeordnet werden, sofern verfügbar.
resolve_names	Löst eine Batchliste mit bestimmten Standortabfragen (Namen von Sehenswürdigkeiten oder genaue Adressen) in kanonische Google Maps-Orts-IDs auf. Eingabeanforderungen (WICHTIG): queries (Array von Objekten – ERFORDERLICH): Eine Liste von Standortabfragen, die aufgelöst werden sollen. Sie können bis zu 20 Abfragen angeben. Jedes Abfrageobjekt muss Folgendes enthalten: text (String – ERFORDERLICH): Die Textanfrage, die einen bestimmten Ortsnamen oder eine bestimmte Adresse darstellt, die aufgelöst werden soll. Beispiele: 'Googleplex, Mountain View, CA', '1600 Amphitheatre Pkwy, Mountain View, CA', 'Eiffel Tower, Paris' location_bias (Objekt – OPTIONAL): Hiermit können Sie Ergebnisse in der Nähe eines bestimmten geografischen Bereichs priorisieren. Format: {"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}} region_code (String – OPTIONAL): Der Unicode-CLDR-Regionscode (zweistelliger Ländercode, z.B. US, CA) des Nutzers, um die Ergebnisse zu beeinflussen. Anweisungen für den Toolaufruf: Spezifität (WICHTIG): Suchanfragen müssen einen bestimmten Ortsnamen oder eine bestimmte Adresse enthalten. Allgemeine Suchanfragen wie 'restaurants' oder Kettennamen wie 'Starbucks' werden nicht unterstützt. Rufen Sie dieses Tool NICHT auf, wenn die nachgelagerten Tools, die Sie aufrufen möchten, bereits Rohadressen oder Ortsnamenstrings direkt akzeptieren. In Google Maps speichern: Die Antwort enthält das Feld save_to_maps_url, eine einzelne Google Maps-URL, die alle erfolgreich aufgelösten Orte enthält. Wenn der Nutzer die aufgelösten Orte als Liste in Google Maps speichern, teilen oder öffnen möchte, präsentieren Sie ihm diesen Link. Erstellen Sie diesen Link NICHT selbst. Fehlerbehandlung (KRITISCH): Dies ist ein Tool für die Batchverarbeitung. Eine Anfrage kann „gemischte Ergebnisse“ zurückgeben (z.B. werden einige Abfragen erfolgreich aufgelöst, während andere fehlschlagen). Die Ausgabeliste von results wird garantiert 1:1 den Eingabe-queries-Indizes zugeordnet. Eine fehlgeschlagene Abfrage führt zu einer leeren Result-Nachricht (es wird kein entity festgelegt) am entsprechenden Index in der results-Liste. Sie MÜSSEN das Zuordnungsfeld failed_requests in der Antwort prüfen, um festzustellen, welcher Abfrageindex fehlgeschlagen ist. Der Schlüssel von failed_requests stellt den 0-basierten Index der fehlgeschlagenen Abfrage in der Anfrage dar. Gehen Sie nicht davon aus, dass der gesamte Batchaufruf aufgrund eines Teilfehlers fehlgeschlagen ist.
resolve_maps_urls	Löst eine Liste von Google Maps-URLs in kanonische Google Maps-Orts-IDs auf. Wann dieses Tool aufgerufen werden sollte (WICHTIG): Verwenden Sie dieses Tool, wenn der Nutzer einen oder mehrere Google Maps-Freigabelinks oder ‑URLs angibt (z.B. „https://maps.app.goo.gl/...“, „https://www.google.com/maps/place/...“ oder „https://maps.google.com/...“) und Sie müssen die zugrunde liegenden kanonischen Orts-IDs extrahieren. Sie können bis zu 20 URLs angeben, die in einer einzelnen Batchanfrage aufgelöst werden sollen. Eingabeanforderungen (WICHTIG): urls (Array von Strings – ERFORDERLICH): Die Liste der aufzulösenden Google Maps-URLs. Jede URL muss eine gültige Google Maps-URL für einen einzelnen Ort sein. In Google Maps speichern: Die Antwort enthält das Feld save_to_maps_url, eine einzelne Google Maps-URL, die alle erfolgreich aufgelösten Orte enthält. Wenn der Nutzer die aufgelösten Orte als Liste in Google Maps speichern, teilen oder öffnen möchte (z.B. um Orte zu sammeln, die in einer Unterhaltung geteilt wurden), präsentiere ihm diesen Link. Erstellen Sie diesen Link NICHT selbst. Fehlerbehandlung (KRITISCH): Dies ist ein Tool für die Batchverarbeitung. Eine Anfrage kann „gemischte Ergebnisse“ zurückgeben (z.B. werden einige URLs erfolgreich aufgelöst, andere nicht). Die Ausgabeliste von entities wird garantiert 1:1 den Eingabe-urls-Indizes zugeordnet. Eine fehlgeschlagene URL-Auflösung führt zu einer leeren Entity-Nachricht (es sind keine Felder festgelegt) am entsprechenden Index in der entities-Liste. Sie MÜSSEN das Zuordnungsfeld failed_requests in der Antwort prüfen, um festzustellen, bei welchem URL-Index der Fehler aufgetreten ist. Der Schlüssel von failed_requests stellt den 0-basierten Index der fehlgeschlagenen URL in der Anfrage dar. Gehen Sie nicht davon aus, dass der gesamte Batchaufruf aufgrund eines Teilfehlers fehlgeschlagen ist.

MCP-Toolspezifikationen abrufen

Mit der Methode tools/list können Sie die MCP-Toolspezifikationen für alle Tools auf einem MCP-Server abrufen. Im folgenden Beispiel wird gezeigt, wie Sie mit curl alle Tools und ihre Spezifikationen auflisten, die derzeit auf dem MCP-Server verfügbar sind.

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