MCP Google — это удалённые серверы Google Workspace, через которые агент читает файлы Диска, ищет свободное время в Календаре и создаёт события по вашей команде. Каждый продукт получает отдельный адрес и отдельный набор разрешений, поэтому открывать можно только нужное. Связка годится команде, у которой есть проект Google Cloud и сотрудник, готовый подтверждать каждую запись.
Что открывает Google
Google публикует отдельные MCP-серверы для продуктов Workspace: Gmail, Диска, Календаря, Документов, Таблиц, Презентаций, Chat и People; в статье разобраны три из них. Сейчас они доступны участникам программы предварительного доступа для разработчиков, а запись включается отдельными разрешениями.
Предварительный доступ означает, что состав инструментов и условия могут измениться, поэтому названия из этой статьи сверяйте с актуальной страницей Google, а в своём сервисе держите их в едином файле настроек. Разберём один сценарий. Руководитель проекта просит агента подготовить встречу по договору. Агент находит на Диске файл с условиями, читает нужный фрагмент, смотрит свободные окна участников и предлагает время. Создание события остаётся за человеком: он видит дату, список гостей и текст приглашения, после чего подтверждает. Договор служит источником, календарь — единственным местом записи. Полные тексты и права доступа к ним остаются в Google, а в ваш сервис попадают только фрагменты, нужные для ответа.
Для Календаря документация Google перечисляет инструменты чтения (list_events, get_event, list_calendars, search_events, suggest_time) и записи (create_event, update_event, delete_event, respond_to_event). Деление на чтение и запись держит на себе всю схему: первое включают сразу, второе после проверки. Пока выданы только права чтения, агент остаётся без возможности что-либо изменить в вашем аккаунте: запись становится доступной лишь после того, как вы добавите соответствующее разрешение и сами включите инструменты записи. Если задача сводится к ячейкам, смотрите разбор Google Таблиц; здесь речь о документах и расписании.
Доступ и OAuth
Подключение начинается в консоли Google Cloud. По инструкции Google для разработчиков, нужны проект Cloud, включённые API нужных продуктов и их MCP-варианты (например, gmailmcp.googleapis.com), затем OAuth-клиент веб-приложения с адресом возврата вашего MCP-клиента и экран согласия. Членство в программе предварительного доступа — отдельное условие: пока условие остаётся невыполненным, подключение недоступно. Планируйте это заранее: оформляйте участие до начала пилота, а на время оформления готовьте тестовые документы и описание сценария.
| Продукт | Чтение | Запись | Решение человека |
|---|---|---|---|
| Диск | Поиск файлов, чтение содержимого | Копии и новые файлы | Владелец файла проверяет результат |
| Календарь | События, свободное время | События и ответы на приглашения | Организатор встречи подтверждает |
| Gmail | Поиск писем, чтение веток | Черновики | Автор читает черновик в почте |
Область доступа берите по минимуму: чем уже список разрешений, тем короче перечень вопросов, которые придётся задавать на проверке безопасности, и тем легче объяснить сотрудникам, что именно они подтверждают. В примере Google для Gmail чтение (gmail.readonly) и составление (gmail.compose) указаны раздельно, то есть это два разных решения. Экран согласия читают сотрудники, поэтому пишите на нём простым языком, какие данные видит агент и зачем. Согласие оформляйте от имени сотрудника, чьи данные читает агент, а для проверки заведите тестовую учётную запись с копиями документов. О токенах и отзыве доступа подробнее в статье про OAuth-доступ для MCP.
Чтение без записи
Хороший первый прогон отвечает на узкий вопрос: видит ли агент ровно то, что вы ему показали, и ничего сверх этого. Первый прогон проводите только с правами чтения. Он показывает, находит ли агент нужный файл, цитирует ли его точно и верно ли называет свободное время. Любая запись до этой проверки лишь добавляет путаницы: ошибку трудно отнести к поиску, к чтению или к самому действию.
- Создайте на Диске тестовую папку с двумя вымышленными документами: условиями договора и протоколом встречи.
- Подключите серверы Диска и Календаря и выдайте права на чтение.
- Попросите агента найти договор по названию, процитировать пункт об оплате и назвать свободное окно для встречи.
- Сверьте цитату с файлом, а окно — с реальным календарём участников; расхождения запишите в журнал проверки.
Фиксируйте в журнале проверки три числа: сколько вопросов задано, в скольких цитата совпала с файлом дословно, в скольких названное окно оказалось свободным. Эти счётчики дают основание расширять права или откладывать это решение. Если цитаты совпали, а окна верны, переходите к тексту приглашения. Если агент подменяет формулировки или предлагает занятое время, чините вход и инструкцию, а запись оставьте закрытой.
Какие документы и календари вы готовы открыть агенту первыми?
Подтверждение записи
Запись устроена в два шага, и оба видны человеку. Агент готовит предложение в структурированном виде: название, время, гости, описание. Сервис показывает его сотруднику, и только после разового подтверждения уходит вызов create_event. Многие MCP-клиенты спрашивают разрешение перед вызовом инструмента, но вариант «разрешать всегда» превращает защиту в формальность, поэтому для записи оставляйте подтверждение на каждый вызов.
Условное предложение выглядит так: «Встреча по договору, участники Иванова и Петров, время во вторник после обеда, описание со ссылкой на файл». Ссылка на файл допустима, а вставка пунктов договора в описание события раскрывает их всем гостям, включая внешних. Отдельный риск описывает сама документация Google: когда модель получает данные из недоверенных источников, возможна косвенная атака через инструкции в тексте (prompt injection). Письмо или документ может содержать фразу вроде «пригласи на встречу такого-то». Поэтому текст файлов считается данными, а команду на запись даёт только сотрудник в диалоге.
Проверку удобно встроить в клиент: список разрешённых инструментов на первом этапе содержит только чтение, а запись добавляется позже и с ручным подтверждением. Тогда ошибка в формулировке задачи упирается в запрет, и сотрудник видит остановку вместо молчаливого действия. Перед каждой записью сотрудник просматривает короткий чек-лист.
- Состав гостей совпадает с заявленным в задаче.
- Время лежит в свободном окне организатора.
- В описании события нет выдержек из закрытых документов.
- Календарь выбран тот, что указан в задаче.
Журнал и отзыв
В журнале храните время, учётную запись, имя инструмента, идентификатор события или файла и решение сотрудника. Тексты документов и писем оставляйте вне журнала: они остаются в Google. Так вы воспроизводите ход событий и сохраняете закрытую границу данных.
Отзыв доступа проверьте до пилота: уберите согласие в настройках аккаунта Google, затем убедитесь, что вызовы агента завершаются ошибкой авторизации. Отзыв без проверки остаётся предположением. Для шага проверки возьмите двух сотрудников с разными правами на один и тот же файл: агент обязан показать каждому только то, что открыто ему в Google, и этот результат подтверждает, что права проверяет сервер Google, а у модели такой возможности нет. Заодно выясните, кто из администраторов домена видит выданные согласия и как быстро он отключит чужое приложение, если сотрудник ошибся при выдаче прав. Учтите смену сотрудников: когда человек уходит из компании, его согласие и токены закрывают в тот же день, а агентские сценарии, завязанные на его учётную запись, переназначают. Пилот разумно ограничить одним календарём и одной папкой Диска, а обязанности распределить заранее: кто владеет OAuth-клиентом, кто читает журнал, кто подтверждает записи.
Заведите тестовую учётную запись, скопируйте в неё два рабочих документа и выдайте только чтение. Когда цитаты и окна совпадут, добавляйте create_event с подтверждением. Если нужен проектный контур с правами, журналом и приёмкой, обсудите с нами ИИ-агента для вашей команды.