Как развернуть Google Antigravity MCP? Настройка прав облачного Mac и приёмка в 2026 году

Сначала — временная шкала и действие на эту неделю

В официальной документации Google для Antigravity Agent отдельно описываются удалённые MCP-подключения и управление MCP Server; для первой проверки достаточно одного сервера и одного инструмента только для чтения — именно такой минимальный контур следует собрать до добавления команд, файловых операций и внешней записи (документация Google Antigravity Agent). Вывод практический: Google Antigravity MCP следует сначала разворачивать в изолированной среде на облачном Mac, с точным URL, минимальным allowed_tools и подтверждением каждого чувствительного действия; глобальные разрешения MCP для production-задач включать не следует.

План работ выглядит так:

До запуска — изолировать проект, проверить сеть, секреты и рабочую директорию.
При первом подключении — зарегистрировать удалённый MCP Server и проверить протокол.
При первом вызове — выполнить чтение и сверить фактический ответ инструмента.
Перед расширением — разделить права read_file, command и mcp.
Перед командной эксплуатацией — закрепить версии конфигурации, журналирование, отзыв ключей и процедуру восстановления.

Материал рассчитан на разработчиков, которые переносят Antigravity с локального компьютера на облачный Mac, а также на инженеров автоматизации и руководителей, которым нужно унифицировать MCP, ключи и подтверждение действий. Тем, кому нужен только локальный эксперимент без удалённых инструментов, большая часть процедур ниже не потребуется.

До запуска: зафиксируйте границы облачного Mac

Google Antigravity, Gemini API Agent и MCP выполняют разные роли. Antigravity предоставляет агентный рабочий контур и управление подключёнными серверами; Gemini API Agent отвечает за взаимодействие модели с агентом; MCP Server публикует инструменты, которые агент может обнаружить и вызвать. Поэтому MCP не является «безопасным расширением модели» сам по себе: подключённый сервер может читать данные, выполнять действие через API или инициировать запись, если такая возможность предоставлена его инструментом и разрешениями.

В официальном описании MCP важно различать локальный сервер и удалённый сервер с потоковым HTTP-подключением. Локальный вариант обычно запускается рядом с клиентом и требует контроля процесса, окружения и стандартного ввода-вывода. Streamable HTTP MCP обращается к удалённому URL, поэтому дополнительно зависят DNS, TLS, маршрут исходящего трафика, заголовки авторизации и политика сетевого выхода. Поля подключения и общие принципы регистрации следует сверять с руководством Google по конфигурации MCP, а не переносить пример из случайного репозитория.

Перед созданием среды полезно пройти предварительную проверку:

[ ] Создан отдельный проект или рабочая директория без production-секретов.
[ ] Понятно, какие файлы агенту разрешено читать и изменять.
[ ] Облачный Mac имеет исходящий доступ к конкретному MCP URL, но не получает лишние входящие порты.
[ ] Переменные окружения отделены от конфигурационного файла и не попадают в Git.
[ ] Для теста подготовлен отдельный ключ с ограниченным сроком действия.
[ ] Определено, кто подтверждает действия с командами, исходным кодом и внешними системами.
[ ] Зафиксирован способ остановить MCP Server и отозвать его ключ.
[ ] Есть журнал, где можно различить запрос агента, ответ сервера и локальную ошибку среды.

Не следует начинать с задачи, которая одновременно читает весь проект, запускает shell-команды, изменяет файлы и отправляет результат во внешнюю систему. Такой тест не показывает, где возник отказ, а при ошибке оставляет слишком широкую область для расследования. Для первого прохода подходят чтение тестового ресурса, получение структуры данных и проверка схемы ответа.

Отдельное внимание требуется рабочему каталогу. Даже если MCP Server ограничивает свои методы, локальная конфигурация Antigravity может предоставлять агенту доступ к дополнительным файлам или командам. Секреты, ключи доступа, файлы с персональными данными и production-конфигурации не должны находиться в каталоге, который используется для первоначальной приёмки.

Первый этап: зарегистрируйте удалённый MCP Server

Добавление MCP Server начинается не с полной библиотеки инструментов, а с описания одного удалённого подключения. В конфигурации нужно логически разделить как минимум четыре элемента: имя сервера, URL, заголовки запроса и список разрешённых инструментов. Точное написание полей и поддерживаемые варианты необходимо сверять с актуальной документацией Antigravity, потому что поведение конкретной версии может измениться.

Имя должно быть однозначным и пригодным для журналов: например, docs-readonly-test, а не server1. В имени не стоит указывать секреты, регион или внутренний адрес. URL должен быть полным адресом удалённой конечной точки, а не ссылкой на страницу документации или административную панель. Заголовок авторизации передаётся через защищённую переменную окружения либо секретное хранилище, если это поддерживается используемым способом запуска.

Концептуально минимальная запись выглядит следующим образом:

{
  "name": "docs-readonly-test",
  "url": "${MCP_READONLY_URL}",
  "headers": {
    "Authorization": "Bearer ${MCP_READONLY_TOKEN}"
  },
  "allowed_tools": [
    "read_document"
  ]
}

Это образец структуры, а не гарантия буквального имени всех полей для каждой версии. Перед применением следует сопоставить его с официальным руководством Google Antigravity по MCP. Главное решение здесь — не формат JSON, а ограничение начального контура одним сервером и одним чтением.

После сохранения конфигурации выполните проверку в таком порядке:

Убедитесь, что переменная с URL действительно присутствует в процессе Antigravity, а не только в интерактивной оболочке.
Проверьте DNS и TLS из той же среды, где будет работать агент.
Сверьте название заголовка авторизации и способ передачи токена.
Проверьте, что MCP Server возвращает ответ ожидаемого протокола, а не HTML-страницу ошибки.
Убедитесь, что имя read_document совпадает с фактически опубликованным инструментом.
Выполните один запрос без записи, shell-команды и доступа к локальному проекту.

Если соединение не устанавливается, не меняйте сразу несколько параметров. Сначала замените URL на проверенный тестовый адрес, затем отдельно проверьте заголовок, после этого — объявление инструмента. Одновременная правка сети, ключа и белого списка стирает причинно-следственную связь.

Для streamable HTTP особенно важны маршрут и политика выхода. Локальный Mac может успешно обращаться к серверу через корпоративную сеть, а облачный Mac — нет; обратная ситуация также возможна из-за фильтрации, прокси или различий в DNS. Поэтому доступность нужно проверять именно из удалённой среды, а не с рабочего ноутбука администратора.

Второй этап: разделите разрешения по поверхности риска

В Antigravity нельзя рассматривать «доступ агента» как одно переключатель. Для приёмки следует отдельно анализировать:

read_file — чтение файлов и каталогов;
command — запуск команд, скриптов и процессов;
mcp — обращение к опубликованным инструментам MCP.

Модель разрешений должна быть составлена так, чтобы предоставление одного типа доступа не означало автоматическое предоставление остальных. Например, инструмент, который читает документацию через удалённый MCP Server, не должен из-за этого получать право запускать локальные команды. Аналогично, возможность выполнить тестовую команду не должна открывать весь MCP-каталог.

Наиболее опасны глобальные шаблоны и широкие маски. Разрешение наподобие «все MCP-серверы» скрывает появление нового сервера за уже существующим правилом. Маска «любая команда» делает невозможным содержательный аудит. Разрешение «весь домашний каталог» увеличивает последствия утечки токена или ошибочного решения модели. Вначале предпочтительны точные пары: конкретный сервер — конкретный инструмент; конкретный каталог — конкретное действие; конкретная команда — конкретный аргумент.

Ориентировочная матрица для трёх режимов:

Разработка. Допустим один тестовый MCP Server и несколько безопасных операций чтения. Изменение локальных файлов разрешается только внутри рабочего каталога. Команды запускаются без доступа к секретам.
Тестирование. Сохраняется тот же MCP-белый список, но добавляется ограниченная запись в отдельную тестовую директорию. Сетевые действия и миграции требуют ручного подтверждения.
Production. Доступ выдаётся конкретному серверу и конкретному инструменту, ключи имеют минимально необходимую область действия, а действия с внешней записью, платежами, исходным кодом и секретами не выполняются автоматически.

Документация Google Cloud по контролю доступа MCP полезна для проверки того, как разграничивать доступ к MCP-ресурсам. Если удалённый сервер использует облачные роли, необходимо также сверить фактическую роль с описанием разрешений MCP в Google Cloud IAM. Наличие сетевого соединения не означает, что операция авторизована, а успешная авторизация не означает, что операция безопасна для production.

Третий этап: примите среду по простому сценарию

Первый полноценный тест должен быть не сложным агентным заданием, а последовательностью коротких проверок. Такой порядок позволяет отделить ошибку рассуждения модели от отказа MCP Server и проблемы облачного Mac.

Проверка чтения. Запросите один заранее известный тестовый ресурс. Зафиксируйте имя инструмента, параметры и полный структурированный ответ без секретных значений.
Проверка структуры. Попросите извлечь несколько заранее определённых полей из ответа. Здесь оценивается не скорость, а соответствие схемы, обработка отсутствующего поля и отсутствие скрытой записи.
Проверка отказа. Отправьте запрос к инструменту, которого нет в allowed_tools, либо к ресурсу, к которому нет доступа. Ожидаемый результат — контролируемый отказ, а не выполнение действия.
Контролируемая запись. Разрешите только тестовую запись в заранее созданный каталог или ресурс. Установите ручное подтверждение и проверьте, что без подтверждения действие не продолжается.
Восстановление. Остановите или перезапустите сессию, затем проверьте, не расширились ли права и можно ли восстановить журнал без повторной выдачи долгоживущего ключа.

В журнале должны быть видны как минимум событие подключения, выбранный инструмент, результат, ошибка, повторная попытка и финальный статус. Секреты и полные токены в журнал не записываются. Если платформа поддерживает hooks, их назначение и ограничения следует изучить по официальной документации Agent Hooks, не предполагая, что hook автоматически является механизмом изоляции.

Ошибки полезно распределять по трём категориям:

Ошибка модели или агента: неверно выбрано имя инструмента, неправильно сформированы параметры, результат неверно интерпретирован.
Ошибка MCP Server: сервер недоступен, вернул ошибку протокола, не объявил ожидаемый инструмент или отклонил авторизацию.
Ошибка удалённой среды: отсутствуют переменная окружения, сетевой маршрут, права процесса, рабочий каталог или свободное место.

Такое разделение особенно важно при повторных попытках. Повторять запрос к недоступному серверу бессмысленно, а автоматически повторять потенциально записывающую операцию рискованно. Для write-операций должна существовать отдельная политика повторов с ручной проверкой идемпотентности.

Четвёртый этап: закрепите обслуживание перед командным запуском

После успешной приёмки конфигурация ещё не готова к командной эксплуатации. Необходимо описать жизненный цикл ключей, серверов и рабочих сред.

Ключи следует периодически ротировать, а при подозрении на утечку — немедленно отзывать, удалять из окружения и проверять журналы использования. В конфигурации не должны храниться токены в открытом виде. Добавление нового MCP Server должно проходить ревью: кто владелец, какие инструменты опубликованы, какие данные покидают облачный Mac, какие операции являются записывающими и как сервер отключается.

Для удалённой разработки технический руководитель также проверяет:

объём и заполнение диска;
наличие зависших процессов MCP;
число параллельных сессий;
сохранение журналов после перезапуска;
корректное завершение неактивной среды;
восстановление проекта после сетевого сбоя;
отсутствие секретов в диагностических архивах.

Облачный Mac подходит для индивидуального теста, временного рабочего места и контролируемой разработки, когда требуется macOS-окружение и понятная изоляция проекта. Переход к централизованной Agent-платформе оправдан, когда нужно единообразно управлять множеством пользователей, журналами, ротацией ключей, политиками согласования и жизненным циклом MCP-серверов. Не следует масштабировать неустойчивую конфигурацию только потому, что один ручной вызов завершился успешно.

Перед расширением можно использовать руководство Vuncloud по аренде Mac для удалённой работы, а для выбора среды — обзор доступных вариантов аренды Mac. Эти страницы полезны именно на этапе сравнения рабочего места и требований к постоянной удалённой сессии; они не заменяют аудит MCP-разрешений.

Сводка вариантов перед расширением доступа

Вариант	Что разрешено	Когда применять	Основной риск
Изолированный тест	Один удалённый сервер и один read-only-инструмент	Первое подключение и проверка протокола	Ложное ощущение безопасности после успешного чтения
Разработка	Ограниченное чтение, отдельный рабочий каталог, ручные подтверждения	Работа над тестовым проектом	Утечка данных через слишком широкий каталог
Тестовый контур	Чтение и контролируемая запись в тестовый ресурс	Проверка полной цепочки Agent — MCP — Mac	Повторная запись после сетевого сбоя
Production	Точные серверы и инструменты, отдельные ключи, аудит	Только после формальной приёмки	Скрытое расширение прав через глобальную маску
Командная среда	Централизованные политики, журналы и отзыв доступа	При большом числе пользователей и серверов	Сложность управления без владельцев политик

Финальный чек-лист перед передачей среды:

[ ] URL MCP проверен из облачного Mac, а не только с локального компьютера.
[ ] Заголовок авторизации не содержит ключ в открытой конфигурации.
[ ] Разрешён один конкретный сервер и минимальный набор инструментов.
[ ] read_file, command и mcp проверены независимо.
[ ] Глобальные шаблоны заменены точными правилами либо обоснованы отдельным ревью.
[ ] Запрос к запрещённому инструменту корректно отклоняется.
[ ] Запись требует ручного подтверждения.
[ ] В журнале различаются агент, MCP Server и удалённый Mac.
[ ] Описаны ротация и отзыв ключа.
[ ] Проверены восстановление сессии, диск, процессы и параллельные подключения.
[ ] Зафиксирована версия конфигурации и дата последней проверки.

Частые вопросы о развёртывании

Как добавить MCP Server в Google Antigravity на удалённом Mac?

Сначала подготовьте отдельный удалённый URL MCP-сервера, проверьте его доступность из облачного Mac и получите точные сведения о заголовках авторизации. Затем зарегистрируйте сервер в конфигурации Antigravity, задайте понятное имя и разрешите только один безопасный инструмент. Первый вызов должен быть чтением без доступа к файлам, shell-командам и внешней записи.

Как настроить права Antigravity MCP без глобального доступа?

Разделяйте разрешения read_file, command и mcp: они контролируют разные поверхности риска. Вместо глобальных шаблонов укажите конкретный MCP-сервер и конкретный инструмент, а для команд и файлов задайте отдельные каталоги. Операции с исходным кодом, секретами, платежами и внешними системами должны требовать ручного подтверждения.

Что проверить перед запуском Antigravity на облачном Mac?

Проверьте исходящий маршрут к MCP-серверу, DNS, TLS, переменные окружения, срок действия ключей, рабочий каталог и способ восстановления сессии. Облачный Mac не должен автоматически видеть домашние файлы, production-секреты или служебные токены команды. Для первого запуска используйте изолированный проект и тестовую учётную запись.

Почему вызов инструмента Antigravity MCP завершается ошибкой?

Диагностику следует вести по слоям: сначала URL и сетевой выход, затем заголовок авторизации, MCP-ответ и объявленный список инструментов. Если соединение установлено, но действие не выполняется, сравните имя инструмента с белым списком и проверьте права. Отдельно исключите сбой модели, MCP-сервера и самого удалённого Mac.

Для временного эксперимента локальный Mac может быть проще, если не требуются удалённая сессия и постоянная доступность. Однако при переносе Antigravity в облачную среду обычная аренда компьютера без заранее проверенного сетевого маршрута, ротации ключей и изоляции проекта оставляет три существенных недостатка: права часто выдаются вручную, состояние трудно воспроизводить, а диагностика сетевых и агентных ошибок смешивается в одном рабочем месте. Поэтому для тестирования удалённого Agent-контура разумнее выбирать Vuncloud, когда нужен отдельный облачный Mac с контролируемым рабочим пространством, а не сразу покупать отдельное устройство под краткосрочный эксперимент.