СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorMCPREST APIGoogle CalendarкалендарьOAuthавтоматизацияИИЧернов пишет

Готовый MCP или свой REST: Google Calendar

Готовый MCP или свой REST: Google Calendar

Команда живёт в двух календарях. У одного встречи в Google, у другого - в корпоративном, события расходятся, и каждое согласование времени превращается в переписку: а тебе во вторник в три удобно? а Маше? а давайте в четверг. Эту рутину хочется отдать ассистенту первым делом - и правильно хочется.

Если у тебя Яндекс Календарь - не беда, приём тот же; пример на CalDAV есть в уроке 0015, но развилку MCP-против-REST проще понять на Google, потому что у него есть и то, и другое.

Но как только садишься это автоматизировать, прилетает развилка, на которой спотыкается почти каждый. С одной стороны - можно написать свой скил-обёртку поверх REST-API календаря. С другой - где-то слышал про готовые MCP-коннекторы, которые вроде бы делают всё то же самое из коробки. Что брать? Жалко времени писать своё, если готовое уже есть. И жалко тащить чужую зависимость, если задача на пять строк.

Этот урок - не столько про календарь, сколько про сам выбор. Календарь тут - удобный пример, потому что у Google Calendar есть и нормальный JSON-REST, и готовые MCP-серверы. То есть развилка стоит во весь рост, и на ней удобно показать правило, по которому ты будешь решать такие вопросы всегда.

В чём идея

Сначала про то, между чем выбираем. MCP-коннектор (Model Context Protocol) - это готовый сервер, который кто-то уже написал и который умеет ходить в сервис за тебя. Подключаешь его к ассистенту - и просто просишь словами, а как именно дёргается API, спрятано внутри коннектора. Свой скил поверх REST - это твоя короткая инструкция ассистенту: вот адрес, вот авторизация, вот что сделать. Ассистент сам собирает запросы по документации.

У Google Calendar для этого есть честный REST. Создать встречу - один запрос на добавление события. Перенести - запрос на правку того же события новым временем (важно: тем же идентификатором, иначе получишь дубль вместо переноса). А самое вкусное для согласования - отдельный запрос про занятость: отдаёшь список участников и интервал, в ответ получаешь, кто когда занят, и предлагаешь общее свободное окно (работает, если участники поделились календарём с тобой или вы в одном Workspace-домене; для личных аккаунтов чужие слоты увидишь только после того, как коллеги дадут доступ). Доступ закрыт по OAuth.

Теперь правило, ради которого всё. Когда брать готовый MCP, а когда писать свой скил? Ответь себе на четыре вопроса. Есть ли проверенный коннектор ровно под твою задачу - тогда бери его, не изобретай. Нужна ли своя логика: особые правила выбора окна, свой формат ответа, своя политика переноса - тогда пиши скил. Готов ли ты тащить и поддерживать чужую зависимость - если нет, пиши скил. И задача типовая-разовая или это ядро твоего процесса - типовое отдай коннектору, ядро держи под своим контролем.

Свернём в одну фразу: типовое и разовое - готовый MCP; своя логика, контроль или подходящего MCP просто нет - свой REST-скил. Скил и коннектор не враги, это два пути к одной цели. И ключевое - в обоих случаях тебе не надо держать детали API в голове: скил говорит ассистенту, ЧТО сделать, а как собрать конкретный запрос, он разбирает сам.

Честная оговорка про Россию. Сам API Google глобальный и рабочий, но доступ к Google из РФ нестабилен и часто требует обхода - VPN или прокси. Без этого скил будет спотыкаться не по своей вине. Поэтому приём важнее площадки: ту же развилку MCP-против-REST один в один применяй на доступном календаре. В соседнем уроке этой серии тот же подход показан на Яндекс Календаре по протоколу CalDAV - если обхода к Google нет, начни оттуда, логика выбора не меняется.

Как себе сделать

Сначала про токен, потому что сам он с неба не падает. Перед запуском скила один раз заведи доступ: зайди на console.cloud.google.com, создай проект, включи Google Calendar API, создай OAuth 2.0 client (тип Desktop), скопируй client_id и client_secret и пройди согласие (consent screen) в браузере - в обмен получишь access- и refresh-токены. Ассистент поможет написать скрипт обмена, но клики в консоли и подтверждение согласия за тебя никто не сделает. Это разовые 15-30 минут; дальше скил берёт access-токен из переменной окружения, а refresh держишь под рукой, чтобы продлевать.

Дальше не пиши скил руками и не решай развилку на глаз - отдай задачу своему ассистенту. Claude Code, Codex, Cursor, любой: он сам проверит, есть ли готовый коннектор, и если нет - соберёт скил поверх REST. Просто скопируй промпт:

Помоги мне с событиями в Google Calendar и сначала реши развилку: брать готовый MCP-коннектор или писать свой скил поверх REST.
Сначала проверь, есть ли проверенный MCP-сервер ровно под Google Calendar. Если есть и он закрывает мою задачу - подключи его, обёртку не пиши.
Если нужна своя логика (свой выбор окна, свой формат ответа) или подходящего MCP нет - создай скил gcal-events поверх REST API v3.
Триггеры: "поставь встречу", "перенеси событие", "когда все свободны", "согласуй время".
Скил должен уметь: создать событие, перенести его на новое время тем же идентификатором (не плодя дубль) и найти общее свободное окно на нескольких участников через запрос freeBusy.
Авторизация - OAuth-токеном из переменной окружения, в файл токен не записывай (client_id, client_secret и refresh-токен я уже завёл в Google Cloud Console).
Инструмент выбери сам по тому, что есть в системе, без привязки к ОС.
Отвечай по-человечески: что сделано или какое окно свободно у всех, с датой и временем.
Учти: freeBusy видит чужую занятость только если участники поделились календарём или вы в одном Workspace; из РФ доступ к Google нестабилен, может понадобиться обход.

Как понять, что заработало: напиши ассистенту по-человечески “когда вся команда свободна в четверг днём”. Если он сам сходит в календарь, сверит занятость всех и предложит конкретное общее окно с датой и временем - скил живой, развилка решена правильно. Дальше проси ставить и переносить встречи теми же словами.

А заодно ты ответил себе на главный вопрос урока. Ты не выбирал между скилом и коннектором по моде - ты выбрал по задаче. Появится удобный коннектор под твой кейс - спокойно перейдёшь на него, скил выкидывать не жалко. Это и есть зрелый подход: инструмент под задачу, а не задача под инструмент.

Смотреть полностью

Коротко