MCP Reference: mapstools.googleapis.com

これは、Maps Experience Agent Tools が提供する MCP サーバーです。このサーバーは、デベロッパーが Google Maps Platform 上に LLM アプリケーションを構築するためのツールを提供します。

Model Context Protocol（MCP）サーバーは、大規模言語モデル（LLM）または AI アプリケーションにコンテキスト、データ、機能を提供する外部サービスとの間のプロキシとして機能します。MCP サーバーは、AI アプリケーションをデータベースやウェブサービスなどの外部システムに接続し、そのレスポンスを AI アプリケーションが理解できる形式に変換します。

サーバーの設定

使用する前に、MCP サーバーを有効にして認証を設定する必要があります。Google と Google Cloud のリモート MCP サーバーの使用方法については、Google Cloud MCP サーバーの概要をご覧ください。

サーバー エンドポイント

MCP サービス エンドポイントは、安全で標準化された接続を確立するために AI アプリケーション（MCP クライアントのホスト）が使用する MCP サーバーのネットワーク アドレスと通信インターフェース（通常は URL）です。これは、LLM がコンテキストをリクエストしたり、ツールを呼び出したり、リソースにアクセスしたりするための接続ポイントとなります。Google MCP エンドポイントをグローバルまたはリージョンにすることができます。

Maps Experience Agent Tools MCP サーバーには、次のグローバル MCP エンドポイントがあります。

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

MCP ツール

MCP ツールは、現実世界でアクションを実行する目的で MCP サーバーが LLM または AI アプリケーションに対して公開する関数または実行可能な機能です。

ツール

mapstools.googleapis.com MCP サーバーには、次のツールがあります。

MCP ツール
search_places

ユーザーのリクエストが、場所、ビジネス、住所、位置、スポット、またはその他の Google マップ関連の検索である場合に、このツールを呼び出します。

入力要件（重要）:

  1. text_query（文字列 - 必須）: プライマリ検索クエリ。ユーザーが探しているものを明確に定義する必要があります。

    • 例: 'restaurants in New York'、'coffee shops near Golden Gate Park'、'SF MoMA'、'1600 Amphitheatre Pkwy, Mountain View, CA, USA'、'pets friendly parks in Manhattan, New York'、'date night restaurants in Chicago'、'accessible public libraries in Los Angeles'
    • Place Details の場合: リクエストする属性（'Google Store Mountain View opening hours'、'SF MoMa phone number'、'Shoreline Park Mountain View address' など）を含めます。

  2. location_bias（オブジェクト - 省略可）: 特定の地理的エリアに近い結果を優先する場合に使用します。

    • 形式: {"location_bias": {"circle": {"center": {"latitude": [value], "longitude": [value]}, "radius_meters": [value (optional)]}}}
    • 使用方法:
      • 半径 5 km にバイアスをかけるには: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}, "radius_meters": 5000}}}
      • 中心点に強くバイアスをかける場合: {"location_bias": {"circle": {"center": {"latitude": 34.052235, "longitude": -118.243683}}}}（radius_meters は省略）。

  3. language_code（文字列 - 省略可）: 検索結果の概要を表示する言語。

    • 形式: 2 文字の言語コード（ISO 639-1）。必要に応じて、アンダースコアと 2 文字の国コード（ISO 3166-1 alpha-2）を続けます（例: en、ja、en_US、zh_CN、es_MX）。言語コードが指定されていない場合、結果は英語で表示されます。

  4. region_code（文字列 - 省略可）: ユーザーの Unicode CLDR 地域コード。このパラメータは、地域固有の場所名など、Place Details を表示するために使用されます（利用可能な場合）。このパラメータは、適用される法律に基づいて結果に影響を与える可能性があります。

    • 形式: 2 文字の国コード（ISO 3166-1 alpha-2）（例: US、CA）。

ツール呼び出しの手順:

  • 位置情報（重要）: 検索には十分な位置情報が含まれている必要があります。場所があいまいな場合（例: 「ピザ屋」のみ）、text_query で指定する必要があります（例: 「ニューヨークのピザ屋」）。または、location_bias パラメータを使用します。曖昧性除去のために必要な場合は、市区町村、都道府県、リージョン / 国名を含めます。

  • 常に、可能な限り具体的でコンテキストに即した text_query を提供します。

  • location_bias は、座標が明示的に指定されている場合、またはユーザーの既知のコンテキストから場所を推測することが適切であり、かつより良い結果を得るために必要な場合にのみ使用してください。

  • グラウンディングされた出力は、attribution フィールドの情報（利用可能な場合）を使用してソースに帰属させる必要があります。
lookup_weather

現在の天気、1 時間ごと、1 日ごとの予報など、包括的な天気データを取得します。

利用可能な特定のデータ: 気温（現在、体感温度、最高 / 最低、熱指数）、風（速度、突風、方向）、天体イベント（日の出 / 日の入り、月相）、降水量（種類、確率、量 / QPF）、大気条件（UV 指数、湿度、雲量、雷雨の確率）、ジオコーディングされた位置情報。

地域と地域に関するルール（重要）:

気象データをリクエストする場所は、location フィールドを使用して指定します。このフィールドは「oneof」構造です。つまり、正確な気象データを検索するには、以下の 3 つの場所サブフィールドのうち 1 つだけに値を指定する必要があります。

  1. 地理座標（lat_lng）

    • 正確な緯度 / 経度座標が提供されている場合に使用します。
    • 例: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} // ロサンゼルス

  2. プレイス ID（place_id）

    • 明確な文字列識別子（Google マップのプレイス ID）。
    • place_id は search_places ツールから取得できます。
    • 例: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} // エッフェル塔

  3. 住所文字列（address）

    • ジオコーディングの特異性を必要とする自由形式の文字列。
    • 都市と地域: 地域 / 国を必ず含めます（例: 「ロンドン」ではなく「ロンドン、英国」）。
    • 番地: 完全な住所を入力します（例: 「1600 Pennsylvania Ave NW, Washington, DC」）。
    • 郵便番号: 国名を含める必要があります（例: 「90210」ではなく「90210, USA」）。
    • 例: {"location": {"address": "1600 Pennsylvania Ave NW, Washington, DC"}}

使用モード:

  • 現在の天気: location のみを提供します。date と hour は指定しないでください。

  • 1 時間ごとの予測: location、date、hour（0 ～ 23）を指定します。特定の時間（「午後 5 時」など）や、「数時間後」、「今日中」などの表現に使用します。お客様が分単位で指定した場合は、時間単位で切り捨てます。現在から 120 時間を超える 1 時間ごとの予報はサポートされていません。過去 24 時間までの時間単位の気象履歴がサポートされています。

  • 日次予測: location と date を指定します。hour は指定しないでください。一般的な日付のリクエスト（「明日の天気」、「金曜日の天気」、「12 月 25 日の天気」など）に使用します。今日の日付がコンテキストにない場合は、ユーザーに確認する必要があります。今日を含む 10 日を超える日次予測はサポートされていません。過去の天気はサポートされていません。

パラメータの制約:

  • タイムゾーン: date と hour の入力はすべて、ユーザーのタイムゾーンではなく、所在地の現地タイムゾーンを基準にする必要があります。
  • 日付形式: 入力は {year, month, day} 個の整数に分割する必要があります。
  • 単位: デフォルトは METRIC です。ユーザーが米国規格を暗示している場合や、明示的にリクエストしている場合は、units_system を IMPERIAL（華氏 / マイル）に設定します。

  • グラウンディングされた出力は、attribution フィールドの情報（利用可能な場合）を使用してソースに帰属させる必要があります。
compute_routes

出発地と目的地の間の移動ルートを計算します。必要に応じて、中間地点を経由することもできます。各ルートの距離と所要時間を返します。

入力要件（重要）:

  1. origin と destination（オブジェクト - 必須）: それぞれ、次のいずれか 1 つのみを使用して指定する必要があります。

    • address（文字列、例: 'Eiffel Tower, Paris'）。名前付きの場所、ランドマーク、ビジネスは直接解決されるため、ウェイポイントをジオコーディングするためだけに search_places を呼び出さないでください。お客様が言及した都市、地域、国を含めます。
    • lat_lng（オブジェクト、{"latitude": number, "longitude": number}）。
    • place_id（文字列、例: 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'）（search_places など）。

  2. intermediate_waypoints（オブジェクトの配列 - 省略可）: 出発地と目的地の間に設定する、最大 10 か所の経由地（順番に並べる）。origin と同じ形式。TRANSIT ではサポートされていません。ユーザーがリクエストした停車地のみを含めます。

  3. travel_mode（列挙型 - 省略可）: DRIVE（デフォルト）、WALK、BICYCLE、TRANSIT。

  4. タイミング（省略可 - 最大 1 つ設定）: UTC オフセットを含む RFC 3339 タイムスタンプ（例: '2026-09-19T08:00:00-07:00'）。デフォルトは「今すぐ出発」です。TRANSIT の場合、時間は過去 7 日以内、または将来 100 日以内です。他のモードの場合、時刻は最大 365 日先まで指定できます。過去の時刻は指定できません。

    • departure_time: ユーザーが出発時刻を指定した場合（例: 「明日の午前 8 時」）に使用します。
    • arrival_time: ユーザーが到着時刻を指定する場合（例: 「午前 9 時までに到着」）に使用します。

  5. routing_preference（列挙型 - 省略可）:

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE（デフォルト）: リアルタイムの交通状況、事故、通行止めを無視します。レイテンシが最も低い。
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL: リアルタイムの交通状況を使用します（利用可能な場合）。WALK または BICYCLE ではサポートされていません。この設定は、お客様から交通状況、渋滞、交通状況を考慮した到着予定時刻について問い合わせを受けた場合にのみ行ってください。コストとレイテンシが増加します。

  6. location_bias（オブジェクト - 省略可）: ウェイポイントの住所で場所の名前の曖昧さを解消するために使用される {"latitude": number, "longitude": number}。名前があいまい（例: 「Springfield」）で、ユーザーが地域を指定していない場合は、address で指定された名前をそのまま使用し、地域を推測するのではなく、目的の地域に location_bias を設定します。

  7. compute_alternative_routes（ブール値 - 省略可）: ユーザーがルート オプションまたは代替ルートをリクエストした場合にのみ true に設定します。デフォルトは false で、おすすめのルートのみが返されます。

  8. include_polyline（ブール値 - 省略可）: ルート ジオメトリ（encoded_polyline）が必要な場合にのみ true に設定します。デフォルトは false です。

ツール呼び出しの手順:

  • 出発地または目的地が不明な場合は、ツールを呼び出す前にユーザーに確認する必要があります。
  • 「A から B までの距離は？」という質問の場合は、B を origin、A を destination として使用します。

ツール呼び出しの例: {"origin":{"address":"Eiffel Tower"},"destination":{"place_id":"ChIJt_5xIthw5EARoJ71mGq7t74"},"intermediate_waypoints":[{"address":"Louvre Museum"}],"travel_mode":"DRIVE","departure_time":"2026-09-19T08:00:00+02:00"}

回答の手順:

  • 代替ルートがリクエストされた場合、ルートはおすすめ度の高い順に並べ替えられます。
  • routes が空の場合は、ルートが見つからなかったことをユーザーに伝えます。ルートを推測しないでください。
  • ツールから返された事実のみを述べてください。ターンバイターン方式の経路、交通機関の路線、駅、プラットフォーム、乗り換えを創作しないでください。
  • グラウンディングされた出力は、各ルートの attribution フィールド（使用可能な場合）を使用してソースに帰属させる必要があります。
resolve_names

特定の場所のクエリ（ランドマーク名や正確な住所）のバッチリストを、正規の Google マップ プレイス ID に解決します。

入力要件（重要）:

  1. queries（オブジェクトの配列 - 必須）: 解決する場所クエリのリスト。最大 20 個のクエリを指定できます。

    • 各クエリ オブジェクトには、次のものが必要です。
      • text（文字列 - 必須）: 解決する特定の場所の名前または住所を表すテキストクエリ。
        • 例: 'Googleplex, Mountain View, CA'、'1600 Amphitheatre Pkwy, Mountain View, CA'、'Eiffel Tower, Paris'

  2. location_bias（オブジェクト - 省略可）: 特定の地理的エリアに近い結果を優先する場合に使用します。

    • 形式: {"viewport": {"low": {"latitude": [value], "longitude": [value]}, "high": {"latitude": [value], "longitude": [value]}}}

  3. region_code（文字列 - 省略可）: 結果をバイアスするユーザーの Unicode CLDR リージョン コード（2 文字の国コード、例: US、CA）。

ツール呼び出しの手順:

  • 具体性（重要）: 検索語句は、特定の場所の名前または住所を表している必要があります。'restaurants' のような一般的な検索や、'Starbucks' のようなチェーン名はサポートされていません。
  • 呼び出す予定の下流ツールが、未加工の住所または場所名の文字列を直接受け入れる場合は、このツールを呼び出さないでください。

Google マップに保存する:

  • レスポンスには save_to_maps_url フィールドが含まれます。これは、正常に解決されたすべての場所を含む単一の Google マップのリンクです。
  • ユーザーが解決済みの場所をリストとして Google マップに保存、共有、または開く場合は、このリンクをユーザーに提示します。このリンクは自分で作成しないでください。

エラー処理（重大）:

  • これはバッチ処理ツールです。リクエストが「混合結果」を返すことがあります（例: 一部のクエリは正常に解決されるが、他のクエリは失敗する）。
  • results の出力リストは、入力 queries インデックスと 1 対 1 でマッピングされることが保証されます。クエリが失敗すると、results リストの対応するインデックスに空の Result メッセージ（entity が設定されていない）が返されます。
  • レスポンスの failed_requests マップ フィールドをチェックして、失敗したクエリ インデックスを特定する必要があります。failed_requests のキーは、リクエストで失敗したクエリの 0 ベースのインデックスを表します。部分的な失敗が原因でバッチ呼び出し全体が失敗したと想定しないでください。
resolve_maps_urls

Google マップの URL のリストを正規の Google マップ プレイス ID に解決します。

このツールを呼び出すタイミング（重要）:

  • このツールは、ユーザーが 1 つ以上の Google マップ共有リンクまたは URL（例: 「https://maps.app.goo.gl/...」）を提供した場合に使用します。（「https://www.google.com/maps/place/...」や「https://maps.google.com/...」など）があり、基盤となる正規のプレイス ID を抽出する必要がある場合。
  • 1 つのバッチ リクエストで解決する URL を最大 20 個指定できます。

入力要件（重要）:

  • urls（文字列の配列 - 必須）: 解決する Google マップの URL のリスト。各 URL は、有効な単一の場所の Google マップ URL である必要があります。

Google マップに保存する:

  • レスポンスには save_to_maps_url フィールドが含まれます。これは、正常に解決されたすべての場所を含む単一の Google マップのリンクです。
  • ユーザーが解決済みの場所を Google マップのリストとして保存、共有、または開きたい場合（会話で共有された場所を収集する場合など）、このリンクをユーザーに提示します。このリンクは自分で作成しないでください。

エラー処理（重大）:

  • これはバッチ処理ツールです。リクエストが「混合結果」を返すことがあります（例: 一部の URL は正常に解決されるが、他の URL は失敗する）。
  • entities の出力リストは、入力 urls インデックスと 1 対 1 でマッピングされることが保証されます。URL の解決に失敗すると、entities リストの対応するインデックスに空の Entity メッセージ（フィールドが設定されていない）が返されます。
  • レスポンスの failed_requests マップ フィールドを必ず確認して、失敗した URL インデックスを特定してください。failed_requests のキーは、リクエスト内の失敗した URL の 0 ベースのインデックスを表します。部分的な失敗が原因でバッチ呼び出し全体が失敗したと想定しないでください。

MCP ツールの仕様を取得する

MCP サーバー内のすべてのツールの MCP ツール仕様を取得するには、tools/list メソッドを使用します。次の例は、curl を使用して、MCP サーバー内で現在使用可能なすべてのツールとその仕様を一覧表示する方法を示しています。

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