MCP Reference: mapstools.googleapis.com

Это сервер MCP, предоставляемый инструментами агентов Maps Experience. Сервер предоставляет разработчикам инструменты для создания приложений на основе LLM на платформе Google Карт.

Сервер Model Context Protocol (MCP) выступает в качестве прокси-сервера между внешним сервисом, который предоставляет контекст, данные или возможности большой языковой модели (LLM) или ИИ-приложению. MCP-серверы подключают ИИ-приложения к внешним системам, таким как базы данных и веб-сервисы, и преобразуют их ответы в формат, понятный ИИ-приложению.

Настройка сервера

Прежде чем использовать MCP-серверы, необходимо включить их и настроить аутентификацию. Подробнее об использовании удаленных MCP-серверов Google и Google Cloud…

Конечные точки сервера

Конечная точка сервиса MCP – это сетевой адрес и интерфейс связи (обычно URL) сервера MCP, который ИИ-приложение (хост для клиента MCP) использует для установления безопасного стандартизированного подключения. Это точка контакта, через которую LLM запрашивает контекст, вызывает инструмент или обращается к ресурсу.

У MCP-сервера инструментов агентов Maps Experience есть следующая глобальная конечная точка MCP:

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

Инструменты MCP

Инструмент MCP – это функция или исполняемый код, который MCP-сервер предоставляет LLM или ИИ-приложению для выполнения действия в реальном мире.

Инструменты

На MCP-сервере mapstools.googleapis.com есть следующие инструменты:

Инструменты 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'.
    • Чтобы получить информацию о местах, укажите нужный атрибут, например '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 км: {"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 (строка, необязательный параметр). Язык, на котором будет показана сводка результатов поиска.

    • Формат. Двухбуквенный код языка (ISO 639-1), за которым может следовать символ подчеркивания и двухбуквенный код страны (ISO 3166-1 alpha-2), например en, ja, en_US, zh_CN, es_MX. Если код языка не указан, результаты будут на английском.

  4. region_code (строка, необязательный). Код региона пользователя в формате Unicode CLDR. Этот параметр используется для отображения информации о местах, например названия места для определенного региона, если оно доступно. Этот параметр может влиять на результаты в соответствии с действующим законодательством.

    • Формат. Двухбуквенный код страны (ISO 3166-1 alpha-2), например US, CA.

  5. page_size (целое число, необязательно). Максимальное количество мест, которое нужно вернуть (от 1 до 10). Значение по умолчанию – 5. Устанавливайте значение выше 5, только если пользователю нужно сравнить более пяти мест. Значения от 6 до 10 приводят к увеличению стоимости и задержки.

  6. include_extended_details (логическое значение, НЕОБЯЗАТЕЛЬНО). Задайте для этого поля значение true, если запрос пользователя требует подробных качественных данных, динамики в реальном времени или специализированных атрибутов объектов. Значение по умолчанию – false. Если задать значение true, стоимость и задержка будут выше.

Инструкции по вызову инструмента

  • Геоданные (КРИТИЧЕСКИ ВАЖНО). Поисковый запрос должен содержать достаточно геоданных. Если местоположение неоднозначно (например, просто "пиццерии"), необходимо указать его в text_query (например, "пиццерии в Нью-Йорке") или использовать параметр location_bias. При необходимости укажите город, штат/провинцию и регион/страну.

  • Всегда указывайте максимально точные и подробные text_query.

  • Используйте location_bias, только если координаты указаны явно или если определение местоположения по известному контексту пользователя уместно и необходимо для получения лучших результатов.

  • Обоснованный ответ должен быть связан с источником с помощью информации из поля attribution, если она доступна.
lookup_weather Получает подробные данные об окружающей среде для местоположения, включая погоду, качество воздуха (ИКВ и загрязнители) и пыльцу (уровни аллергенов деревьев, трав, сорняков и видов растений): текущие условия, почасовые прогнозы/историю и ежедневные прогнозы погоды и качества воздуха; Пыльца – это только ежедневный прогноз (с сегодняшнего дня по +4 дня, без почасовых или прошлых данных). Доступные домены и возможности среды (capabilities: WEATHER, AIR_QUALITY, POLLEN – КРИТИЧЕСКИ ВАЖНО): * Обязательный явный выбор: вы ДОЛЖНЫ включить хотя бы один из параметров WEATHER, AIR_QUALITY или POLLEN в capabilities при каждом вызове. Пропускать capabilities НЕЛЬЗЯ. * Широкие или неоднозначные запросы о погоде на улице (полный набор данных). Если пользователь задает общий вопрос о погоде на улице, путешествиях или ситуации, не ограничиваясь определенной областью (например, "Какая сейчас погода на улице для пробежки?"), явно включите все три функции (capabilities: ["WEATHER", "AIR_QUALITY", "POLLEN"]), чтобы вернуть полный набор данных о погоде на улице (погода + качество воздуха + пыльца). Для прошлых date/hour исключите POLLEN, у которого нет истории. * Выбор целевого домена (конкретные запросы). Если пользователь запрашивает информацию только по одному или двум доменам (например, "Какой сейчас ИКВ в Сиэтле?"), включите только запрошенные функции (WEATHER, AIR_QUALITY и/или POLLEN). Будут выполнены и возвращены только запрошенные домены. Доступные данные по доменам: * Погода (weather): температура (текущая, ощущаемая, максимальная/минимальная, тепловой индекс), ветер (скорость, порывы, направление), астрономические события (восход/закат, фаза луны), осадки (тип, вероятность, количество/QPF) и атмосферные условия (УФ-индекс, влажность, облачность, вероятность грозы, атмосферное давление). * Качество воздуха (air_quality). Универсальный и местный индексы качества воздуха (значение, категория, доминирующий загрязнитель), рекомендации по охране здоровья для семи групп чувствительности и концентрация загрязнителей (include_pollutant_concentration: true). У каждого индекса свой доминирующий загрязнитель. Указывайте его для каждого индекса (например, не указывайте загрязнитель универсального индекса для индекса США). * Пыльца (pollen). Ежедневный универсальный индекс пыльцы (UPI, 0–5) по категориям деревьев, трав и сорняков и по видам растений (index.value с его index.category, например 1 = "Очень низкий"), статус сезона, перекрестные реакции и рекомендации по здоровью. * Отсутствующие поля пыльцы. Отсутствие in_season означает, что сезон не наступил. Не упоминай виды растений, для которых не указан index, если только пользователь не спросит о них. В этом случае скажи, что данных о пыльце этих растений на сегодня нет (не пытайся угадать уровень). Правила в отношении местоположения (ВАЖНО). Целевое местоположение ДОЛЖНО быть указано в location с использованием ТОЛЬКО ОДНОГО из следующих подполей oneof: 1. Географические координаты (lat_lng). Используйте, если известны точные координаты широты и долготы. * Пример: {"location": {"lat_lng": {"latitude": 34.0522, "longitude": -118.2437}}} 2. Идентификатор места (place_id): * Однозначный идентификатор места на Google Картах (например, полученный из search_places или resolve_names). * Пример: {"location": {"place_id": "ChIJLU7jZClu5kcR4PcOOO6p3I0"}} 3. Строка адреса (address). Город, регион, район, достопримечательность, почтовый адрес или почтовый индекс. Желательно также указать город и страну. * Пример: {"location": {"address": "Paris, France"}} Режимы времени и использования (date и hour – КРИТИЧЕСКИ ВАЖНО): * Ссылка на местный часовой пояс: все входные данные date ({year, month, day}) и hour (0-23) ДОЛЖНЫ быть выражены в местном гражданском часовом поясе запрашиваемого location (например, в запросе для "Paris tomorrow at 13:00" используется местная дата Europe/Paris и час 13), а не в UTC или часовом поясе вызывающего абонента. * 1. Текущие условия (date и hour не указаны): * Укажите location и целевую capabilities (WEATHER, AIR_QUALITY, POLLEN). НЕ указывайте date или hour. * Возвращает текущие условия в реальном времени (CC) для запрошенных доменов (текущая погода, качество воздуха за текущий час и/или прогноз пыльцы на сегодня). * Для качества воздуха текущие условия – это один час. НЕ используйте только их, чтобы ответить на вопросы о качестве воздуха или общих условиях на улице за сегодня в целом (используйте ежедневные запросы ниже). * 2. Почасовой прогноз/история (указаны date и hour 0-23): * Укажите location, date ({year, month, day}), hour (0-23) и целевой capabilities. Если указаны минуты, округлите значение до ближайшего часа в меньшую сторону. * КРИТИЧЕСКОЕ ОГРАНИЧЕНИЕ (если задано значение hour, то date ОБЯЗАТЕЛЬНО): указывать hour без date (date опущено, hour задано) НЕЛЬЗЯ. Это приведет к ошибке. Даже если пользователь спрашивает о конкретном часе сегодня (например, "at 13:00 today"), вы ДОЛЖНЫ заполнить и date (сегодняшняя дата в location), и hour. * Выполняет ежечасный поиск запрашиваемых данных о погоде и/или качестве воздуха в YYYY-MM-DD-HH и ежедневный поиск запрашиваемых данных о пыльце в YYYY-MM-DD. * Вопросы о погоде, содержащие слово "когда". Если в вопросе о погоде есть слова когда, в какое время, лучшее время (например, "what time will it stop raining?"), используйте почасовые вызовы WEATHER (date + hour) для соответствующих часов. В ежедневном прогнозе погоды нет почасовых значений. Для общих вопросов о погоде на улице, содержащих слова "когда" или "лучшее время" (например, "when is the best time to go walking today?"), в дополнение к вызову данных о качестве воздуха (и пыльце) за весь день, описанному в разделе "Ежедневные запросы", выполняйте почасовые вызовы WEATHER. * 3. Ежедневные запросы (указан параметр date, а параметр hour опущен): * Чтобы получить данные за весь день, укажите location, date ({year, month, day} по местному гражданскому времени в запрашиваемом location) без hour и целевой capabilities (например, "weather and pollen in London tomorrow"). * Запросы о качестве воздуха и общие вопросы о погоде на сегодня. Чтобы получить почасовые данные о качестве воздуха и общие сведения о погоде (включая качество воздуха) на сегодня (например, "how will the air quality change today", "is today a good day for a picnic?"), задайте для параметра date значение сегодняшняя дата в location (без указания часа). Вызова Current Conditions недостаточно, так как он возвращает только данные о качестве воздуха за текущий час. Вы можете добавить его, если пользователь также спрашивает о текущем моменте. * Временные интервалы для качества воздуха. Если запрос касается качества воздуха в определенный интервал времени в течение одного дня (например, "air quality between noon and 6 PM"), лучше сделать один вызов Daily для этой даты и прочитать часы интервала из серии Air Quality, а не запрашивать данные для отдельных часов. Если вы используете почасовые вызовы, охватите каждый час окна. * Возвращает ежедневные прогнозы для запрошенных данных о погоде и/или пыльце, а также почасовые данные о качестве воздуха за весь местный день (00:00–23:00 по местному времени): 24 часа истории для прошедшей даты, 24 часа прогноза для будущей даты, а для сегодняшнего дня – более ранние часы (история), текущий час и оставшиеся часы (прогноз). Поддерживаемые временные горизонты по доменам: * Погода. Почасовой прогноз за последние 24 часа и на следующие 240 часов (10 дней). Для прошедших часов требуются и date, и hour. Ежедневный прогноз на 10 дней, включая сегодняшний (сегодня и следующие 9 дней). Ежедневная история не поддерживается. * Качество воздуха. Почасовые данные за период от 720 часов (30 дней) назад до 96 часов (4 дней) вперед. Запрос за полный день должен укладываться в этот диапазон (на практике – от −29 до +3 дней). * Пыльца. Только ежедневные данные, с сегодняшнего дня по +4 дня (5 дней, включая сегодняшний). Прошедшие даты не поддерживаются, а параметр hour игнорируется. * Примечание. Если запрашивается несколько возможностей, а значение date/hour выходит за пределы одного из диапазонов, вызов все равно выполняется и возвращает только поддерживаемые возможности. * Запросы за пределами диапазона. Если запрашиваемая дата или час могут быть за пределами поддерживаемого диапазона домена, указанного выше (например, пыльца за прошедшую дату), все равно вызовите lookup_weather для запрашиваемой даты или часа. В ошибке будет указан поддерживаемый диапазон. Не заменяйте их другими датами, часами или доменами. Настройки домена и атрибуция: * Язык (language_code): необязательный код языка BCP-47 (например, "fr"). По умолчанию используется "en". * Единицы измерения погоды (weather_options.units_system или units_system). По умолчанию используется METRIC. Установите значение IMPERIAL (градусы Фаренгейта/мили в час), если пользователь подразумевает стандарты США или явно запрашивает имперские единицы измерения. Поддерживается как в weather_options.units_system (предпочтительно), так и в units_system верхнего уровня. Если указаны оба, они не должны конфликтовать. * Параметры качества воздуха (air_quality_options). Задайте include_pollutant_concentration: true, если вам нужны данные о концентрации определенных загрязнителей (PM2.5, PM10, O3, NO2, SO2, CO). При необходимости задайте index_region_code (двухбуквенный код страны по стандарту ISO, например "US"), чтобы запросить данные по определенной региональной шкале ИКВ. По умолчанию ответ включает универсальный ИКВ и региональный ИКВ для местоположения. * Атрибуция. Обоснованные выходные данные ДОЛЖНЫ быть соотнесены с источником с помощью поля attribution внутри каждого возвращенного контейнера домена (weather.attribution, air_quality.attribution, pollen.attribution). * Возвращенное время. Значения date_time качества воздуха уже указаны по местному времени (включая utc_offset). Представляйте их как есть. Значения date_time погоды (текущей и почасовой) и времени восхода/заката указаны по UTC. Преобразуйте их в местное время с помощью time_zone. Укажите, что время местное.
compute_routes

Рассчитывает маршруты между пунктами отправления и назначения, в том числе с промежуточными остановками. Возвращает расстояние и продолжительность для каждого маршрута.

Требования к входным данным (КРИТИЧЕСКИ ВАЖНО):

  1. origin и destination (объекты – ОБЯЗАТЕЛЬНО). Каждый из них должен быть указан с помощью одного из следующих элементов:

    • address (строка, например 'Eiffel Tower, Paris'). Названия мест, достопримечательностей и компаний разрешаются напрямую, поэтому НЕ вызывайте сначала search_places только для геокодирования путевой точки. Укажите город, регион или страну, упомянутые пользователем.
    • lat_lng (объект, {"latitude": number, "longitude": number}).
    • place_id (строка, например 'ChIJOwE_Id1w5EAR4Q27FkL6T_0'), например из search_places.

  2. intermediate_waypoints (массив объектов, необязательный). До 25 остановок, через которые нужно проехать по порядку между пунктами отправления и назначения. Формат такой же, как у origin. Не поддерживается в TRANSIT. Включайте только те остановки, которые запросил пользователь. Если указать более 10 промежуточных путевых точек, это приведет к увеличению стоимости и задержки.

  3. travel_mode (enum – НЕОБЯЗАТЕЛЬНО): DRIVE (по умолчанию), WALK, BICYCLE или TRANSIT.

  4. Время (НЕОБЯЗАТЕЛЬНО – укажите не более ОДНОГО значения). Временные метки RFC 3339 с разницей с UTC, например '2026-09-19T08:00:00-07:00'. По умолчанию используется текущее время. Для TRANSIT можно указать время в пределах семи дней в прошлом или 100 дней в будущем. Для других режимов время может быть установлено на любой момент в будущем в пределах 365 дней.

    • departure_time – используйте, когда пользователь говорит, когда он уедет (например, "завтра в 8 утра").
    • arrival_time – используйте, если пользователь указывает время прибытия (например, "быть там к 9:00").

  5. routing_preference (enum – НЕОБЯЗАТЕЛЬНО):

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (по умолчанию): не учитывает текущую загруженность дорог, происшествия и перекрытия. Наименьшая задержка.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL – используются данные о загруженности дорог в реальном времени (если доступны). Не поддерживается для WALK и BICYCLE. Устанавливайте этот параметр, ТОЛЬКО когда пользователь спрашивает о дорожном движении, пробках или расчетном времени прибытия с учетом пробок. Это приводит к более высоким затратам и задержкам.

  6. location_bias (объект, НЕОБЯЗАТЕЛЬНО). {"latitude": number, "longitude": number}, используемый для устранения неоднозначности названий мест в адресах путевых точек. Если название неоднозначно (например, "Спрингфилд"), а пользователь не указал регион, оставьте название в address как есть и установите location_bias на нужную область, а не угадывайте регион.

  7. compute_alternative_routes (логическое значение, НЕОБЯЗАТЕЛЬНО). Установите значение true, только если пользователь запрашивает варианты маршрута. По умолчанию используется значение false, при котором возвращается только рекомендуемый маршрут.

  8. include_polyline (логическое значение, необязательно). Установите значение true, только если требуется геометрия маршрута (encoded_polyline). Значение по умолчанию – false.

Инструкции по вызову инструмента

  • Если пункт отправления или назначения отсутствует, вы ДОЛЖНЫ попросить пользователя уточнить информацию, прежде чем вызывать инструмент.
  • Для вопросов типа "Как далеко А от Б?" используйте Б в качестве origin и А в качестве 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 пусто, сообщите пользователю, что маршрут не найден. Не пытайтесь угадать маршрут.
  • Чтобы найти места вдоль маршрута DRIVE, передайте retrieval_token маршрута в search_along_route. Токен действителен в течение 10 минут.
  • Указывай только факты, полученные от инструмента. НЕ придумывайте пошаговые маршруты, линии общественного транспорта, станции, платформы или пересадки.
  • Обоснованные выходные данные должны быть соотнесены с источником с помощью поля attribution каждого маршрута, если оно доступно.
search_along_route

Вызывайте этот инструмент, когда пользователь хочет найти места, компании или достопримечательности вдоль маршрута (например, "заправки по пути в Тахо", "кофейни между Сан-Франциско и Сан-Хосе"). Вызов этого инструмента стоит дороже, чем search_places, поэтому используйте search_places, когда ищете места рядом с одним местоположением, а не вдоль маршрута.

Требования к входным данным (КРИТИЧЕСКИ ВАЖНО):

  1. text_query (строка, ОБЯЗАТЕЛЬНО). Описание того, что нужно искать вдоль маршрута, на естественном языке.

    • Примеры: 'ev chargers', 'coffee', 'vegetarian restaurants', 'rest stops'.

  2. Спецификация маршрута (ОБЯЗАТЕЛЬНО – укажите только ОДИН из следующих вариантов):

    • retrieval_token (строка). Значение retrieval_token, возвращенное предыдущим вызовом compute_routes для маршрута DRIVE. Используйте этот вариант, если маршрут уже рассчитан. Токен действителен в течение 10 минут.
    • route_endpoints (объект). origin и destination маршрута. Каждое значение должно быть указано с помощью одного из следующих свойств: address, lat_lng или place_id.
      • Пример: {"route_endpoints": {"origin": {"address": "San Francisco, CA"}, "destination": {"address": "Lake Tahoe, CA"}}}.
    • encoded_polyline (строка) – закодированная ломаная линия, представляющая маршрут DRIVE.

  3. travel_mode (enum – НЕОБЯЗАТЕЛЬНО): DRIVE (по умолчанию), WALK или BICYCLE. WALK и BICYCLE поддерживаются только с route_endpoints. TRANSIT не поддерживается.

  4. routing_preference (enum – НЕОБЯЗАТЕЛЬНО):

    • ROUTING_PREFERENCE_TRAFFIC_UNAWARE (по умолчанию) – маршрут и объезды рассчитываются без учета текущей загруженности дорог. Наименьшая задержка.
    • ROUTING_PREFERENCE_TRAFFIC_AWARE_OPTIMAL – используются данные о загруженности дорог в реальном времени (если доступны). Не поддерживается для WALK и BICYCLE. Устанавливайте этот параметр, ТОЛЬКО когда пользователь спрашивает о пробках, заторах или времени объезда с учетом пробок. Увеличивается задержка.

  5. include_extended_details (логическое значение, необязательно). Установите значение true, только если в запросе требуются качественные отзывы, конкретные пункты меню или предложения, атмосфера, советы посетителей или загруженность, наличие устройства для зарядки ЭМ, цены на бензин или другие подробные качественные данные. Значение по умолчанию – false. Если включить эту функцию, задержка может увеличиться.

  6. language_code (строка, необязательно). Язык, на котором будет представлена сводка результатов и информация о местах, например en, ja, en-US. Значение по умолчанию – en-US.

  7. region_code (строка, необязательно). Код региона пользователя в формате Unicode CLDR, например US, CA.

Инструкции по вызову инструмента

  • Каждый результат включает объект detour_summary (если доступен), описывающий дополнительное расстояние (localized_detour_distance) и, если маршрут не был задан как encoded_polyline, дополнительное время (detour_duration), необходимое для остановки в этом месте. Используйте его, чтобы сравнивать варианты.
  • Ответ summary может содержать цитаты, начинающиеся с нуля (например, "[0]"), которые ссылаются на записи в results.
  • Обоснованные выходные данные должны быть соотнесены с источником с помощью поля attribution каждого results[].place, если оно доступно.
resolve_names

Преобразует пакетный список запросов о местоположении (названия достопримечательностей или точные адреса) в канонические идентификаторы мест Google Карт.

Требования к входным данным (КРИТИЧЕСКИ ВАЖНО):

  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 (строка, необязательный). Код региона CLDR Unicode (двухбуквенный код страны, например US, CA) пользователя, для которого нужно уточнить результаты.

Инструкции по вызову инструмента

  • Точность (КРИТИЧЕСКИ ВАЖНО). Запросы должны содержать точное название места или адрес. Общие поисковые запросы, например 'restaurants', или названия сетей, например 'Starbucks', не поддерживаются.
  • НЕ вызывайте этот инструмент, если последующие инструменты, которые вы планируете использовать, уже принимают необработанные строки адреса или названия места напрямую.

Сохранить в Google Картах

  • Ответ содержит поле save_to_maps_url – одну ссылку на Google Карты, содержащую все успешно распознанные места.
  • Когда пользователь захочет сохранить, поделиться или открыть сопоставленные места в виде списка в Google Картах, покажите ему эту ссылку. Не создавайте эту ссылку самостоятельно.

Обработка ошибок (КРИТИЧЕСКИЙ ПРИОРИТЕТ)

  • Это инструмент пакетной обработки. Запрос может возвращать смешанные результаты (например, некоторые запросы выполняются успешно, а другие – нет).
  • Выходной список results гарантированно сопоставляется 1:1 с входными индексами queries. Если запрос не удался, то в списке results будет возвращено пустое сообщение Result (без entity) с соответствующим индексом.
  • Вы ОБЯЗАТЕЛЬНО должны проверить поле карты failed_requests в ответе, чтобы определить, какой именно индекс запроса не удалось выполнить. Ключ failed_requests представляет собой индекс неудачного запроса, начинающийся с нуля. Не считайте, что весь пакетный вызов завершился ошибкой, если она произошла только в некоторых случаях.
resolve_maps_urls

Преобразует список URL Google Карт в канонические идентификаторы мест Google Карт.

Когда вызывать этот инструмент (ВАЖНО):

  • Используйте этот инструмент, когда пользователь предоставляет одну или несколько ссылок или URL-адресов Google Карт (например, https://maps.app.goo.gl/...). https://www.google.com/maps/place/... или https://maps.google.com/..., и вам нужно извлечь канонические идентификаторы мест.
  • В одном пакетном запросе можно указать до 20 URL.

Требования к входным данным (КРИТИЧЕСКИ ВАЖНО):

  • urls (массив строк, ОБЯЗАТЕЛЬНО). Список URL Google Карт, которые нужно преобразовать. Каждый URL должен быть действительным и указывать на одно место в Google Картах.

Сохранить в Google Картах

  • Ответ содержит поле save_to_maps_url – одну ссылку на Google Карты, содержащую все успешно распознанные места.
  • Если пользователь хочет сохранить, открыть или поделиться списком найденных мест в Google Картах (например, собрать места, упомянутые в разговоре), покажите ему эту ссылку. Не создавайте эту ссылку самостоятельно.

Обработка ошибок (КРИТИЧЕСКИЙ ПРИОРИТЕТ)

  • Это инструмент пакетной обработки. Запрос может возвращать смешанные результаты (например, некоторые URL разрешаются успешно, а другие – нет).
  • Выходной список entities гарантированно сопоставляется 1:1 с входными индексами urls. Если URL не удалось обработать, то в списке entities появится пустое сообщение Entity (без полей).
  • Вы ДОЛЖНЫ проверить поле карты failed_requests в ответе, чтобы определить, какой именно URL не удалось проиндексировать. Ключ failed_requests представляет собой индекс URL, который не удалось обработать, в запросе (начиная с нуля). Не считайте, что весь пакетный вызов завершился ошибкой, если она произошла только в некоторых случаях.

Получить спецификации инструмента 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
}'